From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

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

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

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

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

Consensus invalidati= on of old legacy scripts was quite controversial last time a consensus clea= nup was proposed:
https://lists.linuxfoundation.org/pipermail/bit= coin-dev/2019-March/016714.html

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

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

Making coinbase u= nique by requesting the block height to be enforced in nLocktime, sounds mo= re robust to take a monotonic counter
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
compare to your mining comp= etitors. Better if it doesn't introduce a new DoS vector at mining job dist= ribution and control.

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
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
code to get right :)=

Best,
Antoine

<= div class=3D"gmail_quote">
Le dimanch= e 24 mars 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit=C2=A0:
Hey all,

I've recently posted about the Great Consensus Cleanup there: https://delvingbitcoin.org/t/great-consensus-clean= up-revival/710.

I'm starting a thread on the mailing list as well to get comments a= nd opinions from people who are not on Delving.

TL;DR:
- 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;
- i believe it's more important to fix the timewarp bug than people= usually think;
- 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;
- 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.

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

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.com.=
------=_Part_69709_1111808445.1711480288616-- ------=_Part_69708_410503362.1711480288616--