[DISCUSSION] - BIP 239 about brcs HOT 4 OPEN

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.

from brcs.

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.

from brcs.

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.

from brcs.

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.

from brcs.