Delivery-date: Tue, 26 Mar 2024 12:15:14 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 26 Mar 2024 12:11:28 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
In-Reply-To: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
Subject: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_69708_410503362.1711480288616"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_69708_410503362.1711480288616
Content-Type: multipart/alternative; 
	boundary="----=_Part_69709_1111808445.1711480288616"

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

Hi Poinsot,

I think fixing the timewarp attack is a good idea, especially w.r.t safety=
=20
implications of long-term timelocks usage.

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

Shall we as a community completely disregard this approach for on-chain=20
settlement throughput scaling ?
Personally, I think you can still design extension-block / side-chains like=
=20
protocols by using other today available
Bitcoin Script mechanisms and get roughly (?) the same security /=20
scalability trade-offs. Shall be fine to me to fix timewarp.

Worst-block validation time is concerning. I bet you can do worst than your=
=20
examples if you're playing with other vectors like
low-level ECC tricks and micro-architectural layout of modern processors.

Consensus invalidation of old legacy scripts was quite controversial last=
=20
time a consensus cleanup was proposed:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.h=
tml

Only making scripts invalid after a given block height (let's say the=20
consensus cleanup activation height) is obviously a
way to solve the concern and any remaining sleeping DoSy unspent coins can=
=20
be handled with  newly crafted and dedicated
transaction-relay rules (e.g at max 1000 DoSy coins can be spent per block=
=20
for a given IBT span).

