Delivery-date: Fri, 22 Nov 2024 12:14:12 -0800
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.137 as permitted sender) client-ip=185.70.40.137;
Date: Fri, 22 Nov 2024 18:54:50 +0000
To: "bitcoinminingdev@googlegroups.com" <bitcoinminingdev@googlegroups.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Prevent future duplicate coinbase transactions as part
 of Consensus Cleanup
Message-ID: <cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRrwNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY=@protonmail.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_hmyRTWFCpe5okwOhHIutAI6oGrHM5EMO0jRWjVRLnc"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--b1=_hmyRTWFCpe5okwOhHIutAI6oGrHM5EMO0jRWjVRLnc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

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

There are different ways this can be fixed. I am sending this email to reac=
h out to engineers and stakeholders of the mining industry, to learn if som=
e 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 hei=
ght be committed to by the coinbase transaction as the first element of the=
 scriptSig. However some coinbase transactions which predate BIP34 activati=
on commit to some future height. This leaves a possibility for duplicating =
the coinbase at these heights, which is why BIP30 validation will need to b=
e resumed in Bitcoin full nodes. See this comment [1] in the Bitcoin Core s=
ource code for more detail about this. See this post [2] in my Consensus Cl=
eanup thread for a list of all heights inferior to 10,000,000 that were com=
mitted in early coinbase transactions.

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

The fix is simply to mandate that each future coinbase transaction whose he=
ight 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 on=
e in the nLocktime=E2=80=8B field;
- require that future coinbase transactions commit to their height in the n=
LockTime=E2=80=8B field and also set their nSequence=E2=80=8B to the maximu=
m value (to disable the timelock);
- require that future coinbase transactions have a nVersion=E2=80=8B differ=
ent than 1=E2=80=8B;
- 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 reall=
y hard? For what reason? Do you have an alternative suggestion?

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

Thanks,
Antoine Poinsot

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

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

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

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRr=
wNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY%3D%40protonmail.com.

--b1=_hmyRTWFCpe5okwOhHIutAI6oGrHM5EMO0jRWjVRLnc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);">Hi everyone,</div><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); =
background-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family:=
 Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color:=
 rgb(255, 255, 255);">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 veri=
fication after block height 1,983,702.</div><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(=
255, 255, 255);"><br></div><div style=3D"font-family: Arial, sans-serif; fo=
nt-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">=
There are different ways this can be fixed. I am sending this email to reac=
h out to engineers and stakeholders of the mining industry, to learn if som=
e ways of fixing this would make things easier for them than others.</div><=
div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0,=
 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style=3D"font=
-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgroun=
d-color: rgb(255, 255, 255);">The root issue we are trying to solve is: BIP=
34 mandated that the block height be committed to by the coinbase transacti=
on as the first element of the scriptSig. However some coinbase transaction=
s which predate BIP34 activation commit to some future height. This leaves =
a possibility for duplicating the coinbase at these heights, which is why B=
IP30 validation will need to be resumed in Bitcoin full nodes. See this com=
ment [1] in the Bitcoin Core source code for more detail about this. See th=
is post [2] in my Consensus Cleanup thread for a list of all heights inferi=
or to 10,000,000 that were committed in early coinbase transactions.</div><=
div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0,=
 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style=3D"font=
-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgroun=
d-color: rgb(255, 255, 255);">An additional motivation for this is that Utr=
eexo nodes cannot perform BIP30 validation [3].<br></div><div style=3D"font=
-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgroun=
d-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255,=
 255, 255);">The fix is simply to mandate that each future coinbase transac=
tion whose height was committed  differs in some way from the early coinbas=
e transaction that committed to its height. Here is some ways to achieve th=
is:</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; col=
or: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><ul style=3D"margi=
n-top: 0px; margin-bottom: 0px;" data-editing-info=3D"{&quot;orderedStyleTy=
pe&quot;:1,&quot;unorderedStyleType&quot;:2}"><li style=3D"list-style-type:=
 &quot;- &quot;;"><span>require that future coinbase transactions commit to=
 their height minus one in the <code>nLocktime</code>=E2=80=8B field;</span=
></li><li style=3D"list-style-type: &quot;- &quot;;"><span>require that fut=
ure coinbase transactions commit to their height in the <code>nLockTime</co=
de>=E2=80=8B field and also set their <code>nSequence</code>=E2=80=8B to th=
e maximum value (to disable the timelock);</span></li><li style=3D"list-sty=
le-type: &quot;- &quot;;"><span>require that future coinbase transactions h=
ave a <code>nVersion</code>=E2=80=8B different than <code>1</code>=E2=80=8B=
;</span></li><li style=3D"list-style-type: &quot;- &quot;;"><span>require t=
he witness commitment to always be present, even for blocks with no segwit =
transaction.</span></li></ul><div><br></div><div>Is any of these preferable=
? Why? Would any of these make miners' life really hard? For what reason? D=
o you have an alternative suggestion?</div><div><br></div><div>Any input fr=
om someone in this industry would be appreciated, either here or on the Del=
ving thread.</div><div><br></div><div>Thanks,<br>Antoine Poinsot<br></div><=
/div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: =
rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); b=
ackground-color: rgb(255, 255, 255);">[0] <span><a target=3D"_blank" rel=3D=
"noreferrer nofollow noopener" href=3D"https://delvingbitcoin.org/t/great-c=
onsensus-cleanup-revival/710">https://delvingbitcoin.org/t/great-consensus-=
cleanup-revival/710</a><br></span></div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255,=
 255, 255);"><span>[1] <span><a target=3D"_blank" rel=3D"noreferrer nofollo=
w noopener" href=3D"https://github.com/bitcoin/bitcoin/blob/2638fdb4f934be9=
6b7c798dbac38ea5ab8a6374a/src/validation.cpp#L2518-L2588">https://github.co=
m/bitcoin/bitcoin/blob/2638fdb4f934be96b7c798dbac38ea5ab8a6374a/src/validat=
ion.cpp#L2518-L2588</a></span><br></span></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: r=
gb(255, 255, 255);">[2] <span><a target=3D"_blank" rel=3D"noreferrer nofoll=
ow noopener" href=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-r=
evival/710/4?u=3Dantoinep">https://delvingbitcoin.org/t/great-consensus-cle=
anup-revival/710/4?u=3Dantoinep</a></span></div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: =
rgb(255, 255, 255);">[3] <span><a target=3D"_blank" rel=3D"noreferrer nofol=
low noopener" href=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-=
revival/710/19?u=3Dantoinep">https://delvingbitcoin.org/t/great-consensus-c=
leanup-revival/710/19?u=3Dantoinep</a></span><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6M=
VRhbzJExPRrwNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
cLJjA4Em1sfbLHBctwsPUvquk8uMGGnXt2zGx7mn_JNu5F-HULjtdsBQjX9VET6MVRhbzJExPRr=
wNKBeLV1S30uEgCtFiBmMPVuzTFVNxkY%3D%40protonmail.com</a>.<br />

--b1=_hmyRTWFCpe5okwOhHIutAI6oGrHM5EMO0jRWjVRLnc--