lnpeer: add fixme for unsafe zeroconf behaviour
What the developer wrote
Authored by SomberNight
lnpeer: add fixme for unsafe zeroconf behaviour
there is a later check in Channel.update_funded_state
added in https://github.com/spesmilo/electrum/pull/9624
but it only validates the funding_tx once it's already 3 blocks deep
What changed, and why it matters
A developer left a FIXME note in Electrum's Lightning code warning that a feature called 'zeroconf' channels marks a payment channel as funded before actually checking that the funding transaction exists or contains the required multisig output. The commit does not fix the issue; it only documents the concern. The note explicitly says this is unsafe and must be reworked before mainnet use, suggesting the current code could let a malicious or buggy peer make Electrum believe money was locked in a channel when it really wasn't.
Treat this as a known security TODO, not a completed fix. Before enabling zeroconf channels on mainnet, add validation that the funding transaction is in the mempool and that it contains the correct multisig funding output before transitioning the channel to FUNDED and sending channel_ready. Consider gating zeroconf support behind explicit user opt-in or disabling it until the rework is complete.
Security signals we found
FIXME comment explicitly labels behavior as unsafe and requiring rework before mainnet usage
Missing validation of funding transaction before marking channel as funded
Missing validation that funding transaction contains the expected multisig funding output
State transition to FUNDED occurs before mempool confirmation for zeroconf channels
Later validation only triggers at 3 confirmations, leaving a trust window
Evidence from the diff
In electrum/lnpeer.py, when a zeroconf channel is opened, the code immediately transitions the channel to ChannelState.FUNDED and sends channel_ready without waiting for the funding transaction to be in the mempool or validating that the transaction actually contains the expected 2-of-2 multisig funding output. The commit adds a FIXME comment pointing out this gap. The existing validation in Channel.update_funded_state only runs once the funding transaction is 3 blocks deep, leaving a window where the local node treats an unverified channel as funded. This is a code-comment-only change; no mitigation is implemented.
Changed components
electrum/lnpeer.pyLightning zeroconf channel opening flowChannelState.FUNDED transition logicInspect captured patch +3 / −0
diff --git a/electrum/lnpeer.py b/electrum/lnpeer.py
index d7594bf..67f89f7 100644
--- a/electrum/lnpeer.py
+++ b/electrum/lnpeer.py
@@ -1432,6 +1432,9 @@ class Peer(Logger, EventListener):
chan.open_with_first_pcp(payload['first_per_commitment_point'], remote_sig)
chan.set_state(ChannelState.OPENING)
if is_zeroconf:
+ # FIXME shouldn't we wait until funding_tx is at least in the mempool?!
+ # We haven't even validated funding_tx really contains the multisig funding output!
+ # This is unsafe. MUST be reworked before mainnet usage.
chan.set_state(ChannelState.FUNDED)
self.send_channel_ready(chan)
self.lnworker.add_new_channel(chan)
Why this scored 41/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.