bitcoin-sv
[DISCUSSION] BEEF_V2 & Atomic BEEF support
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.
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.
Makes sense @1deepwaterz - an all or nothing option. I suppose the trouble might be that the issue could arise when broadcasting the transactions which is "no takey backsies" if something later goes wrong. Any validation ARC can do independently of that is UTXO lookup based. Something which we have on the roadmap, but doesn't currently happen. When you send EF and BEEF there's actually nothing checking to see if the input is spent. That's the most likely cause of error.
So really this could be seen as another request to ensure there's a clear "yes/no" to the question of whether or not existing utxos in a set of transactions are spent. #770
So the steps we could take to solve your issue here:
- Determine the full set of UTXOs which are external to the set of transactions (not created by one of the transactions in the given set).
- Lookup each of those UTXOs.
- If any in that set are spent. then do not proceed with the broadcast.
- Else broadcast in topological order with an appropriate delay between each broadcast to avoid orphans.