Prevent future duplicate coinbase transactions as part of Consensus Cleanup

[Antoine Poinsot]

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

[Gary R Krause]

No preference or issues from my perspective on any of the proposed coinbase tx commitments suggestions.

 

 

From: 'Antoine Poinsot' via Bitcoin Mining Development Mailing List <bitcoinm...@googlegroups.com>
Date: Friday, November 22, 2024 at 16:40
To: bitcoinm...@googlegroups.com <bitcoinm...@googlegroups.com>, Bitcoin Development Mailing List <bitco...@googlegroups.com>
Subject: Prevent future duplicate coinbase transactions as part of Consensus Cleanup

Caution: This is an external email and has a suspicious subject or content. Please take care when clicking links or opening attachments. When in doubt, contact your IT Department

 

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