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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com.
