lightningnetwork
[bug]: `closing_txid` from `lncli closechannel` and `lncli pendingchannels` don't match
I do a cooperative close of a channel
132cfa64874d:/$
132cfa64874d:/$ lncli closechannel --chan_point f3287214768678d43086b2ee2374990f838bf4b230eccd279841df99007d827d:0 --sat_per_vbyte 1
Channel close successfully initiated
Channel close transaction broadcasted: 432889b3fc45a3020158f1a35a85becc3e87e3ead56ffab287ede5077d1bb2e1
{
"closing_txid": "432889b3fc45a3020158f1a35a85becc3e87e3ead56ffab287ede5077d1bb2e1"
}
132cfa64874d:/$
the closing_txid that is output from lncli closechannel does not match the one from lncli pendingchannels
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "02233b03ff0d7ea1b31ef08332020d091006cf5251a0720f10ef60e7c51e138fad",
"channel_point": "f3287214768678d43086b2ee2374990f838bf4b230eccd279841df99007d827d:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "07db8306bb51e30d4ea84c9d2785a6533bae639fcc6f48eb3f048af6ba9ed828",
"remote_txid": "df1f0dcfa80dc0ce003787c4f86e24bfe26aaa0aa45985e84fb803c95c8c4336",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "b194995189298c52dc26cfde2daa264bbe4a723dc3bc364783b73f55be1673c2",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
so, I'm left confused what the actual closing_txid is supposed to be.
I naively tried to repro this in regtest but can't confirm the observed behavior. In my scenario alice opened the channel, bob closed and saw tx1, bob's pending channels shows tx1 as closing tx and so does alice.
Which flags did you use to open the channel? Is this behavior deterministic in your setup?
The only special things I'm doing are sat_per_byte=10 and push_sat=50000
Yes, it is reproducible.
Here is another test. I try to close a channel
132cfa64874d:/$ lncli closechannel --chan_point a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0 --sat_per_vbyte 1
Channel close successfully initiated
Channel close transaction broadcasted: ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b
{
"closing_txid": "ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b"
}
132cfa64874d:/$
again, lncli pendingchannels shows a different closing_txid
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "0274d0d374e78d91e7fe28dc478f902e036f56ddc7db5b804c0a3aa53c6b5d013f",
"channel_point": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "351d8f4d8a49fffc945fc276253ad901d5142977c14d427852d0c6320e248ca3",
"remote_txid": "77ebbf95ed2223592113d2ca76c5556c3f88479844131e168d9ceb8268807677",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "f712f1e6bfcd3f7418c70b7c194e2d1541041a5bcf5342bdb2ad70edebdfbff4",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
Then I take a look at both
132cfa64874d:/$ lncli wallet gettx ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b
{
"tx_hash": "ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b",
"amount": "950000",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1747666555",
"total_fees": "0",
"dest_addresses": [
"bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl"
],
"output_details": [
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"pk_script": "5120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca162",
"output_index": "0",
"amount": "45175",
"is_our_address": false
},
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl",
"pk_script": "5120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb",
"output_index": "1",
"amount": "950000",
"is_our_address": true
}
],
"raw_tx_hex": "0200000000010129fe77cfe327cd7e93b2242a6a1a346114532d5a0d9be343f40b50197096dfa70000000000fdffffff0277b0000000000000225120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca162f07e0e0000000000225120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb0400483045022100ebe5dc8eeed70b4ee3ed3591135d89a195ea6d87559bd612c949d9fb2129dc2d02204aeac8be491e9ec9cebd8d6880cc99e3453af89a143e9e16a1b91b9857ac1ecf014730440220548a6c57d5462bd11f04480754e1ec3c9a52cd911fb7b71e61f620eb04f4de07022061c6a59a266f48101b248c591abdd405a873b017f056b1d1635f4a0d67e3a52301475221026de1d44af71f6146a8ff58e61a5b21c2b2274411e606c1e989f3cef351f498b6210306f8af21e43ffe712347b36129697d129353d309b9248926c87ed03ce9256a8352ae00000000",
"label": "0:closechannel:shortchanid-343047627931648",
"previous_outpoints": [
{
"outpoint": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"is_our_output": false
}
]
}
132cfa64874d:/$
132cfa64874d:/$ lncli wallet gettx f712f1e6bfcd3f7418c70b7c194e2d1541041a5bcf5342bdb2ad70edebdfbff4
{
"tx_hash": "f712f1e6bfcd3f7418c70b7c194e2d1541041a5bcf5342bdb2ad70edebdfbff4",
"amount": "949807",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1747666555",
"total_fees": "0",
"dest_addresses": [
"bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl"
],
"output_details": [
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"pk_script": "5120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca162",
"output_index": "0",
"amount": "50000",
"is_our_address": false
},
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl",
"pk_script": "5120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb",
"output_index": "1",
"amount": "949807",
"is_our_address": true
}
],
"raw_tx_hex": "0200000000010129fe77cfe327cd7e93b2242a6a1a346114532d5a0d9be343f40b50197096dfa70000000000fdffffff0250c3000000000000225120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca1622f7e0e0000000000225120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb0400483045022100ce48f58804e4245f13396c53b419975edbbb00c34f17165b59fb23661d1c36750220702e60daf8cbfa651d9ac9b5f4d420410d2d6bb0239d826e2abee0c4c917bcc401473044022059b2fa716824c09966fac9500f20f57afffead881bba0325b53edebfa0beaea502204e7e9371108cc0c23ebf555281fc6a96f1be8da29226e9ce05c9137ca3f924cb01475221026de1d44af71f6146a8ff58e61a5b21c2b2274411e606c1e989f3cef351f498b6210306f8af21e43ffe712347b36129697d129353d309b9248926c87ed03ce9256a8352ae00000000",
"label": "",
"previous_outpoints": [
{
"outpoint": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"is_our_output": false
}
]
}
132cfa64874d:/$
Now I try to do RBF
132cfa64874d:/$ lncli closechannel --chan_point a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0 --sat_per_vbyte 2
Channel close successfully initiated
Channel close transaction broadcasted: ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b
{
"closing_txid": "ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b"
}
132cfa64874d:/$
132cfa64874d:/$
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "0274d0d374e78d91e7fe28dc478f902e036f56ddc7db5b804c0a3aa53c6b5d013f",
"channel_point": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "351d8f4d8a49fffc945fc276253ad901d5142977c14d427852d0c6320e248ca3",
"remote_txid": "77ebbf95ed2223592113d2ca76c5556c3f88479844131e168d9ceb8268807677",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8e",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
then I try to look at both again
132cfa64874d:/$ lncli wallet gettx ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b
{
"tx_hash": "ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b",
"amount": "950000",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1747666555",
"total_fees": "0",
"dest_addresses": [
"bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl"
],
"output_details": [
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1pu8avewf8ucg46qlntwtgphlrsqel4jdq40ka05j5j6gtsn0u593q9w5g8x",
"pk_script": "5120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca162",
"output_index": "0",
"amount": "45175",
"is_our_address": false
},
{
"output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
"address": "bcrt1p39xq6n0tadzvhkchq8sk30pvfgumrqzzyg3lp6vj9q52d5l0p09sudshwl",
"pk_script": "5120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb",
"output_index": "1",
"amount": "950000",
"is_our_address": true
}
],
"raw_tx_hex": "0200000000010129fe77cfe327cd7e93b2242a6a1a346114532d5a0d9be343f40b50197096dfa70000000000fdffffff0277b0000000000000225120e1faccb927e6115d03f35b9680dfe38033fac9a0abedd7d2549690b84dfca162f07e0e0000000000225120894c0d4debeb44cbdb1701e168bc2c4a39b180422223f0e9922828a6d3ef0bcb0400483045022100ebe5dc8eeed70b4ee3ed3591135d89a195ea6d87559bd612c949d9fb2129dc2d02204aeac8be491e9ec9cebd8d6880cc99e3453af89a143e9e16a1b91b9857ac1ecf014730440220548a6c57d5462bd11f04480754e1ec3c9a52cd911fb7b71e61f620eb04f4de07022061c6a59a266f48101b248c591abdd405a873b017f056b1d1635f4a0d67e3a52301475221026de1d44af71f6146a8ff58e61a5b21c2b2274411e606c1e989f3cef351f498b6210306f8af21e43ffe712347b36129697d129353d309b9248926c87ed03ce9256a8352ae00000000",
"label": "0:closechannel:shortchanid-343047627931648",
"previous_outpoints": [
{
"outpoint": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"is_our_output": false
}
]
}
but they both aren't available
132cfa64874d:/$ lncli wallet gettx 226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8e
[lncli] rpc error: code = Unknown desc = can not find transaction: txid 226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8e
132cfa64874d:/$
I looked and lncli pendingchannels shows the same thing for both alice and bob.
per your last test, ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b is the txn replacing the previous txn, so doesn't it make sense for 226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8e to not be available anymore?
per your last test,
ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198bis the txn replacing the previous txn, so doesn't it make sense for226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8eto not be available anymore?
According to lncli pendingchannels, 226d25160dff5e5252530732ce88145b364ecdb77bb64e061815b2bd8482af8e is the new transaction. https://github.com/lightningnetwork/lnd/issues/9828 makes this extra confusing.
OK, I did some more testing.
First I did
132cfa64874d:/$ lncli closechannel --chan_point a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0 --sat_per_vbyte 5
Channel close successfully initiated
Channel close transaction broadcasted: ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b
{
"closing_txid": "ce43776facef5816a0997619f0662874aac063c1904a11344bd4fa5949d0198b"
}
132cfa64874d:/$
132cfa64874d:/$
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "0274d0d374e78d91e7fe28dc478f902e036f56ddc7db5b804c0a3aa53c6b5d013f",
"channel_point": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "351d8f4d8a49fffc945fc276253ad901d5142977c14d427852d0c6320e248ca3",
"remote_txid": "77ebbf95ed2223592113d2ca76c5556c3f88479844131e168d9ceb8268807677",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "1736728cac037e947314d53e441cde05fab8af6c99e3e675744537e3d896dccb",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
Next, I made a custom script
#!/usr/bin/env python3
from mini_META_lib import litd_node_objects, initNodes
from argparse import ArgumentParser
initNodes()
parser = ArgumentParser()
parser.add_argument('--channel_point', type=str, required=True)
parser.add_argument('--sat_per_vbyte', type=int, required=True)
arguments=parser.parse_args()
print()
print('=============================')
print()
for response in litd_node_objects['bob']['lnd'].close_channel(channel_point=arguments.channel_point, sat_per_vbyte=arguments.sat_per_vbyte, no_wait=True):
print(response)
print('txid_hex: '+response.close_pending.txid.hex())
print()
print('=============================')
print()
And I run this script.
$ close_test --channel_point a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0 --sat_per_vbyte 1
=============================
close_instant {
}
txid_hex:
=============================
close_pending {
txid: "\213\031\320IY\372\324K4\021J\220\301c\300\252t(f\360\031v\231\240\026X\357\254owC\316"
fee_per_vbyte: 25
}
txid_hex: 8b19d04959fad44b34114a90c163c0aa742866f0197699a01658efac6f7743ce
=============================
close_pending {
txid: "\364\277\337\353\355p\255\262\275BS\317[\032\004A\025-N\031|\013\307\030t?\315\277\346\361\022\367"
fee_per_vbyte: 1
local_close_tx: true
}
txid_hex: f4bfdfebed70adb2bd4253cf5b1a0441152d4e197c0bc718743fcdbfe6f112f7
=============================
and although I have no_wait=True, it seems to still wait to release the gRPC stream, and I'm not sure why.
Also, I'm not sure why we get 2 close_pending updates.
Anyway, I go to another terminal and run
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "0274d0d374e78d91e7fe28dc478f902e036f56ddc7db5b804c0a3aa53c6b5d013f",
"channel_point": "a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "351d8f4d8a49fffc945fc276253ad901d5142977c14d427852d0c6320e248ca3",
"remote_txid": "77ebbf95ed2223592113d2ca76c5556c3f88479844131e168d9ceb8268807677",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "f712f1e6bfcd3f7418c70b7c194e2d1541041a5bcf5342bdb2ad70edebdfbff4",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
and you can see 2 things.
First, we have a mix in byte order (see https://learnmeabitcoin.com/technical/general/byte-order/) in the TXID between lncli closechannel/lncli pendingchannels and my script that uses the gRPC response . I'm not sure which one is the correct order.
Second, lncli closechannel shows the first close_pending TXID and lncli pendingchannels shows the second close_pending TXID that come from the raw gRPC response I receive from CloseChannel.
If you're doing RBF, then it's possible that the transaction that we sign ourselves, isn't the one that ultimately gets confirmed.
If you're doing RBF, then it's possible that the transaction that we sign ourselves, isn't the one that ultimately gets confirmed.
No blocks were mined during these tests.
And I run this script.
$ close_test --channel_point a7df967019500bf443e39b0d5a2d531461341a6a2a24b2937ecd27e3cf77fe29:0 --sat_per_vbyte 1 ============================= close_instant { } txid_hex: ============================= close_pending { txid: "\213\031\320IY\372\324K4\021J\220\301c\300\252t(f\360\031v\231\240\026X\357\254owC\316" fee_per_vbyte: 25 } txid_hex: 8b19d04959fad44b34114a90c163c0aa742866f0197699a01658efac6f7743ce ============================= close_pending { txid: "\364\277\337\353\355p\255\262\275BS\317[\032\004A\025-N\031|\013\307\030t?\315\277\346\361\022\367" fee_per_vbyte: 1 local_close_tx: true } txid_hex: f4bfdfebed70adb2bd4253cf5b1a0441152d4e197c0bc718743fcdbfe6f112f7 =============================and although I have
no_wait=True, it seems to still wait to release the gRPC stream, and I'm not sure why.
The other thing is why does the first close_pending have fee_per_vbyte: 25?
Related. I'm running on regtest and I get
132cfa64874d:/$ lncli wallet estimatefeerate 1
[lncli] rpc error: code = Unknown desc = confirmation target must be greater than 1
132cfa64874d:/$ lncli wallet estimatefeerate 2
{
"sat_per_kw": 6250,
"sat_per_vbyte": 25,
"min_relay_fee_sat_per_kw": 253,
"min_relay_fee_sat_per_vbyte": 1
}
132cfa64874d:/$ lncli wallet estimatefeerate 3
{
"sat_per_kw": 6250,
"sat_per_vbyte": 25,
"min_relay_fee_sat_per_kw": 253,
"min_relay_fee_sat_per_vbyte": 1
}
132cfa64874d:/$
so, that may have some relation to where the fee_per_vbyte: 25 came from.
I tried closing a new channel
$ close_test --sat_per_vbyte 6 --channel_point 4fc282d78a58a685545fad08c482260866a418a339f855baeaa104748aca9905:0
total nodes: 9
=============================
close_instant {
}
txid_hex:
closing_txid:
=============================
close_pending {
txid: "\211\276\313\263O\367I\242]\274\343\375\311\264g\366\260\212\324\272BcRD\201J\215\257\022\270i~"
fee_per_vbyte: 25
}
txid_hex: 89becbb34ff749a25dbce3fdc9b467f6b08ad4ba42635244814a8daf12b8697e
closing_txid:
=============================
close_pending {
txid: "\217\003\t\212\014?\252Y\223t\027|\2430\376\335x\333Z\227\021Y\232\373\230N\'\323\037\010\014\241"
fee_per_vbyte: 6
local_close_tx: true
}
txid_hex: 8f03098a0c3faa599374177ca330fedd78db5a9711599afb984e27d31f080ca1
closing_txid:
=============================
Then I run
132cfa64874d:/$ lncli pendingchannels
{
"total_limbo_balance": "946530",
"pending_open_channels": [],
"pending_closing_channels": [],
"pending_force_closing_channels": [],
"waiting_close_channels": [
{
"channel": {
"remote_node_pub": "03edf5716b6d6c286f6b286d4171e6fc38711ee9e7d7f54383106a98976a6e9bc9",
"channel_point": "4fc282d78a58a685545fad08c482260866a418a339f855baeaa104748aca9905:0",
"capacity": "1000000",
"local_balance": "946530",
"remote_balance": "50000",
"local_chan_reserve_sat": "10000",
"remote_chan_reserve_sat": "10000",
"initiator": "INITIATOR_LOCAL",
"commitment_type": "ANCHORS",
"num_forwarding_packages": "0",
"chan_status_flags": "ChanStatusCoopBroadcasted|ChanStatusLocalCloseInitiator",
"private": false,
"memo": "",
"custom_channel_data": ""
},
"limbo_balance": "946530",
"commitments": {
"local_txid": "c0201f2869817f6a1f9202b11e0d56449d4d1f7f1389d17ff52f21ad7769c257",
"remote_txid": "42a92e7feb04ee8c322499d87e899c82a2d5f97ad2605fd1645aa7f1e7593cf6",
"remote_pending_txid": "",
"local_commit_fee_sat": "2810",
"remote_commit_fee_sat": "2810",
"remote_pending_commit_fee_sat": "0"
},
"closing_txid": "a10c081fd3274e98fb9a5911975adb78ddfe30a37c17749359aa3f0c8a09038f",
"closing_tx_hex": ""
}
]
}
132cfa64874d:/$
and then
bitcoin-cli -generate 1
and then I get
chan_close {
closing_txid: "\211\276\313\263O\367I\242]\274\343\375\311\264g\366\260\212\324\272BcRD\201J\215\257\022\270i~"
success: true
}
txid_hex:
closing_txid: 89becbb34ff749a25dbce3fdc9b467f6b08ad4ba42635244814a8daf12b8697e
=============================
OK. I've done some more testing and have done the following:
Use my python script to close a channel and monitor gRPC streaming responses, then run lncli closechannel and lncli pendingchannels on both peers.
What I've observed is the following:
lncli closechannel always shows the peer's latest TXID.
lncli pendingchannels always shows the latest TXID from either party.
regardless of what the actual highest fee TX is.
I can confirm this because whenever I update the fee locally, lncli pendingchannels gets a new TXID and whenever the peer updates the fee, lncli closechannel gets a new TXID.
lncli closechannelalways shows the peer's latest TXID.
lncli pendingchannelsalways shows the latest TXID from either party.
So, if the peer updates the fee on their end, both lncli closechannel and lncli pendingchannels will in that scenario show the same TXID on your end.
I think the simplest and clearest fix to this issue would be for lncli closechannel and lncli pendingchannels to both clearly show the TXID of both parties. This way we know who created what transaction and we can see the fee rate of the other party. If we can look and see that they put in a higher fee rate than us, we may not want to bump the fee.
I just realized I can use the --block option to get some more information from lncli closechannel, but https://github.com/lightningnetwork/lnd/issues/9836 limits it and it does not show fee_per_vbyte or local_close_tx.
I observed the same issue today. The hex also differs. Interestingly, the fee amount does not differ from the published version. However, my local balance was higher by the fee amount in the published version. At the same time, the remote balance was lower by the fee amount.
Edit: SubscribeTransactions returned the correct transaction id and hex before.
