[DISCUSSION] - BRC-95 Atomic BEEF vs BRC-62 BEEF

[dorzepowski]

BRC ID

95

Discussion

It looks for me, that there may be a misunderstanding regarding BRC-62.

1. While it’s not explicitly stated, the intent was that BEEF operates as a format for a single transaction.
   The Ordering subsection, of the BEEF specification, requires Kahn's Topological Sorting, which by definition applies to a single DAG.
   I would like @sirdeggen to confirm my understanding there.
   1. This suggests that the introduction of the "Atomic BEEF" might be unnecessary.
      Additionally, once sorting is applied, the final transaction naturally becomes the subject, removing the need for an extra field to specify it proposed in Atomic BEEF.
   2. Also It might be worth revisiting the specification to clarify these assumptions.
   3. Also consider whether this clarification affects assumptions made in other BRCs or in current implementations.
   4. It may also be necessary to introduce a new format or mechanism for handling merged lists of BEEFs. Since BEEF has been previously used in a way that implies merging multiple instances, such a format would help ensure that duplicates are removed from both the BUMP list and the transaction list. This approach would maintain the intended efficiency of the BEEF format by reducing redundancy and streamlining the overall process.

[tonesnotes]

The BRC-62 (V1) BEEF spec was motivated to support the validity of a single transaction. But the serialization format trivially extends to support multiple new transactions, in which case it becomes a rather arbitrary requirement to say which one is "special". The sort order does require dependencies to appear before dependents, but it explicitly does not require that transactions must be no more than one generation from a BUMP. That is, from a "newness" perspective, a BEEFs purpose is to contain many transactions that are new.

BRC-95 clarifies and makes explicit the originally assumed but not enforced use case of a BEEF in support of a single newest transaction. But in many use cases it makes a great deal of sense to aggregate and share sets of "new" transactions.

Consider the ARC endpoint https://tapi.taal.com/arc/v1/tx to which a serialized BEEF may be posted:

1. If I construct a BEEF with multiple new transactions, each with validity fully supported, how should ARC respond?
2. What sense would it make to be required to create and send multiple BEEFs one at a time for each new transaction?

A central point of Bitcoin is to support the validity of data encoded as transaction outputs. I believe the BEEF format can and should directly support this mission where it is viewed as a list of transactions and BUMP proof data which together allows for the validity of the data in those transaction outputs to be fully trusted.

Applications and services should not be sending transactions, they should be sending BEEFs. Receive a BEEF, verify its validity, and all the transaction data it contains is good to go.

The @bsv/sdk-ts Beef class implements the BEEF V1, V2 and Atomic specifications. It supports merging Beefs, raw transactions, and BUMPs. It implements validation and verification. This includes being able to filter down an arbitrary collection of BUMPs and transactions into an AtomicBEEF.

Using the Beef class, here's a snapshot at the inner workings of a BEEF enabled wallet:

1. The wallet maintains a Beef instance to hold recent transaction validity data.
2. To build a transaction, existing outputs may be queried from back end services. These are returned with a supporting Beef which is merged into wallet Beef.
3. New external inputs must be accompanied by a supporting Beef which is merged into wallet Beef.
4. A full set of new inputs is sent to back end services with a supporting Beef to create and process as a new transaction.
5. Broadcast to the network may be deferred until a batch of new transaction is completed and then broadcast.
6. As new proofs a received, they are merged into wallet Beef.

To understand the motivation for the V2 Beef extension specification, consider the exchange of Beefs between the local wallet and its back end services:

1. Once the wallet receives valid transaction data from the backend it should never send the same data back, the server already knows its valid.
2. Thus when constructing a new transaction with outputs from prior known by the server transactions, there must be an encoding for a transaction in a BEEF when the recipient is known to already possess the raw transaction and proof data.
3. In this case, a fully V1 valid BEEF can be reduced by replacing full raw transactions with just their txids and a flag indicating that the recipient should recognize it. This is what V2 allows.

