← Watch feed
lightningd: split out separate function for "depth == 0".
Public commit record
73/100 · Adequate
What the developer wrote
Authored by Rusty Russell
lightningd: split out separate function for "depth == 0".
This handles the reorg case, ready to use a blockdepth callback next.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
What changed, and why it matters
This commit is a straightforward code cleanup: it takes the existing logic that handles the special case where a funding transaction's confirmation depth drops to zero (a blockchain reorganization) and moves it into its own named function. No behavior changes are visible in the diff. The commit message frames this as preparation for future work, not as a security fix.
Recommended action
No security action required. Treat as normal refactoring.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch refactors funding_depth_cb() in lightningd/peer_control.c by extracting the if (depth == 0) block into a new static helper funding_reorged_cb(). The logic, state machine switch, error messages, and return paths are preserved verbatim. The only minor differences are: the new helper uses channel->funding.txid instead of the local txid variable, and the channel_funding_found() function is relocated below funding_depth_cb(). These are non-functional changes.
Changed components
lightningd/peer_control.cInspect captured patch +65 / −59
diff --git a/lightningd/peer_control.c b/lightningd/peer_control.c
index efda167b..8e773482 100644
--- a/lightningd/peer_control.c
+++ b/lightningd/peer_control.c
@@ -2307,15 +2307,60 @@ void update_channel_from_inflight(struct lightningd *ld,
wallet_channel_save(ld->wallet, channel);
}
-/* We see this tx output spend to the funding address. */
-static void channel_funding_found(struct lightningd *ld,
- const struct bitcoin_tx *tx,
- u32 outnum,
- const struct txlocator *loc,
- struct channel *channel)
+static void funding_reorged_cb(struct lightningd *ld, struct channel *channel)
{
- /* Closes channel if it doesn't fit in an scid! */
- depthcb_update_scid(channel, &channel->funding, loc);
+ /* That's not entirely unexpected in early states */
+ switch (channel->state) {
+ case DUALOPEND_AWAITING_LOCKIN:
+ case DUALOPEND_OPEN_INIT:
+ case DUALOPEND_OPEN_COMMIT_READY:
+ case DUALOPEND_OPEN_COMMITTED:
+ /* Shouldn't be here! */
+ channel_internal_error(channel,
+ "Bad %s state: %s",
+ __func__,
+ channel_state_name(channel));
+ return;
+ case CHANNELD_AWAITING_LOCKIN:
+ /* That's not entirely unexpected in early states */
+ log_debug(channel->log, "Funding tx %s reorganized out!",
+ fmt_bitcoin_txid(tmpctx, &channel->funding.txid));
+ channel_set_scid(channel, NULL);
+ return;
+
+ /* But it's often Bad News in later states */
+ case CHANNELD_AWAITING_SPLICE:
+ case CHANNELD_NORMAL:
+ /* If we opened, or it's zero-conf, we trust them anyway. */
+ if (channel->opener == LOCAL
+ || channel->minimum_depth == 0) {
+ const char *str;
+
+ str = tal_fmt(tmpctx,
+ "Funding tx %s reorganized out, but %s...",
+ fmt_bitcoin_txid(tmpctx, &channel->funding.txid),
+ channel->opener == LOCAL ? "we opened it" : "zeroconf anyway");
+
+ /* Log even if not connected! */
+ if (!channel->owner)
+ log_info(channel->log, "%s", str);
+ channel_fail_transient(channel, true, "%s", str);
+ return;
+ }
+ /* fall thru */
+ case AWAITING_UNILATERAL:
+ case CHANNELD_SHUTTING_DOWN:
+ case CLOSINGD_SIGEXCHANGE:
+ case CLOSINGD_COMPLETE:
+ case FUNDING_SPEND_SEEN:
+ case ONCHAIN:
+ case CLOSED:
+ break;
+ }
+
+ channel_internal_error(channel,
+ "Funding transaction has been reorged out in state %s!",
+ channel_state_name(channel));
}
static enum watch_result funding_depth_cb(struct lightningd *ld,
@@ -2339,57 +2384,7 @@ static enum watch_result funding_depth_cb(struct lightningd *ld,
/* Reorged out? */
if (depth == 0) {
- /* That's not entirely unexpected in early states */
- switch (channel->state) {
- case DUALOPEND_AWAITING_LOCKIN:
- case DUALOPEND_OPEN_INIT:
- case DUALOPEND_OPEN_COMMIT_READY:
- case DUALOPEND_OPEN_COMMITTED:
- /* Shouldn't be here! */
- channel_internal_error(channel,
- "Bad %s state: %s",
- __func__,
- channel_state_name(channel));
- return DELETE_WATCH;
- case CHANNELD_AWAITING_LOCKIN:
- /* That's not entirely unexpected in early states */
- log_debug(channel->log, "Funding tx %s reorganized out!",
- fmt_bitcoin_txid(tmpctx, txid));
- channel_set_scid(channel, NULL);
- return KEEP_WATCHING;
-
- /* But it's often Bad News in later states */
- case CHANNELD_AWAITING_SPLICE:
- case CHANNELD_NORMAL:
- /* If we opened, or it's zero-conf, we trust them anyway. */
- if (channel->opener == LOCAL
- || channel->minimum_depth == 0) {
- const char *str;
-
- str = tal_fmt(tmpctx,
- "Funding tx %s reorganized out, but %s...",
- fmt_bitcoin_txid(tmpctx, txid),
- channel->opener == LOCAL ? "we opened it" : "zeroconf anyway");
-
- /* Log even if not connected! */
- if (!channel->owner)
- log_info(channel->log, "%s", str);
- channel_fail_transient(channel, true, "%s", str);
- return KEEP_WATCHING;
- }
- /* fall thru */
- case AWAITING_UNILATERAL:
- case CHANNELD_SHUTTING_DOWN:
- case CLOSINGD_SIGEXCHANGE:
- case CLOSINGD_COMPLETE:
- case FUNDING_SPEND_SEEN:
- case ONCHAIN:
- case CLOSED:
- break;
- }
- channel_internal_error(channel,
- "Funding transaction has been reorged out in state %s!",
- channel_state_name(channel));
+ funding_reorged_cb(ld, channel);
return KEEP_WATCHING;
}
@@ -2435,6 +2430,17 @@ static enum watch_result funding_depth_cb(struct lightningd *ld,
abort();
}
+/* We see this tx output spend to the funding address. */
+static void channel_funding_found(struct lightningd *ld,
+ const struct bitcoin_tx *tx,
+ u32 outnum,
+ const struct txlocator *loc,
+ struct channel *channel)
+{
+ /* Closes channel if it doesn't fit in an scid! */
+ depthcb_update_scid(channel, &channel->funding, loc);
+}
+
static enum watch_result funding_spent(struct channel *channel,
const struct bitcoin_tx *tx,
size_t inputnum UNUSED,
Risk score
Our methodology →Why this scored 12/100
Human-validated context
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
No validated notes yet.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.