Hello devs,
Writing this post to do a summary of where from my viewpoint
BIP 54 is, in terms of technical readiness, and what are the
remaining steps to be done, to move it toward its technical
finalization and after that to activation. Indeed, it goes
without saying it's representing my viewpoint only.
Back on the chronological timeline, the great consensus cleanup
was put back on the table by Poinsot at the end of '23 and
beginning of '24 [0]. The aim of the consensus changes is to
fix long known security issues among bitcoin protocol devs,
even if there is a divergence of viewpoints among them on
their severities, and necessity of a consensus patch.
Those issues are (a) the timewarp attack, (b) the long block
validation time arising for pre-segwit scripts, (c) the merkle
tree malleability with 64-byte transactions and (d) the possibility
of duplicate coinbase transactions.
There were numerous design discussions on the best way to solve
each issue [1]. During those discussions, it has been made the
point, that it might be necessary to fix more advanced variants
of some attack, notably the Murch-Zawy one [2]. In parallel,
investigations were made on the private Delving Bitcoin thread
on the worst-case evaluations for the long block validation time.
Early '25, a BIP draft was proposed to the community [3]. It
turns out that the new rule to remove 64-byte transactions was
(and is still) the most argued against, by some devs. After
those conversations, a reference implementation was proposed
with test vectors in late '25 [4].
The work was done to address more open technical concerns from
different people beginning of '26, notably on the encoding of
the height in the coinbase transaction nlocktime [5]. Public
demo of the severity of the long block validation time was made
on signet [6]. More conversations still arised about the 64-byte
transactions [7].
Those are the main elements on the design conversations about
BIP 54 that I can remember from my memory, while of course there
are more design conversations that did happen not listed here.
A pull request on bitcoin core has been opened to implement
BIP54 and it is currently under review and testing [8]. There
is also ongoing work in btcd to implement the BIP and exercise
inter-compatibility [9]. I think there is no ongoing implementation
for libbitcoin, though as said I would be willing to contribute
to the review of one there.
Moving BIP54 past the finish line, in my view, would necessitate
resolving the open technical conservations, especially on the
disagreement about the 64 bye transactions. Apart from the high
level technical conversations calling for progress, more review
and testing of the reference implementation is obviously needed.
More sound review and testing is always better, higher we
set the technical bar, better we're while staying realistic on
the process. Testing inter-compatibility with one or more other
implementations is likely also valuable, to assert there is no
shortcoming with the design.
Beyond, though that's might be my personal view only, some parts
of the BIP would be better to be more documented for any wallet
or off-chain protocol, in function of what they're doing it's
good for them to be aware of the proposed new 2500 pre-segwit
script tx limit, and the 64 byte outlawing rule if it slips in.
Overall, I think it's good to invite skilled eyes that wish to
do so to go over the full conceptual BIP 54 design, what they
agree with, what they disagree with, what could be improved and
goes to publish their grounded analysis on their personal blog,
or whatever. A standard of review that was echoed in the past [10].
Doing more real-live testing of the vulnerabilities like it has been
done on signet might be very valuable again. Apart of the activation
logic, of which the conversation can be deferred later on, what else
would be technically valuable to advance the conversation ?
Minding all of that, and with previous experience of the design,
review and activation cycle of the schnorr / taproot change, it
might sounds realistic to slowly start to think about an activation
of BIP 54 during S2 2027. Why not if the community consensus is
present by then, and of course no "force majeure" ou sh*t hit the
fan too much (as it happens in the bitcoin world).
I'm only speaking for myself, so everyone else in the (bitcoin)
world is free to respectfully disagree with the present viewpoint.
Hopefully, at least it is useful to advance the conversation and
not being the BIP champion it's easier for me to do such a call.
Looking on a long term perspective, there are other consensus
changes that will be likely very also valuable in the future be
it post quantum or other security fixes, and imo it's better as
a community we don't sleep on them.
Cheers,
Antoine
OTS hash: dbc7c36dbce85e4885b4d140bb90a1d775176b7ec60753d02a655e42418062bb
[0]
https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo[1]
https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710[2]
https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062[3]
https://groups.google.com/g/bitcoindev/c/0tSvml90Qcw[4]
https://groups.google.com/g/bitcoindev/c/1XEtmIS_XRc[5]
https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg[6]
https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367[7]
https://groups.google.com/g/bitcoindev/c/iCuq6bFKt5Y[8]
https://github.com/bitcoin/bips/pull/1800[9]
https://github.com/btcsuite/btcd/pull/2537[10]
https://gnusha.org/pi/bitcoindev/CAGpPWDbbZ7PEpr4iwYwBn+5QcjjCx8qmTZVB98i2Z=UwDfwaTQ@mail.gmail.com/