[tonesnotes]

The BEEF V2 Spec is here: BEEF V2

[dorzepowski]

Thank you for your response and for emphasizing the importance of Atomic BEEF. After revisiting the specifications and discussions, I’ve realized that you're referring to BEEF v2 (although in the Atomic BEEF specification BRC-62 is mentioned).

I now understand that BEEF v2 introduces support for multiple transaction graphs. However, this has led me to reassess how BEEF, as originally defined, relates to Atomic BEEF and its motivations.

From my perspective, the issue Atomic BEEF aims to address as described in the Motivation section does not seem to exist in the context of the original BEEF (BRC-62). The Motivation section suggests that BEEF can contain multiple unrelated transactions, but due to the required Kahn sorting, which enforces a valid topological order, BEEF inherently operates on a single Directed Acyclic Graph (DAG). Transactions that are not part of the same graph as the last transaction can validly be ignored by any tool parsing the BEEF into a class/structure.

With regard to BEEF v2, while it introduces support for multiple transaction graphs, I believe this represents a significant departure from the single-transaction focus of the original BEEF. This divergence, while valuable for broader use cases, complicates the narrative that BEEF v2 is simply an iteration or extension of the original format. The reliance on Kahn’s sorting in BEEF makes it inherently unsuitable for multiple DAGs, as attempting to use it for such purposes could result in unpredictable behavior or ignored unrelated graphs.

I fully recognize that you may have a different interpretation. To better understand your perspective, could you provide an example—ideally with a diagram or drawing (or ascii art) — demonstrating how multiple DAGs could be encoded in BEEF (BRC-62)? Furthermore, it would be helpful to see how Atomic BEEF specifically addresses issues that a correctly constructed BEEF (BRC-62) cannot resolve.

Looking forward to your clarification.

[tonesnotes]

There are two distinct points here that I'll respond to:

1. BEEF V2 addresses data redundancy. Sending a BEEF to a party already aware of potentially large but still unmined transactions on which new transactions depend.
2. The "multi-DAG" view of BEEF, which I'll call the "multiple-new-transactions" view of BEEF.

Expanding on #2 first, "multiple-new-transactions".

Even in the original single DAG view of BEEF, sending a BEEF with multiple new transactions to ARC's post BEEF endpoints currently works as it should: each new transaction (never broadcast before) gets processed into the chain. It would make no sense for a recipient to complain about an internal dependency transaction that they had not seen before but whose validity was fully supported by the BEEF.

So even in the "only-one-newest" transaction case, single DAG, I argue it makes no sense to disallow multiple new transactions to be sent in a single BEEF.

On to full "multiple-new-transactions", imagine we start with proven transaction A and create new transactions B and C, each of which consumes one output from A. Now I want to send B and C for processing. Am I going to create two BEEFs, each containing a full copy of A just to adhere to "AtomicBEEF"?? What I want to do is throw all three in a single BEEF with a BUMP that supports A and send the single BEEF to ARC for processing. And this works... Why would ARC ignore valid transactions for which it can easily prove validity?

So, it seems to come down to sort order. As I see it, the critical requirement is that dependencies are serialized first: If B consumes outputs from A, then A must be serialized first. This requirement does not yield a unique sort order in the general case, but I see no reason for requiring one. The use of Kahn's algorithm seems like an example to me, not a requirement.

Expanding on #1, BEEF V2

When you start using BEEF to send transactions with validity data in any kind of a multi-step transaction data exchange process you should rapidly realize that V1 often requires you to return data to its source, because it is required to support the validity of yet unmined new work.

You could serialize incomplete, unverifiable BEEFs and send that, expecting the recipient to realize they possess the missing data. This choice greatly expands the potential work to invalidate actually invalid BEEFs. BEEF validity would also depend on context: Do you possess an external validity store that has the missing data.

