Delivery-date: Wed, 27 Mar 2024 04:00:41 -0700
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.18 as permitted sender) client-ip=185.70.43.18;
Date: Wed, 27 Mar 2024 10:35:51 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Message-ID: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
In-Reply-To: <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com> <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_u70ErIln1yHwbVljTNO079SNuKdPPACFp4808fxkfA"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

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

> Hi Poinsot,

Hi Riard,

> The only beneficial case I can remember about the timewarp issue is "forw=
arding blocks" by maaku for on-chain scaling:
> http://freico.in/forward-blocks-scalingbitcoin-paper.pdf

I would not qualify this hack of "beneficial". Besides the centralization p=
ressure of an increased block frequency, leveraging the timewarp to achieve=
 it would put the network constantly on the Brink of being seriously (fatal=
ly?) harmed. And this sets pernicious incentives too. Every individual user=
 has a short-term incentive to get lower fees by the increased block space,=
 at the expense of all users longer term. And every individual miner has an=
 incentive to get more block reward at the expense of future miners. (And o=
f course bigger miners benefit from an increased block frequency.)

> I think any consensus boundaries on the minimal transaction size would ne=
ed to be done carefully and have all lightweight
> clients update their own transaction acceptance logic to enforce the chec=
k to avoid years-long transitory massive double-spend
> due to software incoordination.

Note in my writeup i suggest we do not introduce a minimum transaction, but=
 we instead only make 64 bytes transactions invalid. See https://delvingbit=
coin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-better=
-fix-10:

> However the BIP proposes to also make less-than-64-bytes transactions inv=
alid. Although they are of no (or little) use, such transactions are not ha=
rmful. I believe considering a type of transaction useless is not sufficien=
t motivation for making them invalid through a soft fork.
>
> Making (exactly) 64 bytes long transactions invalid is also what AJ imple=
mented in [his pull request to Bitcoin-inquisition](https://github.com/bitc=
oin-inquisition/bitcoin/pull/24).

> I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly by al=
l transaction-relay backends and it's a mess in this area.

What type of backend are you referring to here? Bitcoin full nodes reimplem=
entations? These transactions have been non-standard in Bitcoin Core for th=
e past 6 years (commit 7485488e907e236133a016ba7064c89bf9ab6da3).

> Quid if we have < 64 bytes transaction where the only witness is enforced=
 to be a minimal 1-byte
> as witness elements are only used for higher layers protocols semantics ?

This restriction is on the size of the transaction serialized without witne=
ss. So this particular instance would not be affected and whatever the witn=
ess is isn't relevant.

> Making coinbase unique by requesting the block height to be enforced in n=
Locktime, sounds more robust to take a monotonic counter
> in the past in case of accidental or provoked shallow reorgs. I can see o=
f you would have to re-compute a block template, loss a round-trip
> compare to your mining competitors. Better if it doesn't introduce a new =
DoS vector at mining job distribution and control.

Could you clarify? Are you suggesting something else than to set the nLockT=
ime in the coinbase transaction to the height of the block? If so, what exa=
ctly are you referring to by "monotonic counter in the past"?

At any rate in my writeup i suggested making the coinbase commitment mandat=
ory (even when empty) instead for compatibility reasons.

That said, since we could make this rule kick in in 25 years from now, we m=
ight want to just do the Obvious Thing and just require the height in nLock=
Time.

> and b) it's already a lot of careful consensus
> code to get right :)

Definitely. I just want to make sure we are not missing anything important =
if a soft fork gets proposed along these lines in the future.

> Best,
> Antoine
>
> Le dimanche 24 mars 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9cri=
t :
>
>> Hey all,
>>
>> I've recently posted about the Great Consensus Cleanup there: https://de=
lvingbitcoin.org/t/great-consensus-cleanup-revival/710.
>>
>> I'm starting a thread on the mailing list as well to get comments and op=
inions from people who are not on Delving.
>>
>> TL;DR:
>> - i think the worst block validation time is concerning. The mitigations=
 proposed by Matt are effective, but i think we should also limit the maxim=
