[DISCUSSION] BEEF_V2 & Atomic BEEF support

[sirdeggen]

Summary

Update to latest version of go-sdk which has inbuilt functions for parsing both BEEF_V1 and BEEF_V2, and Atomic BEEF.

/tx should support Atomic BEEF
/txs should support BEEF_V2

Perhaps we should maintain BEEF_V1 support for a while on both.

Motivation

Mixed reviews on using ARC with sets of transactions which happen together.

Description

The expectation is that v2 is a set of potentially unrelated transactions. We should be smart about parsing beef in general where we build up a dependency tree so there is some understanding of whether there are parents and children involved. We also should be cognizant of whether txs in the BEEF have Merkle Paths which means they are there for the purpose of SPV validation on receipt; or if they don't then to add them to the list of transactions which need to be broadcast in order of parent, child etc. The response could be an array of responses to each tx we attempted to broadcast, but callbacks ought to be fired off on an individual tx basis.

Additional References

Tone's feedback to the ARC dev team.

[1deepwaterz]

Hello. So I've been thinking about the need for some assurance that a batch of transactions is validated, and rejected as one. It sounds like v2/Atomic beef may be what I need specifically. The idea being we have a set of transactions that related to a business process. Currently we broadcast them on build essentially, but that has the drawback of sometimes having to unpick some application state when something bad happens.

Now, if we adopt the batching approach, and issues during the building of the batch will allow is to reject prior to broadcasting therefore any batches we broadcast should be good .. but none the less .. it would still be nice to have the assurance that if one or more transactions in the batch fail to validate .. then the batch as a whole is rejected allowing for a tidier rollback of application state.

Some thoughts from the trenches.