lnpeer: chan_reest: clarify my_current_per_commitment_point is ignored
What the developer wrote
Authored by SomberNight
lnpeer: chan_reest: clarify my_current_per_commitment_point is ignored
`my_current_per_commitment_point` was only used prior to option_static_remotekey
What changed, and why it matters
This is a small code cleanup in Electrum's Lightning Network peer handling. The change replaces a fake but valid-looking public key (derived from the number 42) with a clearer, well-known valid public key (the standard generator point) when sending a 'channel_reestablish' message. The comment now explicitly says this value is ignored by modern nodes because they use a feature called option_static_remotekey. There is no obvious security vulnerability being fixed here; it is mainly a clarification and minor hardening against future confusion.
No immediate action required. Treat as routine maintenance. Reviewers may want to confirm that option_static_remotekey is indeed mandatory for all channels and that no legacy non-static-remotekey path still relies on my_current_per_commitment_point.
Security signals we found
Magic constant replaced with semantically clear generator point
Comment added clarifying that the per-commitment point is ignored under option_static_remotekey
No change to protocol logic or control flow
No bounds check, input validation, or cryptographic operation change
No bug fix or vulnerability disclosure language in commit message
Evidence from the diff
In electrum/lnpeer.py, two call sites that construct channel_reestablish messages now set my_current_per_commitment_point to ecc.GENERATOR.get_public_key_bytes(compressed=True) instead of secret_to_pubkey(42) or the real local commitment point at index 0. The commit message and comments state that my_current_per_commitment_point is ignored when option_static_remotekey is enabled, and Electrum now requires that feature (assert chan.is_static_remotekey_enabled()). The old secret_to_pubkey(42) produced a valid secp256k1 point but was a magic value; the new value is the standard generator point, still valid but semantically neutral. This is a non-functional refactor/clarification.
Changed components
electrum/lnpeer.pyLightning channel reestablishment message constructionInspect captured patch +4 / −4
diff --git a/electrum/lnpeer.py b/electrum/lnpeer.py
index fc5d99b..5270561 100644
--- a/electrum/lnpeer.py
+++ b/electrum/lnpeer.py
@@ -1419,14 +1419,14 @@ class Peer(Logger, EventListener):
self.logger.info(f"trying to get remote peer to force-close chan {channel_id.hex()}")
# First, we intentionally send a "channel_reestablish" msg with an old state.
# Many nodes (but not all) automatically force-close when seeing this.
- latest_point = secret_to_pubkey(42) # we need a valid point (BOLT2)
+ ignored_point = ecc.GENERATOR.get_public_key_bytes(compressed=True) # ignored but valid point (BOLT2)
self.send_message(
"channel_reestablish",
channel_id=channel_id,
next_commitment_number=0,
next_revocation_number=0,
your_last_per_commitment_secret=0,
- my_current_per_commitment_point=latest_point)
+ my_current_per_commitment_point=ignored_point)
# Newish nodes that have lightning/bolts/pull/950 force-close upon receiving an "error" msg,
# so send that too. E.g. old "channel_reestablish" is not enough for eclair 0.7+,
# but "error" is. see https://github.com/ACINQ/eclair/pull/2036
@@ -1568,7 +1568,7 @@ class Peer(Logger, EventListener):
oldest_unrevoked_remote_ctn = chan.get_oldest_unrevoked_ctn(REMOTE)
# send message
assert chan.is_static_remotekey_enabled()
- latest_secret, latest_point = chan.get_secret_and_point(LOCAL, 0)
+ ignored_point = ecc.GENERATOR.get_public_key_bytes(compressed=True) # ignored but valid point (BOLT2)
if oldest_unrevoked_remote_ctn == 0:
last_rev_secret = 0
else:
@@ -1580,7 +1580,7 @@ class Peer(Logger, EventListener):
next_commitment_number=next_local_ctn,
next_revocation_number=oldest_unrevoked_remote_ctn,
your_last_per_commitment_secret=last_rev_secret,
- my_current_per_commitment_point=latest_point)
+ my_current_per_commitment_point=ignored_point)
self.logger.info(
f'channel_reestablish ({chan.get_id_for_log()}): sent channel_reestablish with '
f'(next_local_ctn={next_local_ctn}, '
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.