Update outdated BOLT quotes in channel open/close handling.
What the developer wrote
Authored by Rusty Russell
Update outdated BOLT quotes in channel open/close handling.
Some of these are malformed (thus were unchecked!), some are from the
stricter interpretation of `...` which won't cross section boundaries.
Several BOLT quotes had drifted from the current spec text:
- connectd/queries.c: BOLT #7 uses 'full_information' not 'complete';
remove a second quote that referenced query_channel_range but was
actually wrong (that requirement is for query_short_channel_ids).
- lightningd/dual_open_control.c: channel reserve is 1% rounded down
(not just 1%); witness weight check now says SHOULD broadcast rather
than MUST fail; RBF quotes simplified to match actual BOLT wording.
- openingd/openingd.c: 'The sending node' became 'The sender';
invalid signature response now says MUST send warning/error not just
MUST fail the channel.
- openingd/dualopend.c: same invalid-signature quote as openingd.c.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
What changed, and why it matters
This commit updates code comments that quote the Lightning Network specification (BOLT) in four files. Most changes are cosmetic: fixing outdated wording, malformed quote markers, and removing one incorrect quote. One change in connectd/queries.c removes a stale BOLT requirement comment but does not alter the actual behavior, which already replies with sync_complete=false for an unknown chain. Another change in dual_open_control.c updates a comment about what to do when a transaction's effective feerate is too low, but the surrounding code still calls a failure path. Overall, the commit is primarily documentation cleanup and does not appear to introduce or fix a security vulnerability on its own.
No immediate security action required. Treat as a normal code-comment maintenance commit. Reviewers may want to verify separately that the implementation behavior in dual_open_control.c's feerate handling and RBF validation actually matches the updated BOLT requirements, since the commit only updates comments and does not change the control flow.
Security signals we found
Comment-only/spec-alignment changes with no functional code changes visible in the diff
One stale/incorrect BOLT quote removed in connectd/queries.c, but behavior already matched the correct interpretation
Updated BOLT quotes in dual_open_control.c around feerate and RBF failure conditions, but surrounding failure logic remains
No new input validation, bounds checks, memory safety changes, or cryptographic changes present in the diff
Evidence from the diff
The commit updates BOLT quotation comments in connectd/queries.c, lightningd/dual_open_control.c, openingd/dualopend.c, and openingd/openingd.c. In connectd/queries.c, the comment for handle_query_short_channel_ids is corrected to use ‘full_information’ instead of ‘complete’, and a misplaced/wrong BOLT quote in handle_query_channel_range is replaced with a plain code comment. In dual_open_control.c, comments for channel reserve calculation, witness weight/feerate handling, and RBF validation are updated to match current BOLT wording. In openingd.c and dualopend.c, comments around invalid signature handling are updated. The actual control flow and function calls are largely unchanged; the commit is comment/spec-alignment cleanup. There is no direct diff evidence of a functional security fix or vulnerability introduction.
Changed components
connectd/queries.clightningd/dual_open_control.copeningd/dualopend.copeningd/openingd.cInspect captured patch +50 / −49
diff --git a/connectd/queries.c b/connectd/queries.c
index 59f2bf5..09f7897 100644
--- a/connectd/queries.c
+++ b/connectd/queries.c
@@ -294,12 +294,12 @@ void handle_query_short_channel_ids(struct peer *peer, const u8 *msg)
} else
flags = NULL;
- /* BOLT #7
+ /* BOLT #7:
*
* The receiver:
* ...
* - if does not maintain up-to-date channel information for `chain_hash`:
- * - MUST set `complete` to 0.
+ * - MUST set `full_information` to 0.
*/
if (!bitcoin_blkid_eq(&chainparams->genesis_blockhash, &chain)) {
status_peer_debug(&peer->id,
@@ -724,13 +724,7 @@ void handle_query_channel_range(struct peer *peer, const u8 *msg)
else
query_option_flags = 0;
- /* BOLT #7
- *
- * The receiver of `query_channel_range`:
- * ...
- * - if does not maintain up-to-date channel information for `chain_hash`:
- * - MUST set `complete` to 0.
- */
+ /* Unknown chain_hash: reply with sync_complete=false. */
if (!bitcoin_blkid_eq(&chainparams->genesis_blockhash, &chain_hash)) {
status_peer_debug(&peer->id,
"query_channel_range with chainhash %s",
diff --git a/lightningd/dual_open_control.c b/lightningd/dual_open_control.c
index 3ea21b3..7c440e5 100644
--- a/lightningd/dual_open_control.c
+++ b/lightningd/dual_open_control.c
@@ -1178,12 +1178,12 @@ static struct amount_sat calculate_reserve(struct channel_config *their_config,
{
struct amount_sat reserve, dust_limit;
- /* BOLT #2
+ /* BOLT #2:
*
- * The channel reserve is fixed at 1% of the total channel balance
- * rounded down (sum of `funding_satoshis` from `open_channel2`
- * and `accept_channel2`) or the `dust_limit_satoshis` from
- * `open_channel2`, whichever is greater.
+ * Instead, the channel reserve is fixed at 1% of the total channel balance
+ * (`open_channel2`.`funding_satoshis` + `accept_channel2`.`funding_satoshis`)
+ * rounded down to the nearest whole satoshi or the `dust_limit_satoshis`,
+ * whichever is greater.
*/
reserve = amount_sat_div(funding_total, 100);
dust_limit = opener == LOCAL ?
@@ -1811,12 +1811,16 @@ static void handle_peer_tx_sigs_sent(struct subd *dualopend,
return;
}
- /* BOLT #2
- * The receiving node: ...
- * - MUST fail the channel if:
- * - the `witness_stack` weight lowers the
- * effective `feerate` below the agreed upon
- * transaction `feerate`
+ /* BOLT #2:
+ *
+ * The receiving node:
+ * ...
+ * - if the `witness` weight lowers the effective `feerate`
+ * below the *opener*'s feerate for the funding transaction
+ * and the effective `feerate` is determined by the receiving
+ * node to be insufficient for getting the transaction
+ * confirmed in a timely manner:
+ * - SHOULD broadcast their commitment transaction, closing the channel
*/
if (!feerate_satisfied(inflight->funding_psbt,
inflight->funding->feerate)) {
@@ -2170,12 +2174,16 @@ static void handle_peer_tx_sigs_msg(struct subd *dualopend,
return;
}
- /* BOLT #2
- * The receiving node: ...
- * - MUST fail the channel if:
- * - the `witness_stack` weight lowers the
- * effective `feerate` below the agreed upon
- * transaction `feerate`
+ /* BOLT #2:
+ *
+ * The receiving node:
+ * ...
+ * - if the `witness` weight lowers the effective `feerate`
+ * below the *opener*'s feerate for the funding transaction
+ * and the effective `feerate` is determined by the receiving
+ * node to be insufficient for getting the transaction
+ * confirmed in a timely manner:
+ * - SHOULD broadcast their commitment transaction, closing the channel
*/
if (!feerate_satisfied(inflight->funding_psbt,
inflight->funding->feerate)) {
@@ -2307,10 +2315,12 @@ static void handle_validate_rbf(struct subd *dualopend,
memset(inputs_present, true, tal_bytelen(inputs_present));
/* BOLT #2:
- * The receiving node: ...
- * - MUST fail the negotiation if: ...
- * - the transaction does not share at least one input with
- * each previous funding transaction
+ *
+ * - if this is an RBF attempt:
+ * - MUST fail the negotiation if:
+ * ...
+ * - the transaction does not share at least one input with
+ * each previous funding transaction
*/
list_for_each(&channel->inflights, inflight, list) {
/* Remove every non-matching input from set */
@@ -2355,11 +2365,11 @@ static void handle_validate_rbf(struct subd *dualopend,
last_fee = psbt_compute_fee(inflight->funding_psbt);
/* BOLT #2:
- * The receiving node: ...
- * - if this is an RBF attempt:
- * - MUST fail the negotiation if:
- * - the transaction's total fees is less than the last
- * successfully negotiated transaction's fees
+ *
+ * - if this is an RBF attempt:
+ * - MUST fail the negotiation if:
+ * - the transaction's total fees is less than the last
+ * successfully negotiated transaction's fees
*/
if (!amount_sat_greater(candidate_fee, last_fee)) {
char *errmsg = tal_fmt(tmpctx, "Proposed funding tx fee (%s)"
diff --git a/openingd/dualopend.c b/openingd/dualopend.c
index 733b0c2..20ae07c 100644
--- a/openingd/dualopend.c
+++ b/openingd/dualopend.c
@@ -1237,12 +1237,10 @@ static char *do_commit_signed_received(const tal_t *ctx,
&state->their_funding_pubkey, remote_sig)) {
/* BOLT #1:
*
- * ### The `error` and `warning` Messages
- *...
* - when failure was caused by an invalid signature check:
- * - SHOULD include the raw, hex-encoded transaction in reply
- * to a `funding_created`, `funding_signed`,
- * `closing_signed`, or `commitment_signed` message.
+ * - SHOULD include the raw, hex-encoded transaction in reply
+ * to a `funding_created`, `funding_signed`,
+ * `closing_signed`, or `commitment_signed` message.
*/
/*~ This verbosity is not only useful for our own testing, but
* a courtesy to other implementaters whose brains may be so
diff --git a/openingd/openingd.c b/openingd/openingd.c
index 7a86218..cf63b3c 100644
--- a/openingd/openingd.c
+++ b/openingd/openingd.c
@@ -149,10 +149,10 @@ static void set_reserve_absolute(struct state * state, const struct amount_sat d
} else {
/* BOLT #2:
*
- * The sending node:
- *...
+ * The sender:
+ * ...
* - MUST set `channel_reserve_satoshis` greater than or equal
- *to `dust_limit_satoshis` from the `open_channel` message.
+ * to `dust_limit_satoshis` from the `open_channel` message.
*/
if (amount_sat_greater(dust_limit, reserve_sat)) {
status_debug("Their reserve is too small, bumping to "
@@ -735,7 +735,8 @@ static bool funder_finalize_channel_setup(struct state *state,
*
* The recipient:
* - if `signature` is incorrect OR non-compliant with LOW-S-standard rule...:
- * - MUST fail the channel
+ * - MUST send a `warning` and close the connection, or send an
+ * `error` and fail the channel.
*/
/* So we create *our* initial commitment transaction, and check the
* signature they sent against that. */
@@ -1196,12 +1197,10 @@ static u8 *fundee_channel(struct state *state, const u8 *open_channel_msg)
&theirsig)) {
/* BOLT #1:
*
- * ### The `error` and `warning` Messages
- *...
* - when failure was caused by an invalid signature check:
- * - SHOULD include the raw, hex-encoded transaction in reply
- * to a `funding_created`, `funding_signed`,
- * `closing_signed`, or `commitment_signed` message.
+ * - SHOULD include the raw, hex-encoded transaction in reply
+ * to a `funding_created`, `funding_signed`,
+ * `closing_signed`, or `commitment_signed` message.
*/
/*~ This verbosity is not only useful for our own testing, but
* a courtesy to other implementaters whose brains may be so
Why this scored 18/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.