I think any consensus boundaries on the minimal transaction size would need=
=20
to be done carefully and have all lightweight
clients update their own transaction acceptance logic to enforce the check=
=20
to avoid years-long transitory massive double-spend
due to software incoordination. I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE`=
=20
is implemented correctly by all transaction-relay
backends and it's a mess in this area. Quid if we have  < 64 bytes=20
transaction where the only witness is enforced to be a minimal 1-byte
as witness elements are only used for higher layers protocols semantics  ?=
=20
Shall get its own "only-after-height-X" exemption, I think.

Making coinbase unique by requesting the block height to be enforced in=20
nLocktime, sounds more robust to take a monotonic counter
in the past in case of accidental or provoked shallow reorgs. I can see of=
=20
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=20
DoS vector at mining job distribution and control.

Beyond, I don't deny other mentioned issues (e.g UTXO entries growth limit)=
=20
could be source of denial-of-service but a) I think it's hard
to tell if they're economically neutral on modern Bitcoin use-cases and=20
their plausible evolvability and b) it's already a lot of careful consensus
code to get right :)

Best,
Antoine

Le dimanche 24 mars 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit =
:

> Hey all,
>
> I've recently posted about the Great Consensus Cleanup there:=20
> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710.
>
> I'm starting a thread on the mailing list as well to get comments and=20
> opinions from people who are not on Delving.
>
> TL;DR:
> - i think the worst block validation time is concerning. The mitigations=
=20
> proposed by Matt are effective, but i think we should also limit the=20
> maximum size of legacy transactions for an additional safety margin;
> - i believe it's more important to fix the timewarp bug than people=20
> usually think;
> - it would be nice to include a fix to make coinbase transactions unique=
=20
> once and for all, to avoid having to resort back to doing BIP30 validatio=
n=20
> after block 1,983,702;
> - 64 bytes transactions should definitely be made invalid, but i don't=20
> think there is a strong case for making less than 64 bytes transactions=
=20
> invalid.
>
> Anything in there that people disagree with conceptually?
> Anything in there that people think shouldn't (or don't need to) be fixed=
?
> Anything in there which can be improved (a simpler, or better fix)?
> Anything NOT in there that people think should be fixed?
>
>
> Antoine Poinsot
>

--=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/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com.

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

Hi Poinsot,<div><br /></div><div>I think fixing the timewarp attack is a go=
od idea, especially w.r.t safety implications of long-term timelocks usage.=
</div><div><br /></div><div>The only beneficial case I can remember about t=
he timewarp issue is "forwarding blocks" by maaku for on-chain scaling:</di=
v><div>http://freico.in/forward-blocks-scalingbitcoin-paper.pdf<br /></div>=
<div><br /></div><div>Shall we as a community completely disregard this app=
roach for on-chain settlement throughput scaling ?</div><div>Personally, I =
think you can still design extension-block / side-chains like protocols by =
using other today available</div><div>Bitcoin Script mechanisms and get rou=
ghly (?) the same security / scalability trade-offs. Shall be fine to me to=
 fix timewarp.</div><div><br /></div><div>Worst-block validation time is co=
ncerning. I bet you can do worst than your examples if you're playing with =
other vectors like</div><div>low-level ECC tricks and micro-architectural l=
ayout of modern processors.</div><div><br /></div><div>Consensus invalidati=
on of old legacy scripts was quite controversial last time a consensus clea=
nup was proposed:</div><div>https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2019-March/016714.html<br /></div><div><br /></div><div>Only makin=
g scripts invalid after a given block height (let's say the consensus clean=
up activation height) is obviously a</div><div>way to solve the concern and=
 any remaining sleeping DoSy unspent coins can be handled with =C2=A0newly =
crafted and dedicated</div><div>transaction-relay rules (e.g at max 1000 Do=
Sy coins can be spent per block for a given IBT span).</div><div><br /></di=
v><div>I think any consensus boundaries on the minimal transaction size wou=
ld need to be done carefully and have all lightweight</div><div>clients upd=
ate their own transaction acceptance logic to enforce the check to avoid ye=
ars-long transitory massive double-spend</div><div>due to software incoordi=
nation. I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly=
 by all transaction-relay</div><div>backends and it's a mess in this area. =
Quid if we have =C2=A0&lt; 64 bytes transaction where the only witness is e=
nforced to be a minimal 1-byte</div><div>as witness elements are only used =
for higher layers protocols semantics =C2=A0? Shall get its own "only-after=
-height-X" exemption, I think.</div><div><br /></div><div>Making coinbase u=
nique by requesting the block height to be enforced in nLocktime, sounds mo=
re robust to take a monotonic counter</div><div>in the past in case of acci=
dental or provoked shallow reorgs. I can see of you would have to re-comput=
e a block template, loss a round-trip</div><div>compare to your mining comp=
etitors. Better if it doesn't introduce a new DoS vector at mining job dist=
ribution and control.</div><div><br /></div><div>Beyond, I don't deny other=
 mentioned issues (e.g UTXO entries growth limit) could be source of denial=
-of-service but a) I think it's hard</div><div>to tell if they're economica=
lly neutral on modern Bitcoin use-cases and their plausible evolvability an=
d b) it's already a lot of careful consensus</div><div>code to get right :)=
</div><div><br /></div><div>Best,</div><div>Antoine</div><div><br /></div><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le dimanch=
e 24 mars 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit=C2=A0:<br/=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hey all,
<br>
<br>I&#39;ve recently posted about the Great Consensus Cleanup there: <a hr=
ef=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710" tar=
get=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.=
com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t/great-consensus-cleanu=
p-revival/710&amp;source=3Dgmail&amp;ust=3D1711565663390000&amp;usg=3DAOvVa=
w0H-vWJQFB5_UBHVBwhQ1qE">https://delvingbitcoin.org/t/great-consensus-clean=
up-revival/710</a>.
<br>
<br>I&#39;m starting a thread on the mailing list as well to get comments a=
nd opinions 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&#39;s more important to fix the timewarp bug than people=
 usually 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=
9;t think there is a strong case for making less than 64 bytes transactions=
 invalid.
<br>
<br>Anything in there that people disagree with conceptually?
<br>Anything in there that people think shouldn&#39;t (or don&#39;t need to=
) be fixed?
<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 &=
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/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com</a>.=
<br />

------=_Part_69709_1111808445.1711480288616--

------=_Part_69708_410503362.1711480288616--