BEEF V2 extends V1 by allowing transactions to be listed in the BEEF in two ways: full serialized raw transaction OR just it's 32 byte TXID. When determining the validity of a V2 BEEF, a transaction is valid either in the V1 sense OR if it is just a TXID. The recipient of a V2 BEEF can verify validity efficiently yielding an explicit list of TXIDs they are expected to already know are valid.

[tonesnotes]

From BRC-62:

We propose a binary format for sending Transactions between peers to allow Simple Payment Verification (SPV). The format is optimized for minimal bandwidth while maintaining data required to independently validate the transaction in full.

"Transactions..." plural. Reading this to mean only the last transaction really matters or that they must all form a single DAG is greatly narrowing the obvious intent and utility of the specification.

Order is important - we must ensure that we end with the tx being evaluated, and its inputs are above, and their inputs are above that. Khan's algorithm is a well known solution to the problem in Graph Theory. Running this on the transaction DAG subset is recommended for complex transaction chains where order is not clear. Example below to demonstrate with extraneous data removed for clarity.

"Must ensure" that inputs appear as outputs before use as inputs...

"DAG subset"..."recommended for complex transaction chains" The algorithm is explicitly not a requirement. DAG already allows for multiple new transactions B and C depending on A but not each other.

[tonesnotes]

Transactions that are not part of the same graph as the last transaction can validly be ignored by any tool parsing the BEEF into a class/structure.

But why would you want to?? If you are a transaction processor and someone sends you a BEEF containing multiple DAGs with validity support for each one, why would you not process all the new transactions?? If you are a business data processing service and someone sends you a BEEF with multiple DAGs, it either makes sense or doesn't based on service level context. It may certainly be beneficial.

Only in the case where you must consider the BEEF as supporting a single transaction are you justified in ignoring unrelated data. This is the precise point of AtomicBEEF.

[dorzepowski]

On to full "multiple-new-transactions", imagine we start with proven transaction A and create new transactions B and C, each of which consumes one output from A. Now I want to send B and C for processing.

I understand your point and I didn't ever question the idea that we need some format for transferring, but to have a better view. I would like to ask you for an example how can I prepare with ts-sdk, Transaction so the toBEEF (BRC-62) will contain both B and C, because I would like to examine such a BEEF.

[dorzepowski]

Thank you for your response and for elaborating on the purpose of AtomicBEEF.

I’d like to better understand why introducing AtomicBEEF is necessary, given that BEEF v1, implemented with Kahn sorting, appears to solve the same problem without requiring additional metadata. From my involvement in preparing BEEF v1, it was designed as an extension to EF, which itself extends the RAW TX format. Our intention with BEEF was to create a format for a single transaction that provides all the information required for SPV validation in a compact, efficient structure.

Rather than introducing a new AtomicBEEF format, wouldn’t it make sense to simply add a requirement to BEEF that the last transaction is the subject of the BEEF and that all included transactions must belong to the strict subtree of this transaction? Any unrelated transactions would then be ignored. This approach eliminates the need for adding a txid to the header of the format and aligns with the original design principles of BEEF.

Regarding BEEF v2, I believe it could be more aptly named Aggregated BEEF to reflect its broader scope and differentiate it from the single-transaction focus of BEEF. Aggregated BEEF could use a different magic number while retaining most of the structure of BEEF, but without the single-DAG requirement (and with appropriate sorting rules). This approach preserves the understanding that has already been established in the BSV ecosystem around BEEF, while clearly delineating the new functionality.

To illustrate the established understanding of BEEF as a single-transaction format, I’d like to point to the ts-sdk API, where the Transaction class has a method fromBEEF that returns a single transaction. This raises the question: if BEEF were intended to store or transfer multiple transactions, what would this method return in such cases?

I hope this perspective contributes constructively to the discussion, and I look forward to further clarifications and insights.

[tonesnotes]

I understand your point and I didn't ever question the idea that we need some format for transferring, but to have a better view. I would like to ask you for an example how can I prepare with ts-sdk, Transaction so the toBEEF (BRC-62) will contain both B and C, because I would like to examine such a BEEF.

