Prevent future duplicate coinbase transactions as part of Consensus Cleanup

Prevent future duplicate coinbase transactions as part of Consensus Cleanup
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2024-11-22 18:54 UTC ( / )
  To: bitcoinminingdev, Bitcoin Development Mailing List



Hi everyone,

As part of my investigation in the Consensus Cleanup proposal [0] i suggested we include a fix for potential duplicate coinbase transactions in the future. This would avoid having to re-enable BIP30 verification after block height 1,983,702.

There are different ways this can be fixed. I am sending this email to reach out to engineers and stakeholders of the mining industry, to learn if some ways of fixing this would make things easier for them than others.

The root issue we are trying to solve is: BIP34 mandated that the block height be committed to by the coinbase transaction as the first element of the scriptSig. However some coinbase transactions which predate BIP34 activation commit to some future height. This leaves a possibility for duplicating the coinbase at these heights, which is why BIP30 validation will need to be resumed in Bitcoin full nodes. See this comment [1] in the Bitcoin Core source code for more detail about this. See this post [2] in my Consensus Cleanup thread for a list of all heights inferior to 10,000,000 that were committed in early coinbase transactions.

An additional motivation for this is that Utreexo nodes cannot perform BIP30 validation [3].

The fix is simply to mandate that each future coinbase transaction whose height was committed differs in some way from the early coinbase transaction that committed to its height. Here is some ways to achieve this:

- require that future coinbase transactions commit to their height minus one in the nLocktime​ field;
- require that future coinbase transactions commit to their height in the nLockTime​ field and also set their nSequence​ to the maximum value (to disable the timelock);
- require that future coinbase transactions have a nVersion​ different than 1​;
- require the witness commitment to always be present, even for blocks with no segwit transaction.

Is any of these preferable? Why? Would any of these make miners' life really hard? For what reason? Do you have an alternative suggestion?

Any input from someone in this industry would be appreciated, either here or on the Delving thread.

Thanks,
Antoine Poinsot

[0] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710

[1] https://github.com/bitcoin/bitcoin/blob/2638fdb4f934be96b7c798dbac38ea5ab8a6374a/src/validation.cpp#L2518-L2588

[2] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4?u=antoinep
[3] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/19?u=antoinep

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRrwNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY%3D%40protonmail.com.