public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: "bitcoinminingdev@googlegroups•com"
	<bitcoinminingdev@googlegroups•com>,
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Prevent future duplicate coinbase transactions as part of Consensus Cleanup
Date: Fri, 22 Nov 2024 18:54:50 +0000	[thread overview]
Message-ID: <cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRrwNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY=@protonmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 6654 bytes --]

                 reply	other threads:[~2024-11-22 20:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRrwNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY=@protonmail.com' \
    --to=bitcoindev@googlegroups.com \
    --cc=bitcoinminingdev@googlegroups$(echo .)com \
    --cc=darosior@protonmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox