The Transaction ancestors specification in a nutshell

Think back to the days of credit cards that authorised payments via a magnetic strip on the back (before the days of chips, PINs or contactless payments). When you paid at a restaurant using your credit card, the merchant would require you to sign the receipt to confirm the purchase. It would then be the merchant’s responsibility to verify that the signature on the receipt corresponds to the one on the back of the card, alternatively that your photo ID confirms your ownership of the card. Although this process wouldn’t ensure that the customer has adequate funds in their account (that would require a call to the bank), it would prevent the merchant from accepting a fraudulent transaction.

Similarly, the Transaction ancestors specification establishes a process for checking that a person is authorised to make a certain transaction. A BSV merchant would check the extension transaction data to ensure its validity before submitting it to a transaction processor or miner. 

In this edition of our TTDR (Too Technical Didn’t Read) blog, we speak to the author of the Transaction ancestors specification, Jad Wahab to learn how it relates to other ‘envelope’ specs, how it works and what its value proposition is for the BSV blockchain and enterprise clients.

Technical Standards Committee (TSC): The TSC is working on a number of specifications with the term ‘envelope’ in them. How do they relate to one another?

Jad Wahab (JW): There’s the JSON envelope that we use for mAPI and there’s the data envelope spec that Tokenized and a few other people are working on. To avoid confusion between all of these ‘envelopes’, we’re exploring separating the payment/current transaction from the SPV data instead of having them both in the same structure as initially proposed. We’re still exploring a new, more accurate name for it but the separation definitely makes it easier.

TSC: What does the Transaction ancestors specification do, and what need does it fulfil in BSV?

JW: As background, you need to understand how this standard relates to the P2P Payment Protocol (P4), previously called BIP270, that has to do with peer-to-peer payments and the communication flow between a sender/receiver or customer/merchant. 

The process of undertaking peer-to-peer payments looks as follows: first, the sender has to fetch a payment request from the recipient in which they specify which outputs they want to receive. For example, the recipient might want to receive the total payment of $100 into various outputs to maintain their privacy. Someone observing the blockchain would see the many different outputs, but it would be difficult to connect them and understand the significance of the transaction outputs. Then the sender sends the payment directly to the receiver and the receiver then broadcasts it to get it settled on the Bitcoin ledger.

The Transaction ancestors specification allows the receiver to have better assurances and guarantees in order to properly assess a payment format and details before settling it on the blockchain. These criteria could relate to fees, state channels (interim states), multiple inputs, multi-sig spending and spending complex scripts. 

TSC: Which eventualities does the specification cater for?

JW: Let’s look at the example of miner fee policy. If a wallet broadcasts a transaction to the network without checking that it meets the minimum miner’s fee, the network might reject the transaction. Over time, wallets that broadcast invalid transactions to the network might be banned. The other immediate repercussion is that transactions with fees that fall short of the miner fee but meet the relay fee, will be accepted into a miner’s secondary meme pool. Until one of the other miners in the network is willing to process that transaction or it’s dropped from the secondary meme pool, it will remain stuck. Keep in mind that BSV, unlike BTC, does not have a replace-by-fee feature to deal with such scenarios. Unfortunately, this issue has already manifested on the network a couple times recently.

In practical terms: if a miner’s fee is 0.05 Satoshi per byte, then they will mine transactions that pay at least 0.05 Satoshi per byte of data. But they will also have a relay fee of perhaps 0.025 Satoshi per byte. Although they won’t mine these transactions, they will keep them in their secondary meme pool and broadcast them to other miners for validation to protect against double-spending. It also covers them in case a miner with a lower minimum fee decides to mine it, and they have to validate it rapidly. 

The Transaction ancestors spec will eliminate such eventualities entirely. Instead of blindly broadcasting a transaction to the network, the transaction will be packaged in an Transaction ancestors that contains the metadata so the receiver can check if the transaction is paying enough fees (and other requirements, for example token protocol formats).

TSC: The process you describe shuffles the responsibilities of miners, senders and recipients as we’ve come to know it. Where are we going with this?

JW: The Transaction ancestors specification makes a definitive move away from the legacy payments process the way BTC (and most other blockchain systems) is still doing it: if someone wanted to send me a payment they would send it to the blockchain. To know if my payment has been approved, I would have to scan the blockchain to filter it by transactions that are addressed to me. That process hardly works with BTC’s 1 MB blocks and it’s definitely not going to work with Terabyte-sized blocks. 

Craig Wright has warned about this bottleneck on many occasions. Instead, he pointed out the original plan of Bitcoin was to use a pay-to-IP feature. Unfortunately, BTC removed this feature because it took too much effort to secure it. It’s understandable that this wasn’t addressed in the early days of BTC since most people working on it at the time were only hobbyists doing it in their free time.

But the right way to undertake payments would be for the sender to create the transaction and send it directly to the recipient, similar to the old-school process of paying with a cheque. Using the transaction’s extension data, or SPV Envelope, the recipient would be able to verify if the transaction is valid, before submitting it to the network. Again, this is just like receiving a cheque, validating the signature and identity against the sender’s identity documents, and then taking it to the bank to settle. At present, recipients don’t have access to the extension data needed to validate a transaction, which is why we’re creating the SPV Envelope spec. 

TSC: You’ve told us how the Transaction ancestors work in the context of miner fee policies. How does it affect more complex policies?

JW: OP_PUSH_TX lets a sender force specific requirements into a transaction so miners have to check if it meets those before mining it. These requirements could be that the transaction can only be broadcast if it carries a specific script, like a token script. As OP_PUSH_TX is being done right now, the script being forced into the transaction is often much larger than it needs to be. As a result, the burden of validating the script falls onto miners, and the cost on broadcasters.

With the Transaction ancestors spec implemented, the process can be simplified to one where the receiver checks the validity of the script and only broadcasts it to the network if it qualifies. 

Another area where Transaction ancestors spec is a necessity is that of Payment and State Channels. Although not many people have started using them yet, the Transaction ancestors will be essential for implementing Payment and State Channels successfully. Let’s say you have a transaction that can only be processed if it’s signed by five specific keys. If the receiver simply broadcasts the transaction without validating the signatures, there’s a risk that it will fail once the miners have had a chance to look at it. The client would then have to be notified of the failure, without necessarily knowing which of the variables are invalid. It would be completely unprofessional, frustrating, and a waste of time. This level of fragility is not acceptable for professional or enterprise systems.

Another scenario is transactions that include spending complex scripts. If you’re forwarding transactions directly to miners without properly checking them, that creates room for an attack vector to enter. 

TSC: Why does BSV consider it essential to ‘pre-approve’ transactions if other blockchains go without? 

JW: It depends what your vision for blockchain implementation is. If you’re running it for hobbyists who are prepared to trouble-shoot when something goes off-kilter, it’s all well and good. But the BSV blockchain’s focus is on offering enterprise-level service. We simply can’t afford to settle for ‘happy-paths’, where the tech only works if every variable goes right but falls apart if one tiny thing is done wrong. Implementing standards like the Transaction ancestors and P2P Payment Protocol (P4) specifications makes the BSV blockchain robust enough to cater to enterprise needs.

Professional software needs to cover for all of these edge cases to ensure a smooth user experience and proper scaling. If you’re not handling errors at the earliest possible instance, things will spiral out of control once you try to scale. It’s as Jimmy Nguyen often says: ‘It’s time for Bitcoin to grow up and professionalise.’ 

Follow the development of the Transaction ancestors specification

If you’d like to follow the development of the draft of this spec, make sure you register to get involved and tick the box to be subscribed to the newsletter.