Fix: Progress channel announcement state when remote_sigs already in DB #8808
Conversation
…th (Fixes ElementsProject#8493) Changelog-None
Fixes ElementsProject#8395 Changelog-Fixed: Transactions now correctly create change outputs between 330-546 sat for P2TR/P2WPKH instead of absorbing them as fees
Fixes ElementsProject#8395 Changelog-Fixed: Transactions now correctly create change outputs between 330-546 sat for P2TR/P2WPKH instead of absorbing them as fees
Fixes ElementsProject#8552 Changelog-Fixed: Channel announcements now work after restart even if peer doesn't resend announcement_signatures
cdecker
left a comment
cdecker
left a comment
There was a problem hiding this comment.
A couple of minor comments, specifically the elements check for 300-546sat outputs is likely important.
| try: | ||
| wait_for(lambda: node.daemon.is_in_log('overgrind: short signature length'), timeout=5) | ||
| return True | ||
| except (TimeoutError, ValueError): |
There was a problem hiding this comment.
Using the wait_for_log helper here is superfluous, as it'll always wait, except for the rare case we're trying to address here, in which case it'd go quicker because it actually finds the string. The helper is more for waiting and verifying, but the try-catch block makes it just a 5s sleep.
bitcoin/tx.c
Outdated
| if (chainparams->is_elements) | ||
| dust_limit = AMOUNT_SAT(330); /* P2WPKH */ | ||
| else | ||
| dust_limit = AMOUNT_SAT(330); /* P2TR */ |
There was a problem hiding this comment.
Both if-elae branches are identical.
|
|
||
| /* Must be non-dust */ | ||
| if (!amount_sat_greater_eq(excess, dust_limit)) | ||
| // Change is P2TR (Bitcoin) or P2WPKH (Elements) both have |
There was a problem hiding this comment.
Commenting here since we cannot comment on commit messages: by having the change log fragment in the commit message twice, you are duplicating the resulting change log entry
| // Change is P2TR (Bitcoin) or P2WPKH (Elements) both have | ||
| // dust limit of 330 sat. Legacy types (P2PKH/P2SH) use 546 sat | ||
| // but we dont create those as change outputs | ||
| if (!amount_sat_greater_eq(excess, AMOUNT_SAT(330))) |
There was a problem hiding this comment.
The check for elements also got lost somewhere. The logic matches but elements should not create these sub dust outputs since it doesn't use p2tr yet
2 participants
(Fixes #8552)
Depends on #8493 (this PR is stacked on top of the P2TR dust limit fix)
Problem
When a node restarts after exchanging announcement_signatures with a peer - the remote_sigs are loaded from the database during channel_gossip_init(). But when the peer reconnects, it may not resend announcement_signatures if it already sent them before the disconnect!
This causes the channel to get stuck in CGOSSIP_WAITING_FOR_MATCHING_PEER_SIGS state forever, preventing the channel from being announced to the network.
Solution
Modified channel_gossip_channel_reestablished() in channel_gossip.c to check if we already have remote_sigs loaded from the database. If we do - we call update_gossip_state() to attempt to progress the channel gossip state machine instead of waiting forever for the peer to resend signatures
Added comprehensive tests in test_gossip_announcement.py:
test_channel_announcement_after_restart_with_saved_sigs: Reproduces the exact scenario from issue A specific channel is not announcing my side #8552 (channel announcement after node restart)
test_channel_announcement_reconnect_without_restart: Verifies channel announcement works after simple reconnect without restart
Important
26.04 FREEZE March 11th: Non-bugfix PRs not ready by this date will wait for 26.06.
RC1 is scheduled on March 23rd
The final release is scheduled for April 15th.
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:
tools/lightning-downgrade