Certainly! The Beef class in ts-sdk supports all the formats. You could use something like the following:

import { Beef } from '@bsv/ts-sdk'
const beef = Beef.fromBinary(<BRC-62 BEEF of A>)
const A = beef.findTxid(<txid of A>).Tx  // Transaction A
const B = new Transaction() // add output 0 from A as input to B
const C = new Transaction() // add output 1 from A as input to C
beef.mergeTransaction(B)
beef.mergeTransaction(C)
const ok = await beef.verify(chainTracker)
const beefABC: number[] = beef.toBinary()

[tonesnotes]

Note that Beef.fromBinary() will read V1, V2, and AtomicBEEF serialized formats. You can force V1 format only. By default it serializes to V2 only if you use mergeTxidOnly(txid) or if you use fromBinary() on data containing txid only transactions.

[dorzepowski]

Thank you for the example code! I will experiment with it to gain a better understanding.

In the meantime, I’m still looking forward to your opinion or comment regarding my proposition to use BRC-62 BEEF instead of AtomicBEEF, as well as the suggestion to redefine BEEF V2 as a separate format—such as "Aggregated BEEF"—for handling a list of any transactions.

[tonesnotes]

It would help me to understand if you could explain why you feel it is so important to disallow more complex relationships between the transactions?

What constituency are you speaking for? What problem or difficulty is caused by this interpretation?

[dorzepowski]

To clarify, I do not want to disallow more complex relationships between transactions.

My intention is to make BSV technology accessible to developers across various programming languages and skill levels. As someone who works on spreading knowledge about BSV and open-source tools, I know there is a diverse group of developers—those working in TypeScript and others using different languages, sometimes on large-scale projects—who are already testing or building solutions based on BSV and its SDK.

Due to how the SDK API was originally designed, these developers have developed an understanding that BEEF represents a single transaction. They will also continue to share this understanding and knowledge with others.

A change that significantly alters the established intention and understanding of BEEF can cause confusion among these developers. It may also strengthen a perception that BSV is not a stable, well-defined, and standardized solution, as the standard and its interpretation could seemingly change overnight. My concern is to avoid introducing ambiguity and misunderstanding by reusing a standard that has been widely understood as one for serializing a single transaction and its related data. I am fully open to supporting more complex relationships, but this should be achieved by defining a new serialization standard. Such a standard could even be less restrictive, allowing the serialization of any number of transaction DAGs—whether related or not—while maintaining clarity and avoiding confusion.

As one of the authors of the BEEF specification, I want to clarify that BEEF was originally designed as a serialization format for a specific transaction along with its parents (or more precisely, all the data required to perform SPV for that transaction). It was never intended to serialize arbitrary transactions from a single DAG.

To illustrate this point, consider the initial API in ts-sdk, which introduced a Transaction.fromBEEF function. If BEEF were meant to support multiple transactions, this method would have been fundamentally misleading.

If we were to serialize multiple transactions, the ambiguity arises: which transaction should fromBEEF return? This highlights that the original understanding of BEEF was focused on serializing a single transaction along with its related data, rather than handling multiple unrelated transactions.

Additionally, it might help me to understand your perspective if you could clarify why you are against preserving the original, already established intention of the standard. Why do you feel it is so important to introduce ambiguity and potential confusion by redefining a standard that has been widely understood to serialize a single transaction?

[tonesnotes]

Thank you. This is very helpful. And I apologize for presuming to read use cases into a spec you co-authored.
In my defense, this feels more like the horse has escaped from the barn and I'm just sharing that it is running free.
Can we reframe this conversation as not one of subversion but rather one of "what and amazing tool this is with support for a much wider range of use cases!"

Because the serialization format enables an arbitrary list of transactions linked to validation data, it IS going to be used wherever that capability is needed. A bit like the inventor of the private passenger car intended for a single-family use learning that they were all taxis as well when Uber came along.

