BIP 54: improve and deduplicate parts of rationale and motivation #2170

pull darosior wants to merge 4 commits into bitcoin:master from darosior:bip54_rationale_additions changing 1 files +35 −36

darosior commented at 3:14 PM on May 21, 2026: member
As i'm finalizing the document, i noticed a few places that could be improved:
- Rephrase some paragraphs for better flow
- Link to new posts (for instance the Utreexo BIP)
- De-duplicate content between motivation and rationale: stick to motivating the concept in the motivation, and justifying the approach taken in rationale
- Similarly to #2159, link to an objection about using nLockTime and explain why this approach was taken nonetheless
- Minor improvements (duplicate references, English wording, etc.)
bip-0054: rephrase Timewarp motivation 19caed45a1

bip-0054: more correct worst case validation times

The sentence was misleading, with 'lower end devices' potentially applying to the whole range, and the range itself being understated.

ec24fd371c

murchandamus added the label BIP Update by Owner on May 21, 2026
murchandamus commented at 3:22 PM on May 21, 2026: member

Changes look good to me. Nice clean-up of the descriptions. No nits.

in bip-0054.md:49 in 8a41b0625a outdated

  50 | -Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be
  51 | -performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field
  52 | -allows applications to recover the block height corresponding to a coinbase transaction without
  53 | -having to parse Script.
  54 | +block height 1,983,702[^0]. Resuming [bip-0030][BIP30] validation would unnecessarily increase block
  55 | +validation overhead and preclude alternative full node designs (such as [bip-0182][BIP182] Utreexo).

murchandamus commented at 4:59 PM on May 21, 2026:

Nit: The commit message here describes the Utreexo BIP as published. It is still an open pull request and the BIP itself has not been published yet.

darosior commented at 6:50 PM on May 21, 2026:

Changed "now-published" to "now-proposed".

murchandamus commented at 5:00 PM on May 21, 2026: member

Clicked through the commits now that CI has run and came up with a nit. ;)

bip-0054: rephrase/dedup motivation and rationale for BIP 34 cleanup

The rationale was duplicating some of the motivation. The motivation had a sentence that read weird.
While rephrasing the sentence, take the opportunity to link to the now-proposed Utreexo BIP. Also
remove a duplicate link reference.

b75238ffb3

bip-0054: mention Luke's extranonce concern in rationale 6c61126d74
darosior force-pushed on May 21, 2026
murchandamus approved
murchandamus commented at 7:05 PM on May 21, 2026: member

This is mainly an improvement of the phrasing and collects resolutions on some remarks. There are no changes to the meaning of the specification.

LGTM.
murchandamus merged this on May 21, 2026
murchandamus closed this on May 21, 2026
in bip-0054.md:122 in 6c61126d74
```
 128 | +early [bip-0034][BIP34] violations also allows applications to recover the block height without
 129 | +having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained:
 130 | +the same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both
 131 | +reasoning and client implementation, since the [bip-0030][BIP30] check can be skipped entirely past
 132 | +Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. One person
 133 | +[raised the concern][miningdev nLockTime] that the `nLockTime` field would be an ideal extranonce
```
jonatack commented at 7:13 PM on May 21, 2026:

Should this miningdev nLockTime link be different from the identical one 2 lines below in line 124?

darosior commented at 7:45 PM on May 21, 2026:

Initially i was linking exactly to the two posts, but decided in favour of linking to the thread instead, as this gives a better overview of the discussion. Both Luke's and AJ's points are easy to spot from this link. So this was intentional, it just means "in the same thread".

jonatack commented at 7:50 PM on May 21, 2026:

Ah, ok. From the way it reads, it appears like the intention is to link to each post and as a reader I reckon it would be better, but no big deal.
jonatack commented at 7:15 PM on May 21, 2026: member

Good improvements

Contributors

Labels

Linked (view graph)

#2159 BIP 54: clarify 64-byte transactions item description and rationale