um size of legacy transactions for an additional safety margin;
>> - i believe it's more important to fix the timewarp bug than people usua=
lly think;
>> - it would be nice to include a fix to make coinbase transactions unique=
 once and for all, to avoid having to resort back to doing BIP30 validation=
 after block 1,983,702;
>> - 64 bytes transactions should definitely be made invalid, but i don't t=
hink there is a strong case for making less than 64 bytes transactions inva=
lid.
>>
>> Anything in there that people disagree with conceptually?
>> Anything in there that people think shouldn't (or don't need to) be fixe=
d?
>> Anything in there which can be improved (a simpler, or better fix)?
>> Anything NOT in there that people think should be fixed?
>>
>> Antoine Poinsot
>
> --
> 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 on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com.

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1=
yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div>
        <div class=3D"protonmail_quote"><blockquote class=3D"protonmail_quo=
te" type=3D"cite">
            Hi Poinsot,</blockquote><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); background-color: rgb(255, 255, 255);">Hi Riard=
,<br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><br><b=
lockquote class=3D"protonmail_quote" type=3D"cite"><div>The only beneficial=
 case I can remember about the timewarp issue is "forwarding blocks" by maa=
ku for on-chain scaling:</div><div>http://freico.in/forward-blocks-scalingb=
itcoin-paper.pdf<br></div></blockquote><div style=3D"font-family: Arial, sa=
ns-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-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">I wou=
ld not qualify this hack of "beneficial". Besides the centralization pressu=
re of an increased block frequency, leveraging the timewarp to achieve it w=
ould put the network constantly on the Brink of being seriously (fatally?) =
harmed. And this sets pernicious incentives too. Every individual user has =
a short-term incentive to get lower fees by the increased block space, at t=
he expense of all users longer term. And every individual miner has an ince=
ntive to get more block reward at the expense of future miners. (And of cou=
rse bigger miners benefit from an increased block frequency.)<br></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><br><blockquote class=
=3D"protonmail_quote" type=3D"cite"><div>I think any consensus boundaries o=
n the minimal transaction size would need to be done carefully and have all=
 lightweight</div><div>clients update their own transaction acceptance logi=
c to enforce the check to avoid years-long transitory massive double-spend<=
/div><div>due to software incoordination.</div></blockquote><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgr=
ound-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(2=
55, 255, 255);">Note in my writeup i suggest we do not introduce a minimum =
transaction, but we instead only make 64 bytes transactions invalid. See <s=
pan><a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://delvingbitcoin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-=
with-a-better-fix-10">https://delvingbitcoin.org/t/great-consensus-cleanup-=
revival/710#can-we-come-up-with-a-better-fix-10</a></span>:</div><blockquot=
e style=3D"border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200=
, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div style=3D"=
font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backg=
round-color: rgb(255, 255, 255);"><p>However the BIP proposes to also make =
less-than-64-bytes transactions
 invalid. Although they are of no (or little) use, such transactions are
 not harmful. I believe considering a type of transaction useless is not
 sufficient motivation for making them invalid through a soft fork.</p><p>M=
aking (exactly) 64 bytes long transactions invalid is also what AJ implemen=
ted in <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/24">h=
is pull request to Bitcoin-inquisition</a>.</p></div></blockquote><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><br></div><blockquote=
 class=3D"protonmail_quote" type=3D"cite"><div>I doubt `MIN_STANDARD_TX_NON=
_WITNESS_SIZE` is implemented correctly by all transaction-relay backends a=
nd it's a mess in this area.</div></blockquote><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: r=
gb(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)=
;">What type of backend are you referring to here? Bitcoin full nodes reimp=
lementations? These transactions have been non-standard in Bitcoin Core for=
 the past 6 years (commit <span>7485488e907e236133a016ba7064c89bf9ab6da3</s=
pan>).<br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14=
px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><=
div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Qui=
d if we have  &lt; 64 bytes transaction where the only witness is enforced =
to be a minimal 1-byte</div><div>as witness elements are only used for high=
er layers protocols semantics  ?</div></blockquote><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-colo=
r: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial, sans-se=
rif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, =
255);">This restriction is on the size of the transaction serialized withou=
t witness. So this particular instance would not be affected and whatever t=
he witness is isn't relevant.<br></div><div style=3D"font-family: Arial, sa=
ns-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-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br><=
/div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Making coinb=
ase unique by requesting the block height to be enforced in nLocktime, soun=
ds more robust to take a monotonic counter</div><div>in the past in case of=
 accidental or provoked shallow reorgs. I can see of you would have to re-c=
