Skip to content

Workaround for LND to cause a force-close on our channel #8213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Workaround for LND to cause a force-close on our channel #8213

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6ad55e9
Workaround for LND to cause a force-close on our channel
adi2011 Apr 5, 2025
871eead
tests: Fix test_emergencyrecover to check for ChannelReestablish
ShahanaFarooqui Apr 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions lightningd/peer_control.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1383,6 +1383,32 @@ static void connect_activate_subd(struct lightningd *ld, struct channel *channel
send_error:
log_debug(channel->log, "Telling connectd to send error %s",
tal_hex(tmpctx, error));

/* LND does not respond to errors with a unilateral close
* (https://github.com/lightningnetwork/lnd/blob/abb1e3463f3a83bbb843d5c399869dbe930ad94f/htlcswitch/link.go#L2119).
* We fix this by sending a `ChannelReestablish` msg with `0` commitment numbers and an
* invalid `your_last_per_commitment_secret`. */
if (is_stub_scid(*channel->scid)) {
struct secret your_last_per_commit_secret;
memset(&your_last_per_commit_secret, 1,
sizeof(your_last_per_commit_secret));

const u8 *msg = towire_channel_reestablish(tmpctx, &channel->cid,
0,
0,
&your_last_per_commit_secret,
&channel->channel_info.remote_per_commit,
NULL);

log_debug(channel->log, "Sending a bogus channel_reestablish message to make the peer "
"unilaterally close the channel.");

subd_send_msg(ld->connectd,
take(towire_connectd_peer_send_msg(NULL, &channel->peer->id,
channel->peer->connectd_counter,
msg)));
}

/* Get connectd to send error and close. */
subd_send_msg(ld->connectd,
take(towire_connectd_peer_send_msg(NULL, &channel->peer->id,
Expand Down
2 changes: 1 addition & 1 deletion tests/autogenerate-rpc-examples.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1914,7 +1914,7 @@ def generate_list_examples(l1, l2, l3, c12, c23_2, inv_l31, inv_l32, offer_l23,
output['amount_msat'] = 201998900000 + (i * 1000) + (k * 100)
update_example(node=l1, method='listtransactions', params={}, response=listtransactions_res1)
listclosedchannels_res1 = l2.rpc.listclosedchannels()
listclosedchannels_res1 = update_list_responses(listclosedchannels_res1, list_key='closedchannels')
listclosedchannels_res1 = update_list_responses(listclosedchannels_res1, list_key='closedchannels', slice_upto=2, update_func=None, sort=True, sort_key='channel_id')
for i, closedchannel in enumerate(listclosedchannels_res1['closedchannels'], start=1):
closedchannel['last_commitment_fee_msat'] = 2894000 + (i * 1000)
closedchannel['last_commitment_txid'] = 'txidcloselastcommitment0' + (('0000' + str(i)) * 8)
Expand Down
7 changes: 7 additions & 0 deletions tests/test_misc.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2975,6 +2975,7 @@ def test_emergencyrecoverpenaltytxn(node_factory, bitcoind):
stubs = l1.rpc.emergencyrecover()["stubs"]
assert len(stubs) == 1
assert stubs[0] == _["channel_id"]
l1.daemon.wait_for_log('Sending a bogus channel_reestablish message to make the peer unilaterally close the channel.')
l1.daemon.wait_for_log('peer_out WIRE_ERROR')

# Restarting so that L1
Expand Down Expand Up @@ -3022,7 +3023,10 @@ def test_emergencyrecover(node_factory, bitcoind):
listfunds = l1.rpc.listfunds()["channels"][0]
assert listfunds["short_channel_id"] == "1x1x1"

l1.daemon.wait_for_log('Sending a bogus channel_reestablish message to make the peer unilaterally close the channel.')
l1.daemon.wait_for_log('peer_out WIRE_ERROR')

l2.daemon.wait_for_log('bad reestablish commitment_number: 0')
l2.daemon.wait_for_log('State changed from CHANNELD_NORMAL to AWAITING_UNILATERAL')

bitcoind.generate_block(5, wait_for_mempool=1)
Expand Down Expand Up @@ -3143,7 +3147,10 @@ def test_restorefrompeer(node_factory, bitcoind):

assert l1.rpc.restorefrompeer()['stubs'][0] == _['channel_id']

l1.daemon.wait_for_log('Sending a bogus channel_reestablish message to make the peer unilaterally close the channel.')
l1.daemon.wait_for_log('peer_out WIRE_ERROR')

l2.daemon.wait_for_log('bad reestablish commitment_number: 0')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is the warning sent to the peer (l2 back to l1) over the wire, but also l1 disconnects immediately, so there's no opportunity for l1 to catch it. That would mean we either need to separately log the bad reestablish in connectd and then this test would check for that log message in l2, or otherwise we assume we're sending the bogus revocation correctly, but can't confirm with this blackbox test beyond seeing that it transmitted.

lightningd-1 2025-04-30T20:47:27.026Z DEBUG   022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Sending a bogus channel_reestablish message to make the peer unilaterally close the channel.
...
lightningd-1 2025-04-30T20:47:27.029Z DEBUG   022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_out WIRE_CHANNEL_REESTABLISH
lightningd-1 2025-04-30T20:47:27.029Z DEBUG   022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_out WIRE_ERROR
lightningd-1 2025-04-30T20:47:27.029Z DEBUG   022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: disconnect_peer
...
0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Activating for message WIRE_CHANNEL_REESTABLISH
lightningd-2 2025-04-30T20:47:27.033Z DEBUG   0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-lightningd: Telling connectd to send error 0011f7133e8b2a3e1241e601b48017f2020f1e456d1b37022912b89d61ee06508fbd008f6368616e6e656c643a207265636569766564204552524f52206368616e6e656c20663731333365386232613365313234316536303162343830313766323032306631653435366431623337303232393132623839643631656530363530386662643a20556e6b6e6f776e206368616e6e656c20666f7220574952455f4348414e4e454c5f524545535441424c495348

So I think we either need to remove this line from the test or add a separate logging event to check on the senders side (l2).

l2.daemon.wait_for_log('State changed from CHANNELD_NORMAL to AWAITING_UNILATERAL')

bitcoind.generate_block(5, wait_for_mempool=1)
Expand Down
Loading