In concrete terms: ARC has a 'v1/tx' endpoint that accepts a BEEF for broadcast to the network. I tested the endpoint earlier this year and confirmed that if the beef contained multiple new transactions, they would all be broadcast. Since this functionality is critical to our wallet and efficient in that it doesn't require repetition of validity data and multiple requests.

My interpretation of this is that while the author of the endpoint may have shared the single transaction BEEF viewpoint, but ultimately what were they supposed to do when the beef contained additional fully valid transactions? Theoretically they get paid to process new transactions and here I am delivering them in my Uber.

In clarification of my support for preserving the original: Absolutely! No changes are required. My role here has been to observe that this fabulous tool CAN and IS being used in ways that extend a bit beyond the original language and perhaps that could be shared as well.

[tonesnotes]

First paragraph of BRC-62:

We propose a binary format for sending Transactions between peers to allow Simple Payment Verification (SPV). The format is optimized for minimal bandwidth while maintaining data required to independently validate the transaction in full.

If that last "transaction" had been "transactions", you wouldn't have a leg to stand on :-)

As it is, the recipient of a BRC-62 BEEF for SPV payment will treat it differently than a transaction processor should.

From an SPV point of view, the last transaction is the purpose of the BEEF, the remaining transactions support its validity and serve only to generate the right hash values.

A transaction processor, however, should treat any valid transaction in the BEEF as a new transaction to be added to the next block. It makes no sense to ignore valid transactions that support the validity of the latest transaction(s). If they weren't accepted, the last transaction wouldn't be mineable.

We have the BEEF BRC-62 format. It is eminently suitable for sending multiple new transactions with validity support to a transaction processor. Are you seriously proposing we bump the version number just to reflect that the BEEF contains multiple "newest" transactions? I would counter argue that it makes more sense to start with a flexible base standard and then extend that to handle specific use cases. Or perhaps, let this standard cover the encoding of the data and let the context by which they are exchanged handle the nuances on how the data is to be used.

[dorzepowski]

We have the BEEF BRC-62 format. It is eminently suitable for sending multiple new transactions with validity support to a transaction processor. Are you seriously proposing we bump the version number just to reflect that the BEEF contains multiple 'newest' transactions?

First, I don’t understand the reference to "newest transactions". Neither BRC-95 nor BRC-96 mentions this concept or mention anything that could limit somehow "newness". The term seems to have been introduced without basis in the specifications, and it adds unnecessary confusion or maybe it's a clue that actually BRC-95 and BRC-96 is adding unnecessary confusion.

Atomic BEEF operates on the same core principles as BEEF (BRC-62). The primary distinction is that Atomic BEEF includes an additional header for contextualization. Importantly:

• A properly structured BEEF should ensure that the transaction being validated appears last in the list.
• This is entirely consistent with BRC-62, which specifies that transactions must be sorted such that inputs appear before the transactions that consume them.

This design is not incidental—it optimizes parsing efficiency and simplifies validation.

Instead of redefining BEEF, a minor improvement would suffice: explicitly validating that a BEEF contains only related transactions (those directly connected to the subject transaction), and explicitly mention that the last transaction is considered a subject transaction.

The changes in BRC-96, which allow multiple transactions related solely through a common ancestor, fundamentally alter the assumptions underlying BEEF.

Rather than extending BEEF to accommodate loosely related transactions¹, I propose that such a format be treated as an entirely new standard. This can be achieved easily:

• Introduce a new magic number while preserving the rest of the format.
• This approach avoids confusion and maintains compatibility for existing BEEF implementations.

I would counter argue that it makes more sense to start with a flexible base standard and then extend that to handle specific use cases.

It is too late to say that we're "starting" with a flexible base standard. BRC-62 was last updated over a year ago and has been widely adopted. Methods like Transaction.fromBEEF in ts-sdk, go-sdk and py-sdk have been built on these assumptions, and other custom solutions also.

