Repository navigation
bLIP: move to bits 266/267, link the taproot extension BOLT, and three notes - #1
Conversation
Bits 264/265 are already claimed by lightning#73 (option_path_queries), open since 2026-07-15 and mergeable. Only merged reservations show in bLIP 2 on master, so the next-free pair reads as 264/265 when it is not. Of the pairs above 263, 266/267 and 268/269 are the only ones no open PR claims; 270/271 goes to lightning#56. Simple taproot channels is no longer a proposal: lightning/bolts#995 merged on 2026-05-04 as bolt-simple-taproot.md. Refer to the extension BOLT and link it, and reflow the paragraph. Also fix a comma splice in Per-commitment points, and pad the bLIP 2 row to the table's columns.
|
@davelund110 — review of The one that needs action regardless of the rest: bits 264/265 are already claimed by lightning/blips#73, open since July and mergeable. bLIP 2 on The crypto checks out — the shachain/SHA256 argument and the MuSig2 nonce-to-key-share leak are both right. Three judgement calls are in the PR description rather than the diff, since they are yours as champion. One I could not fix from here: |
|
Thanks René, great review! 264/265 would have clashed with lightning#73, so that was a real catch. Merged, and the lnd and CLN branches are on 266/267 too. I've added your three notes to the bLIP (storage growth, static backups, the 34-byte channel_type), and the commits are now in my name. |
2 participants
Review of
independent-secrets. The crypto holds up — I checked bothload-bearing claims and they're right — so this is the mechanical half
only. The judgement calls are below the diff, for you to take or leave.
In the diff
Bits 264/265 are already taken. lightning/blips#73
(
option_path_queries, @brh28) claims them — open since 2026-07-15,not a draft,
mergeable_state=clean. The trap is that bLIP 2 onmasteronly lists merged reservations, so 262/263 → 729 looks likeopen space while 28 open PRs are quietly staking claims in it. Surveying
every open PR that touches
blip-0002.md:Moved to 266/267, the lowest uncontested pair. Worth re-checking at
PR time regardless.
Simple taproot channels isn't a proposal any more. lightning/bolts#995
merged on 2026-05-04 as
bolt-simple-taproot.md. The sectioncalled it "the simple taproot channel proposal" twice, unlinked. Now
refers to the extension BOLT and links it. Your description of its
nonce scheme is accurate against the merged text — a second shachain
HMAC'd from the revocation root — and this helps the argument: you're
amending something normative, not speculating against a draft.
Plus a comma splice in Per-commitment points, and the bLIP 2 row
padded to the table's columns.
Not in the diff — your call as champion
1. Unbounded receiver storage is the objection you'll get. The
Rationale spends one sentence on it: "adds to existing storage rather
than creating a new kind." True of LDK and CLN, but it undersells the
case — the shachain exists precisely so secrets are O(1) while the rest
is pruneable. The commitment number stays 48 bits, so the ceiling is
2^48 x 32 B ~ 9 PB, with no cap to negotiate and no
MAY fail the channelescape. The only out is not setting the bit, which line 36'sSHOULDpushes against. A paragraph conceding the growth and namingthat opt-out as deliberate would close the hole before someone opens it.
2. Static channel backups silently stop being able to punish. The
Rationale notes an SCB with the compact representation "can still punish
any state revoked by a seed-based peer" — and never states the converse.
Against an independent-secrets peer, a restored node can't derive any
secret it didn't persist, so breach punishment is gone. That belongs in
Backwards Compatibility, which currently covers only the downgrade
hazard.
3. Any bit above 255 costs 34 bytes in
channel_type. This would bethe first merged bLIP to define a
T-context bit (no merged bLIP usesone; only lightning#70 also tries). The highest channel_type bit in use today is
option_zeroconfat 50/51, so the vector is <= 7 bytes; bit 266 needs267 bits, so 34. And it's unavoidable — bLIP 2 reserves 0-255 for the
BOLTs. Either concede it in the Rationale, or treat it as an argument
for going straight to the BOLTs, which Universality already gestures
at. Multi-signer nodes need every peer to accept this anyway.
One thing I can't fix from here
a36ae6fis authoredClaude <noreply@anthropic.com>and carriesCo-Authored-ByandClaude-Sessiontrailers, while the bLIP'sAuthor:is you. That needs an amend on your side before the upstreamPR — it'll be the first thing a bLIP editor sees.
Conformance is otherwise clean, for the record: preamble fields and
order match bLIP 4/32/42, the Specification-before-Motivation layout
matches bLIP 4 and 25,
CC0is one of the two bLIP 1 permits, andContext: INTis right —Tis a real BOLT 9 letter andINTisexactly what
option_anchors,option_scid_aliasandoption_zeroconfuse. Expect someone to query theIanyway: bLIP 2'sown prose glosses it as the BOLT 11 context while half its rows mean
init. That inconsistency is upstream's, not yours.