[DISCUSSION] - BIP 239

[kyuupichan]

BRC ID

30

Discussion

I have just 2 points:

1. Knowing the previous amount and script is not actually sufficient to validate. You also need to know if the UTXO is from before the genesis activation as the rules are different. Since, as time passes, the number of such UTXOs will only decline, and also since I suspect very few of those UTXOs are actually affected by the validation differences, I suggest that we ignore this. Perhaps a tool that wants to validate should test the post-genesis assumption first, and the pre-genesis assumption second.
2. As written BIP239 does not address coinbase transactions. I think for completeness, and to keep implementations behaving consistently, this should be addressed.

Also, one or two example extended format transactions should be provided in hex for testing purposes.

[sirdeggen]

2. Coinbase handling.

I'm thinking on whether BEEF BRC-62 handles these. Full tx plus a Merkle path, if index within block is 0 then ensure current height - 100 > txHeight?

Thanks for your points.

[kyuupichan]

Yes, coinbases cannot be spent unless their age (at the next block) would be >= 100. I think this description is right - there is a lot of potential for off-by-one with this rule though.

If one is worried about these things, careful attention needs to be paid to non-final transactions too.

There are other validation rules that miners take into account as well; it is not possible for a light wallet to do them all; I think a wallet should focus on covering the important basics and accept that it can still be fooled in corner-cases.

[kyuupichan]

Incidentally (and sorry for this being somewhat off-topic now) - we need nChain / miners to fully document their mempool rules for non-final transactions. There seems to be no documentation on this, and wallets need to know what the guarantees are. For example - if a non-final tx is broadcast, is it retained? Are alternative, entirely separate transactions spending the same inputs rejected? If so, for how long? Do miners reject update tx versions that do not correctly increment all sequence numbers? etc. etc.

[Danconnolly]

I have additional comments on BIP-239.

The spec inserts the outputs that are being spent into the serialized form of the transaction for each input, in the middle of the serialized form of the transaction. Note that:

• the transaction identifier is calculated by hashing the bytes in the original serialized form
• existing transaction validators use the serialized form of the transactions
• the signature generation and verification code depends on the serialized form of the transaction

By including the outputs being spent in the middle of the serialized form of the extended transaction, all of these algorithms break. They all need to be updated to account for, and ignore, the inserted outputs being spent. In the case of calculating the transaction identifier, which is presumably performed for every transaction by every single piece of code dealing with transactions, they need to shuffle and copy bytes around to remove the outputs being spent before the standard hashing functions can be used.

It would have been much easier if the outputs that are being spent are just appended to the end of the transaction.