By contrast, BRC-95 and BRC-96 were introduced only recently and are attempts to build on top of BEEF. This distinction matters because any major change to BEEF risks breaking established workflows and confusing the user base.

Instead of retrofitting flexibility into BEEF, we should define a new standard for bundling multiple transactions. This new standard could:

• Extend BEEF’s core design to introduce flexibility.
• Allow for arbitrary transactions, even if they are completely unrelated. Each transaction would include its own dependencies to ensure validity.

This solution keeps BEEF focused on its original purpose—serializing a single transaction and its related data—while enabling a broader, more flexible format for advanced use cases.

By introducing a new standard, we avoid unnecessary confusion, preserve compatibility, and ensure that both BEEF and its extensions remain clear and intuitive for developers and implementers.

---

1. "loosely related transactions" - Although such transactions may share a common ancestor, there is no mention in the specifications, nor are there any tools or mechanisms to guarantee that these transactions are substantively or meaningfully related. The only connection between them is the user or system grouping them together and their shared ancestor. This is insufficient to suggest any deeper relationship compared to a set of unrelated transactions sent by the same user or system.

[tonesnotes]

Again, no design change is requested or required. My contributions here have all centered on pointing out use cases that are occurring using the exact design of this specification.

The desire to add additional validity checks on the sort order not originally included in the specification should be resisted as they can be trivially ignored and will only break existing code.

Transaction.fromBEEF continues to work in a reasonable manner, pulling a single valid subtree for the newest transaction out of the DAGs of transactions encoded in the BEEF. There's a documentation opportunity here, not a specification issue.

[sirdeggen]

I really like the extension to the original idea of BEEF @tonesnotes describes in BRC-96 in that it is indeed a trivial extension of the original idea to have completely separate transactions encapsulated in the same blob of binary. Why not?

The reason I chose 0100BEEF as the version number was so that we could easily adopt 0200BEEF when the time came to extend or improve on the idea. The inclusion of the two main ideas are welcome in my view:

1. Ability to quickly acknowledge a known tx by referring to its txid and simply assuming the validity of it within a more complex DAG.
2. Explicitly encourage the encoding of multiple unrelated transactions in the same structure.

[sirdeggen]

The motivation for txidOnly is clear - you don't want to have to resend data if you can avoid it and you know the counterparty already has it. Plus you get performance optimization too!

[sirdeggen]

The motivation for multiple unrelated transactions is also clear, and the inclusion of BUMP format implies this use case -- since it optimizes for paths for many transaction within the same block being shared.

I agree with @dorzepowski that it was our original intention to have the minimum data necessary to prove one transaction in the simple payments context.

I agree with @tonesnotes that ARC implementation proves useful and can be generalized to any set of transactions. It will greatly reduce the amount of data being passed around once we see use go up significantly and we should try to optimize for massing throughput despite it not being present for now.

[sirdeggen]

The part I don't actually think is necessary is Atomic BEEF BRC-95. I'm going to go back again and check my premises and the intention to try and re-evaluate having heard Damian's point that it might be redundant. BEEF_V1 might be just as valid a format for such an encoding... trying to determine what I've missed. Probably txidOnly encoding of a singleton?

[sirdeggen]

Maybe there's room to improve the language of the classes in the SDKs whereby we indicate BEEF is an encoding of a single transaction.

Transaction = version inputs outputs locktime
BEEF_V1 = ProofData (BUMPs and previousTxs) Transaction (one)
BEEF_V2 = BUMPs Transactions (many, can be txid only, rawtx only or with merkle path)

As long as we have Transaction and Beef I think we're ok. No immediate need to update names.

[sirdeggen]

Re-reading the BRC again, if we simply state explicitly that BEEF_V1 is essentially what you desire from Atomic BEEF the only question for me is whether we need the txid to be upfront for some reason. The txid is implied in BEEF_V1 in the sense that you have to hash the last tx to know what the subject txid is.

Otherwise in my view that is exactly what BEEF_V1 should be already.