Re: [bitcoindev] Update on the Great Consensus Cleanup Revival

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4602 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 4949 bytes --]