diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2025-02-11 13:20:10 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-02-11 16:06:00 -0800 |
| commit | 7e3e271b15f406a1800fff392d574150c0f78441 (patch) | |
| tree | bb2c1f064b04b1f1efa2bad789f3c9211b6a1906 | |
| parent | ad9df40000e9e1b2a65db20ac0aeb7c2faa981f8 (diff) | |
| download | pi-bitcoindev-7e3e271b15f406a1800fff392d574150c0f78441.tar.gz pi-bitcoindev-7e3e271b15f406a1800fff392d574150c0f78441.zip | |
Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
| -rw-r--r-- | 81/3d9c471068ade2c71b68020017f600e569a0a6 | 256 |
1 files changed, 256 insertions, 0 deletions
diff --git a/81/3d9c471068ade2c71b68020017f600e569a0a6 b/81/3d9c471068ade2c71b68020017f600e569a0a6 new file mode 100644 index 000000000..0795ab17a --- /dev/null +++ b/81/3d9c471068ade2c71b68020017f600e569a0a6 @@ -0,0 +1,256 @@ +Delivery-date: Tue, 11 Feb 2025 16:06:00 -0800 +Received: from mail-yb1-f187.google.com ([209.85.219.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+bncBC3PT7FYWAMRBXWLV66QMGQEVMB5SXA@googlegroups.com>) + id 1ti0GN-0002yT-D4 + for bitcoindev@gnusha.org; Tue, 11 Feb 2025 16:06:00 -0800 +Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e54da6701d2sf9386865276.0 + for <bitcoindev@gnusha.org>; Tue, 11 Feb 2025 16:05:59 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1739318753; x=1739923553; 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=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=; + b=p5FwEZbmF+d+PTaqd8qw5Jec/vdLOGY5pjMqxtgaJfS7Pb3OqNj5K0Lz7x54YJkhOO + SHJjI6Q0a/JiIPee/vCBuglin26HNFVK6MllzWnaT5Boy6vujdGgm1uP3MLNiRpd2nK6 + xOaoOd1iMW0zMSVfXdr+FqRg6y8m2lWDt5eQuKVBbe2TyuFSnLanVjN0qRdbKg2KpVcI + fzl53aTDak61iRiVQqTLc+ZEfe6gE68ZE0uEHwt46n/M9Yarg404pLqwnyRr/AG83Vrh + pxzJEFNn9wV4Zufpuiz4HWld6Lo/wZ4/adfeJbQpOorrOAfCQG/mq7feDSH1HiESPYwo + M0FQ== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1739318753; x=1739923553; 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=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=; + b=UaB8tKNmO4EOnGYXDVzm7NgJEPCpags4ifnDKv70D/RlrEyGODUBTbezMG5T7xBXUK + i63UJtR5sC+BJOzcBKsvnlnTF/FgWWEsW80VXJlms2LvwmLepsP9q1PFcQEW6Al8hz3I + 3wosbQUw9oMbhEfbsUF02SCD/l39c/RORgD6n+F2l/Q8j+ahPORQqhL9VjP9uNFuev4S + o8ix4rxbY/I/p/n0loXrGVOM4c4P3QujqrwvFpJDEzN4qih49xQLrai/iL4fLCiNGyAy + 7Q5zInuboqgDt5XqYKNR9J372blofUM0BYJqvweRfF5Lj/a42dF47qukIdjygLoQgV7X + m5zw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1739318753; x=1739923553; + 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=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=; + b=q7o3pY2YreVsTECJMKoLvEjH3PRbvEmYM2fltBnz44rAxeCmadNZLJqS1wfAnyZDkE + f6uvitwKLHhq1F/s923ueDzVv4Oi+fG4ZpKHYwQUlBOKNlZznWttmc4vGGGjG1VGJuaE + nqaYmmcnvbANj2U++ZpJGVnf4SlhII8FQ/CyNtlIDI6SuLYgiJY0aZwFo5cfGRiS9yr0 + TYwmN574OAK6aHe8vZgGXk1Nts7kE1A/+dlxDqi++PJ9P/VGxC+BGaJTA+uiSZU3B1Km + R6T4pVS27Iv6D6eUOX+2anS4qhupl4vsfKwv4OvEBc5/sqQG0HJM9LWlt/QVZ/CU8tke + XU/A== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCXgwBwlICcA9ReD5SFupFbFtp7koMvjbPi5lHGr1BQn1S0z/IDepSI6A39Z4E/KyIAGi4CPFEnbOfKI@gnusha.org +X-Gm-Message-State: AOJu0YxOOIglakeIIrXOatoSY3pYlYla+e6mtDg3VMvlZH84eEeY4Dy1 + ZNeio4PbRgNz8tJt6REUqQ4jQ+kNQmyRpRnRYtWX+dwNTkt/assi +X-Google-Smtp-Source: AGHT+IF/rgM5btrl3GRC99CX4WFOwHZdlCPZG2b5mUrF6mO5FOZFjIFb2bUW4zVbzSoKftykpmVBTA== +X-Received: by 2002:a05:6902:2382:b0:e5b:3a7b:1221 with SMTP id 3f1490d57ef6-e5d9f0fcadcmr1304372276.14.1739318753386; + Tue, 11 Feb 2025 16:05:53 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a25:abab:0:b0:e5b:3adb:a133 with SMTP id 3f1490d57ef6-e5b46087878ls290736276.1.-pod-prod-03-us; + Tue, 11 Feb 2025 16:05:49 -0800 (PST) +X-Received: by 2002:a05:690c:30c:b0:6f9:a90a:f7f2 with SMTP id 00721157ae682-6fb1f6c42a8mr17054047b3.34.1739318749688; + Tue, 11 Feb 2025 16:05:49 -0800 (PST) +Received: by 2002:a05:690c:4448:b0:6f9:a930:a709 with SMTP id 00721157ae682-6f9b1de8b9ams7b3; + Tue, 11 Feb 2025 13:20:11 -0800 (PST) +X-Received: by 2002:a05:690c:3687:b0:6f9:50ed:e6eb with SMTP id 00721157ae682-6fb1f27c541mr13924927b3.27.1739308810637; + Tue, 11 Feb 2025 13:20:10 -0800 (PST) +Date: Tue, 11 Feb 2025 13:20:10 -0800 (PST) +From: Antoine Riard <antoine.riard@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <87360fbe-30dd-4e18-acbf-7416c47ebc61n@googlegroups.com> +In-Reply-To: <CAGL6+mFYCKjhD8O1G9diC4pbM=_XubW0YxTfeqyyRpDe9t2fng@mail.gmail.com> +References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com> + <CAGL6+mFYCKjhD8O1G9diC4pbM=_XubW0YxTfeqyyRpDe9t2fng@mail.gmail.com> +Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_331308_116972442.1739308810117" +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_331308_116972442.1739308810117 +Content-Type: multipart/alternative; + boundary="----=_Part_331309_1883248253.1739308810117" + +------=_Part_331309_1883248253.1739308810117 +Content-Type: text/plain; charset="UTF-8" + +Hi Darosior, + +> I believe it is important to bundle all fixes together to make up for the +substantial fixed cost of deploying a soft fork. It also seems absurd to +deploy a soft fork aimed at patching security bugs, but only fix some of +them and lea> ve the protocol partly vulnerable. While it is technically +possible it is not something i want to encourage. + +I don't wish to be dogmatic here, though I believe we have 2 distinct +things. There is (a) to have 4 distinct BIPs for each fix +("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-txn") +and there is (b) to bundle all the fixes together as of course there is +substantial ecosystem coordination cost to deploy a soft fork, even with +BIP9. Getting 4 distinct BIPs, it's of course a bit more work for the soft +fork authors and champions, though I think this avoid too-beefy +ill-written BIP as we already had and undocumented future rules in the +script interpreter code like the SIGPUSHONLY check I was pointing out. + +Apart of this editorial good practice motivation, this also indeed make it +simpler to deploy the fix one by one (of course you can always hack-in +activation code, even if it's single BIP), in the pessimistic scenario in +the future there are no consensus on all the fixes, though only a subset of +the 4 ones. In that optic, yes if we can get in 3 of the 4 fixes in a +bundled soft fork and the remaining one at a latter time, it would be +already a win to reduce the protocol vulnerability exposure. + +It's unlike the Taproot patchset here, each proposed soft-fork fix is +supposed to be addressing a vulnerability of its own, and there is almost +no technical coupling between them (well one could go to argue there is one +among the timewarp fix and the worst-block-validation time, if you go to +consider the maximum DoS surface of a full-node under wall clock time). I +don't think it's a question of wishing what we wished to encourage as the +"ideal" deployment of this set of consensus rules changes, as if there are +good technical reasons to object on 1 fix and no consensus, this shouldn't +prevent to be realistic and go to deploy all the remaining ones for which +there is consensus. + +> Regarding the confiscation surface, please note the specific concerns +raised about the 2019 proposal do not apply to the fix proposed here. The +new approach to mitigating the worst case validation time is extremely +conservative in this regard: no opcodes or other Script functionality get +disabled. Only a limit is introduced at the transaction level, which allows +to pinpoint exactly the harmful behaviour without rendering any innocent +transaction invalid. + +I'm not sure if there is already code, and even a BIP on the +"worst-block-validation-time", though it's unclear to me if the limit aims +to apply on UTXO spends spending lecacy scripts ex post to the activation +(as I think the proposal of few months ago was laying out) or ex ante to +the activation. If the latter one, with a "retro-active" confiscation +surface, I think it's akin to the specific concerns raised in 2019, and if +it's something like that we should be +very careful in the design. + +> As one would expect due to the larger design space available to fix this +issue, this private thread is where most of the discussion would happen. + +There is another point - I'm sharing the practice on not exposing all +experimentation on the worst-block-validation-time, as you never know it's +the wild Internet and there can be always script kiddies at the corner of +the block for unpatched vulnerabilities. On the other hand, we're proposing +to change what is the "consensus" definition of people money, so a bit more +of publicity in rationalizing why the changes are proposed could be +welcome. For clarity I have access on the thread and there is bunch of +other devs. It's always a (hard) question how much info you share on +vulnerabilities in the process of fixing them. + +Anyway, I'll go to review code+BIP(s) for all the fixes, those raised +points are just relevant to keep in mind imho. + +Best, +Antoine R. (nah you're evil, i'm evil, we're all evil, btc is beyond good +and evil) +OTS hash: 0334fb9d557426c4f7d71d3e99bb9badbfd87903 + +-- +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 visit https://groups.google.com/d/msgid/bitcoindev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com. + +------=_Part_331309_1883248253.1739308810117 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Darosior,<br /><br />> I believe it is important to bundle all fixes = +together to make up for the substantial fixed cost of deploying a soft fork= +. It also seems absurd to deploy a soft fork aimed at patching security bug= +s, but only fix some of them and lea> ve the protocol partly vulnerable.= + While it is technically possible it is not something i want to encourage.<= +br /><br />I don't wish to be dogmatic here, though I believe we have 2 dis= +tinct things. There is (a) to have 4 distinct BIPs for each fix ("timewarp"= +/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-txn") and t= +here is (b) to bundle all the fixes together as of course there is substant= +ial ecosystem coordination cost to deploy a soft fork, even with BIP9. Gett= +ing 4 distinct BIPs, it's of course a bit more work for the soft fork autho= +rs and champions, =C2=A0though I think this avoid too-beefy ill-written BIP= + as we already had and undocumented future rules in the script interpreter = +code like the SIGPUSHONLY check I was pointing out.<br /><br />Apart of thi= +s editorial good practice motivation, this also indeed make it simpler to d= +eploy the fix one by one (of course you can always hack-in activation code,= + even if it's single BIP), in the pessimistic scenario in the future there = +are no consensus on all the fixes, though only a subset of the 4 ones. In t= +hat optic, yes if we can get in 3 of the 4 fixes in a bundled soft fork and= + the remaining one at a latter time, it would be already a win to reduce th= +e protocol vulnerability exposure.<br /><br />It's unlike the Taproot patch= +set here, each proposed soft-fork fix is supposed to be addressing a vulner= +ability of its own, and there is almost no technical coupling between them = +(well one could go to argue there is one among the timewarp fix and the wor= +st-block-validation time, if you go to consider the maximum DoS surface of = +a full-node under wall clock time). I don't think it's a question of wishin= +g what we wished to encourage as the "ideal" deployment of this set of cons= +ensus rules changes, as if there are good technical reasons to object on 1 = +fix and no consensus, this shouldn't prevent to be realistic and go to depl= +oy all the remaining ones for which there is consensus.<br /><br />> Reg= +arding the confiscation surface, please note the specific concerns raised a= +bout the 2019 proposal do not apply to the fix proposed here. The new appro= +ach to mitigating the worst case validation time is extremely conservative = +in this regard: no opcodes or other Script functionality get disabled. Only= + a limit is introduced at the transaction level, which allows to pinpoint e= +xactly the harmful behaviour without rendering any innocent transaction inv= +alid.<br /><br />I'm not sure if there is already code, and even a BIP on t= +he "worst-block-validation-time", though it's unclear to me if the limit ai= +ms to apply on UTXO spends spending lecacy scripts ex post to the activatio= +n (as I think the proposal of few months ago was laying out) or ex ante to = +the activation. If the latter one, with a "retro-active" confiscation surfa= +ce, I think it's akin to the specific concerns raised in 2019, and if it's = +something like that we should be<br />very careful in the design.<br /><br = +/>> As one would expect due to the larger design space available to fix = +this issue, this private thread is where most of the discussion would happe= +n. <br /><br />There is another point - I'm sharing the practice on not exp= +osing all experimentation on the worst-block-validation-time, as you never = +know it's the wild Internet and there can be always script kiddies at the c= +orner of the block for unpatched vulnerabilities. On the other hand, we're = +proposing to change what is the "consensus" definition of people money, so = +a bit more of publicity in rationalizing why the changes are proposed could= + be welcome. For clarity I have access on the thread and there is bunch of = +other devs. It's always a (hard) question how much info you share on vulner= +abilities in the process of fixing them.<br /><br />Anyway, I'll go to revi= +ew code+BIP(s) for all the fixes, those raised points are just relevant to = +keep in mind imho.<br /><br />Best,<br />Antoine R. (nah you're evil, i'm e= +vil, we're all evil, btc is beyond good and evil)<br />OTS hash: 0334fb9d55= +7426c4f7d71d3e99bb9badbfd87903<br /> + +<p></p> + +-- <br /> +You received this message because you are subscribed to the Google Groups &= +quot;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">bitcoind= +ev+unsubscribe@googlegroups.com</a>.<br /> +To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com?utm_med= +ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind= +ev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com</a>.<br /> + +------=_Part_331309_1883248253.1739308810117-- + +------=_Part_331308_116972442.1739308810117-- + |