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.