path: root/c1/b17e1fb09cb59baa0e8ed528af2fc267c1e6ab

Delivery-date: Tue, 26 Mar 2024 12:15:14 -0700
Received: from mail-yw1-f187.google.com ([209.85.128.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBON5RSYAMGQEXK7Y4WA@googlegroups.com>)
	id 1rpCGP-0006C3-9X
	for bitcoindev@gnusha.org; Tue, 26 Mar 2024 12:15:13 -0700
Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-60a54004e9fsf104728727b3.3
        for <bitcoindev@gnusha.org>; Tue, 26 Mar 2024 12:15:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1711480507; x=1712085307; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=OVImNhbqOL4fCy7lc+XH7kO9Qi0cHJNOEpY2FQ2ghG8=;
        b=hdA5m2p/BBzGF2iNXILJWjxzkYsY3yU9eN43LDNoUdbNYgSPxDfvBp6zJyQBbfbXJ2
         DRa5VR8CCvCtdvmgvxNY/Bjfqtsgrb44h2TlCHEpR6nkxTRJVPKqTpTpQzi9EhSQQIoO
         k6FrMTqbQKpj0l+w0dbQbJR1dUjfRHdSCmAWM+vZ+G/7iVZ7SCHVMk6GmN0tyILA9Urc
         I+jHfNOhUn0M2Z5g7MeNA7lV0hw3RVxc7n1KrJKypX8/Rq+V3VylvrBluwgwU5xE517O
         mlUiI2whc+IWpRMGPpm1hxPrbvaT6KrQjGyHnjTLtfkZyt2BSPvEYd85CuAZLP61wXBQ
         NKoA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711480507; x=1712085307; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=OVImNhbqOL4fCy7lc+XH7kO9Qi0cHJNOEpY2FQ2ghG8=;
        b=PviVJqss/uEGHwPWKJRGbpK4Xab/iGiIjLPmJosoiNNLTxsA1Xk7IP8MIZwvP+8ghA
         c5WlxgOGgp3TDHq4AcpZknJfaCAv7ZIEBWsRG2Zz4r50WOO1L0EoUUBduE/usOz4kXNR
         vk4mYGbTEQod4qD1b0E0b9QBpJBg9r3zRG+qaZ7dsmdwf62ccRzLfbNgdMperw5SI3Pv
         5xSudcb+1US5N6l/HaJ6vft3K+NOqH8bQ3xQY7NP1JBgNqrJYLO2YSkCIf9f2nFfI+NO
         X+JWWpFtmPEO0Agq85jTMD+rrtAKFQhzUBoYqipLsx7GLGpr1TFSjjtHMKybe3BgSlfb
         ODYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711480507; x=1712085307;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=OVImNhbqOL4fCy7lc+XH7kO9Qi0cHJNOEpY2FQ2ghG8=;
        b=XfT+Jtz1AWgJkajMVFwIa4tAaD+daq5bkh+ZGDxBVsZEMeA/SC1/dDVZ8gGeuugDFG
         0UJsUPzSz+zyUmPk+1cz+KxmZcu/xByYrM55ZSAOm7au+8XDfqb2U7AH5JFcheRzwDiV
         IswxxDhQw4VnQn72QHXuKWY8AsylSXEo//IcDvya/ey5DE5ZSnExKkHaAXQ2UOAxfaGG
         Z3+ypXMLURDvzHE0dygCR9I77Fmyf8vYZ3D56rN24wRDr1TjpEEHh0PffDid8XDMRGf5
         /3fsU31WHr1h7Cyz5q9GGHVC0h75+aIi0plKGjkabhAKAc9gPY9Jq/TcPPU++qnLaFMA
         g+5Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVEVy0iU2nSbJ0IqNQuZEnAJvy2EMQ6R7+eGfeb0WBq33z3NBlK4UMy1BjcWGHutus948U+wd1KOlM+SEEnaCFnKFhP+Y0=
X-Gm-Message-State: AOJu0Yy/QpBX4goNvsVK/JMqFl8PO8WFcsiVEYvdDdwyMGPjbgxyf/i0
	Y6fL6isMliDvSJua8u/VWLrThlGIajuOPzXkmL+sf55zXNii8ArE
X-Google-Smtp-Source: AGHT+IFhmsNC55+bUn/BWnkQ8XllQrK4Aeon+ou+lT6DCxtGoxz6H8DFW9aewGYjztKtDwMfnM5mVg==
X-Received: by 2002:a25:60b:0:b0:dd0:c2a:26f9 with SMTP id 11-20020a25060b000000b00dd00c2a26f9mr8192707ybg.27.1711480506575;
        Tue, 26 Mar 2024 12:15:06 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:e0d2:0:b0:dcc:4b24:c0da with SMTP id x201-20020a25e0d2000000b00dcc4b24c0dals2122144ybg.2.-pod-prod-02-us;
 Tue, 26 Mar 2024 12:15:05 -0700 (PDT)
X-Received: by 2002:a05:6902:1b8e:b0:dd9:3922:fc0e with SMTP id ei14-20020a0569021b8e00b00dd93922fc0emr511299ybb.13.1711480505420;
        Tue, 26 Mar 2024 12:15:05 -0700 (PDT)
Received: by 2002:a05:690c:ecc:b0:611:2a20:d0cc with SMTP id 00721157ae682-613f27c0326ms7b3;
        Tue, 26 Mar 2024 12:11:30 -0700 (PDT)
X-Received: by 2002:a25:ce51:0:b0:dd3:f55f:ff02 with SMTP id x78-20020a25ce51000000b00dd3f55fff02mr426405ybe.1.1711480289043;
        Tue, 26 Mar 2024 12:11:29 -0700 (PDT)
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"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_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&#3=
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--