ompute a block template, loss a round-trip</div><div>compare to your mining=
 competitors. Better if it doesn't introduce a new DoS vector at mining job=
 distribution and control.</div></blockquote><div style=3D"font-family: Ari=
al, 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; f=
ont-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"=
>Could you clarify? Are you suggesting something else than to set the nLock=
Time in the coinbase transaction to the height of the block? If so, what ex=
actly are you referring to by "monotonic counter in the past"?</div><div st=
yle=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-famil=
y: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-colo=
r: rgb(255, 255, 255);">At any rate in my writeup i suggested making the co=
inbase commitment mandatory (even when empty) instead for compatibility rea=
sons.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div s=
tyle=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0=
); background-color: rgb(255, 255, 255);">That said, since we could make th=
is rule kick in in 25 years from now, we might want to just do the Obvious =
Thing and just require the height in nLockTime.<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);"><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"=
>&nbsp;and b) it's already a lot of careful consensus<div>code to get right=
 :)</div></blockquote><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 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);">Definitely. I just wan=
t to make sure we are not missing anything important if a soft fork gets pr=
oposed along these lines in the future.<br></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-seri=
f; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 25=
5);"><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Be=
st,</div><div>Antoine</div><div><br></div><div class=3D"gmail_quote"><div c=
lass=3D"gmail_attr" dir=3D"auto">Le dimanche 24 mars 2024 =C3=A0 19:06:57 U=
TC, Antoine Poinsot a =C3=A9crit :<br></div><blockquote style=3D"margin: 0 =
0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" c=
lass=3D"gmail_quote">Hey all,
<br>
<br>I've recently posted about the Great Consensus Cleanup there: <a data-s=
aferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvin=
gbitcoin.org/t/great-consensus-cleanup-revival/710&amp;source=3Dgmail&amp;u=
st=3D1711565663390000&amp;usg=3DAOvVaw0H-vWJQFB5_UBHVBwhQ1qE" rel=3D"norefe=
rrer nofollow noopener" target=3D"_blank" href=3D"https://delvingbitcoin.or=
g/t/great-consensus-cleanup-revival/710">https://delvingbitcoin.org/t/great=
-consensus-cleanup-revival/710</a>.
<br>
<br>I'm starting a thread on the mailing list as well to get comments and o=
pinions from people who are not on Delving.
<br>
<br>TL;DR:
<br>- i think the worst block validation time is concerning. The mitigation=
s proposed by Matt are effective, but i think we should also limit the maxi=
mum size of legacy transactions for an additional safety margin;
<br>- i believe it's more important to fix the timewarp bug than people usu=
ally think;
<br>- it would be nice to include a fix to make coinbase transactions uniqu=
e once and for all, to avoid having to resort back to doing BIP30 validatio=
n after block 1,983,702;
<br>- 64 bytes transactions should definitely be made invalid, but i don't =
think there is a strong case for making less than 64 bytes transactions inv=
alid.
<br>
<br>Anything in there that people disagree with conceptually?
<br>Anything in there that people think shouldn't (or don't need to) be fix=
ed?
<br>Anything in there which can be improved (a simpler, or better fix)?
<br>Anything NOT in there that people think should be fixed?
<br>
<br>
<br>Antoine Poinsot
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://groups.=
google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googl=
egroups.com</a>.<br>

        </blockquote><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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-Ko=
SplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1y=
uUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com</a>.<br />

--b1_u70ErIln1yHwbVljTNO079SNuKdPPACFp4808fxkfA--