From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <87360fbe-30dd-4e18-acbf-7416c47ebc61n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

> 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 />
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.

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.

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.

> 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.

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
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 happe= n.

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.

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.

Best,
Antoine R. (nah you're evil, i'm e= vil, we're all evil, btc is beyond good and evil)
OTS hash: 0334fb9d55= 7426c4f7d71d3e99bb9badbfd87903

--
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 visit https://groups.google.com/d/msgid/bitcoind= ev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com.
------=_Part_331309_1883248253.1739308810117-- ------=_Part_331308_116972442.1739308810117--