(May be related to #707 )
Seems like it disconnected between master telling it funding was locked and it replying, so we're
in AWAITING_LOCKIN but no longer have a depth callback? This could be fixed by a restart,
but we need to add a test for this case. Generally, we should probably keep this callback
around until we move out of that state (ie. don't have it delete itself).
Needs a new test written though...
$ lightning-cli --lightning-dir=$HOME/.lightning/mainnet listpeers 0231ddd5d41d510ceda7e0c66b62ea6eaadf7954ef80b1c61222efc5d2441218b9 debug
{ "peers" :
[
{ "id" : "0231ddd5d41d510ceda7e0c66b62ea6eaadf7954ef80b1c61222efc5d2441218b9", "connected" : true, "netaddr" :
[ "[::ffff:94.5.151.31]:58081" ], "channels" :
[
{ "state" : "CHANNELD_AWAITING_LOCKIN", "owner" : "lightning_channeld", "short_channel_id" : "505336:540:0", "funding_txid" : "b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "msatoshi_to_us" : 0, "msatoshi_total" : 82556000 } ], "log" :
[ "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Waiting for funding confirmations", "Got depth change 0->1 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Funding tx b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39 depth 1 of 3", "Got depth change 1->2 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Funding tx b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39 depth 2 of 3", "Got depth change 2->3 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Funding tx b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39 depth 3 of 3", "Got depth change 0->3 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Got depth change 3->4 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Got depth change 4->5 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Got depth change 5->6 for b2b5bc0e4795e6ad8161f0e64982faf2fe090527c1bb53edf2c7ad7cc3ff9c39", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in", "Peer transient failure in CHANNELD_AWAITING_LOCKIN: Owning subdaemon lightning_channeld died (33792)", "Peer has reconnected, state CHANNELD_AWAITING_LOCKIN", "Already have funding locked in" ] } ] }
This is the same issue as #689 but it does not resolve after restart.
I created a testcase for this, disconnecting and/or restarting nodes, then confirming and the reconnecting, but I can't reproduce the issue. I also tried to reproduce the issue with the node 02aeb693e2dfb2f890c65dcf27e6eb7d52dd3e4f7b74ce5fe646675793625f9b51 which some have reported as being the offending node. I'll see if I can reproduce this in some other way.
I think I might have found one place where we might be dropping the watch without telling channeld: https://github.com/cdecker/lightning/commit/5f38522ceef14512e65f53a10a33866a5be48e08
If we start watching a tx, but cross the lock depth or the announce depth, without being owned by channeld, e.g., during a restart or reconnection in openingd, then it can happen that the TX watch dies without notifying.
I'm fishing in the dark here of course, since I was unable to reproduce the issue, and the consistency users are encountering despite restart may point to more places where this happens.
I have the same issue, i'm noticing that the lightningd debug output does not contain any "new block" messages (aside from when it was first started). Still doesn't pick up new blocks even after restart. I think that may be why it's stuck in CHANNELD_AWAITING_LOCKIN - it hasn't seen the blocks that the transaction went into.
Note, perhaps unrelated but I don't think my fundchannel commands are actually broadcasting the transaction either. After 30 minutes the txid wasn't found on block explorers. I used the block explorer to push the raw tx, and then it got confirmed soon after. But lightningd still shows it as CHANNELD_AWAITING_LOCKIN.
@weissjeffm Yes, same as me.
I'm not sure if this is relevant but this is my transaction and it was created using a patched version of lnd for mainnet.
I got this issue as well and across multiple channels. My first channel creation was successful as I was able to purchase stickers. I had some satoshis left over so I tried to create another channel with another node using the remainder, which got stuck in CHANNELD_AWAITING_LOCKIN. I then tried to close the original one (used to buy stickers) and now that is stuck in ONCHAIND_OUR_UNILATERAL. To potentially screw things up more, I deposited some more BTC into a new address. Once that confirmed I tried to open 2 new channels with different nodes from before. Both of those resulted in CHANNELD_AWAITING_LOCKIN.
I don't know how I caused the initial issue but I've tried restarting lightning, restarting bitcoind, cloning the latest lightning repo and rebuilding, etc. Everything is still stuck and so far I only have 1 channel open with a node I don't remember opening myself.
Ok, so can everybody confirm that once a channel gets stuck in this situation then all subsequent channels will also get stuck?
@cdecker I've only done two attempts and they both got stuck, so I've never seen it get unstuck. This is just my naive opinion and could be totally wrong, but it sure looks to me like lightningd is not communicating with bitcoind correctly - fails to broadcast transactions, and then fails to notice that transactions have been included in blocks.
If you could tell me what output messages I should see if the communication was working, I can check if I have them in my logs. As I mentioned, I don't get the "Adding block [block hash]" messages - they appear when I first start the daemon with a fresh db, but stop sometime after, and won't reappear even if I restart the daemon.
I noticed this in the log just now (shortly after restarting lightningd):
lightningd(884): bitcoin-cli getblock 00000000000000000038e70ff9f4dabeeb3a61abf53f3fbef8e9220a6f63da12
exited with status 1
So I tried to run that command myself and got this:
[jweiss@localhost lightning]$ bitcoin-cli getblock 00000000000000000038e70ff9f4dabeeb3a61abf53f3fbef8e9220a6f63da12
error code: -1
error message:
Block not available (pruned data)
[jweiss@localhost lightning]$
So, the big question is, is running bitcoind with pruning unsupported? There's nothing in the README that says it isn't.
But that could explain the persistent "stuckness" if a block lightningd needs to see has been pruned, it's never going to come back.
My node that is still stuck on CHANNELD_AWAITING_LOCKIN with peer 02aeb693e2dfb2f890c65dcf27e6eb7d52dd3e4f7b74ce5fe646675793625f9b51 successfully opened a channel to 02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432 which is now in CHANNELD_NORMAL. So it appears that nodes can still successfully make channels if there is one that gets stuck.
Ok, just merged @rustyrussell's fix, please update to master, recompile, rinse and repeat :wink:
What about pruned support, will that be looked at soon? Both weissjeffm and me can't start lightningd now:
lightningd(8678): bitcoin-cli getblock 0000000000000000003e71ed8a7f0b824e7604f45d0f3d377131ca3f2a45316c false exited with status 1
bitcoin-cli getblock 0000000000000000003e71ed8a7f0b824e7604f45d0f3d377131ca3f2a45316c
error code: -1
error message:
Block not available (pruned data)
We'll need to add some machinery in order to fully support pruned nodes, e.g., tracking UTXOs ourselves and not resyncing from the first block on every start. It's on the roadmap, but not the highest priority task.
It seems like I have the same problem. I connected to the node 02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432, funded channel and tx is successfully broadcasted and confirmed (link to block explorer) but channel status is stuck on CHANNELD_AWAITING_LOCKIN. I tried to restart both nodes but the status never changed.
I am also facing the same. In my case, I connected to node 0235447c7485ff2b945bac5fbc366d54a87389bab8cacf1b64b26ec01e96bd165a, funded channel and tx can be seen here: https://blockchain.info/tx/a7f2741a0950019c020caad26f0c3600d2f20e8f85344bf23b0153c7973489a6
Channel Status still stuck on CHANNELD_AWAITING_LOCKIN. Recompiled, restarted etc but still stuck unfortunately
Please don't comment on closed issues, I tend to miss them, since they are closed.
@ismailakkila & @dpgribkov can you share the output of getinfo?
@cdecker, thanks for looking into this. The channel status just got updated recently:
{ "peers" :
[
{ "id" : "0235447c7485ff2b945bac5fbc366d54a87389bab8cacf1b64b26ec01e96bd165a", "connected" : true, "netaddr" :
[ "34.236.113.58:9735" ], "channels" :
[
{ "state" : "CHANNELD_NORMAL", "owner" : "lightning_channeld", "short_channel_id" : "506615:1310:1", "funding_txid" : "a7f2741a0950019c020caad26f0c3600d2f20e8f85344bf23b0153c7973489a6", "msatoshi_to_us" : 250000000, "msatoshi_total" : 250000000, "dust_limit_satoshis" : 546, "max_htlc_value_in_flight_msat" : 18446744073709551615, "channel_reserve_satoshis" : 0, "htlc_minimum_msat" : 0, "to_self_delay" : 144, "max_accepted_htlcs" : 483 } ] } ] }
Here is getinfo:
{ "id" : "032368258aad451e2c70c76d86b194001240f3a2cdff651e57ccbc473ade84a0a4", "port" : 9735, "address" :
[ ], "version" : "v0.5.2-2016-11-21-1722-g7db88f0", "blockheight" : 506650, "network" : "bitcoin" }
But now if I make a payment to blockstream store, i get WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote):
Here are some details:
decodepay lnbc1692458280p1pdx7gyepp5h3m6833dk6rkl3ggn9s9lhe8zs6fcuxtqy6mhctxc04xwyu95f8qdr6gfkx7cmtwd68yetpd5azqvfe9ccrqgz42dzzqen0ypskuepqg3hkufm5yp28yatnwshzq4n9wf5kv7fwyqkjqnt9deejqumgd9e8ggpdypxk2erfw4kjq7pqxycqpg00prasu2sgne4tgwmvkj9f3fp63jvwzeedhy6kwat3sfucw2qap3z9cqzjxj8gcf64jhg0jm400847hjzhdz6rq2ue3f52dge39700gqk6reju:
{ "currency" : "bc", "timestamp" : 1517232281, "created_at" : 1517232281, "expiry" : 3600, "payee" : "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432", "msatoshi" : 169245828, "description" : "Blockstream: 19.00 USD fo and Don't Trust. Verify. - Mens shirt - Medium x 1", "min_final_cltv_expiry" : 8, "payment_hash" : "bc77a3c62db6876fc50899605fdf2714349c70cb0135bbe166c3ea671385a24e", "signature" : "304402207bc23ec38a82279aad0edb2d22a6290ea3263859cb6e4d59dd5c609e61ca07430220111700148d23a309d565743e5babde7afaf215da2d0c0ae6629a29a8cc4be7bd" }
getroute 02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432:
{ "route" :
[
{ "id" : "0235447c7485ff2b945bac5fbc366d54a87389bab8cacf1b64b26ec01e96bd165a", "channel" : "506615:1310:1", "msatoshi" : 169248858, "delay" : 31 },
{ "id" : "03cbf298b068300be33f06c947b9d3f00a0f0e8089da3233f5db37e81d3a596fe1", "channel" : "505917:2028:0", "msatoshi" : 169246166, "delay" : 17 },
{ "id" : "02318a86649ae70b06e6951636b3addc29876fb3dec82a63757595915ae2e3652e", "channel" : "505728:566:0", "msatoshi" : 169245997, "delay" : 13 },
{ "id" : "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432", "channel" : "505881:1710:1", "msatoshi" : 169245828, "delay" : 9 } ] }
pay lnbc1692458280p1pdx7gyepp5h3m6833dk6rkl3ggn9s9lhe8zs6fcuxtqy6mhctxc04xwyu95f8qdr6gfkx7cmtwd68yetpd5azqvfe9ccrqgz42dzzqen0ypskuepqg3hkufm5yp28yatnwshzq4n9wf5kv7fwyqkjqnt9deejqumgd9e8ggpdypxk2erfw4kjq7pqxycqpg00prasu2sgne4tgwmvkj9f3fp63jvwzeedhy6kwat3sfucw2qap3z9cqzjxj8gcf64jhg0jm400847hjzhdz6rq2ue3f52dge39700gqk6reju:
{ "code" : -1, "message" : "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)" }
Maybe Im missing something..
Maybe these logs can help:
listpeers 0235447c7485ff2b945bac5fbc366d54a87389bab8cacf1b64b26ec01e96bd165a debug:
{
"peers":[
{
"id":"0235447c7485ff2b945bac5fbc366d54a87389bab8cacf1b64b26ec01e96bd165a",
"connected":true,
"netaddr":[
"34.236.113.58:9735"
],
"channels":[
{
"state":"CHANNELD_NORMAL",
"owner":"lightning_channeld",
"short_channel_id":"506615:1310:1",
"funding_txid":"a7f2741a0950019c020caad26f0c3600d2f20e8f85344bf23b0153c7973489a6",
"msatoshi_to_us":250000000,
"msatoshi_total":250000000,
"dust_limit_satoshis":546,
"max_htlc_value_in_flight_msat":18446744073709551615,
"channel_reserve_satoshis":0,
"htlc_minimum_msat":0,
"to_self_delay":144,
"max_accepted_htlcs":483
}
],
"log":[
"Peer has reconnected, state CHANNELD_AWAITING_LOCKIN",
"Waiting for funding confirmations",
"Got depth change 0->20 for a7f2741a0950019c020caad26f0c3600d2f20e8f85344bf23b0153c7973489a6",
"Funding tx a7f2741a0950019c020caad26f0c3600d2f20e8f85344bf23b0153c7973489a6 depth 20 of 3",
"Got funding_locked",
"State changed from CHANNELD_AWAITING_LOCKIN to CHANNELD_NORMAL",
"got revoke 0: 0 changed",
"got commitsig 1: feerate 13412, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 1: 0 changed",
"got commitsig 2: feerate 30499, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 2: 0 changed",
"got commitsig 3: feerate 28035, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 3: 0 changed",
"got commitsig 4: feerate 28032, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 4: 0 changed",
"got commitsig 5: feerate 26466, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 5: 0 changed",
"got commitsig 6: feerate 26460, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 6: 0 changed",
"got commitsig 7: feerate 26449, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 7: 0 changed",
"got commitsig 8: feerate 26446, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 8: 0 changed",
"got commitsig 9: feerate 19746, 0 added, 0 fulfilled, 0 failed, 0 changed",
"HTLC out 0 SENT_ADD_HTLC->SENT_ADD_COMMIT",
"got revoke 9: 1 changed",
"HTLC out 0 SENT_ADD_COMMIT->RCVD_ADD_REVOCATION",
"got commitsig 10: feerate 19746, 0 added, 0 fulfilled, 0 failed, 1 changed",
"HTLC out 0 RCVD_ADD_REVOCATION->RCVD_ADD_ACK_COMMIT",
"HTLC out 0 RCVD_ADD_ACK_COMMIT->SENT_ADD_ACK_REVOCATION",
"got commitsig 11: feerate 19746, 0 added, 0 fulfilled, 1 failed, 0 changed",
"HTLC out 0 SENT_ADD_ACK_REVOCATION->RCVD_REMOVE_COMMIT",
"Our HTLC 0 failed (0)",
"HTLC out 0 RCVD_REMOVE_COMMIT->SENT_REMOVE_REVOCATION",
"HTLC out 0 SENT_REMOVE_REVOCATION->SENT_REMOVE_ACK_COMMIT",
"got revoke 10: 1 changed",
"HTLC out 0 SENT_REMOVE_ACK_COMMIT->RCVD_REMOVE_ACK_REVOCATION",
"Removing out HTLC 0 state RCVD_REMOVE_ACK_REVOCATION REMOTEFAIL",
"htlc 0 failed from 1th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE)",
"HTLC out 1 SENT_ADD_HTLC->SENT_ADD_COMMIT",
"got revoke 11: 1 changed",
"HTLC out 1 SENT_ADD_COMMIT->RCVD_ADD_REVOCATION",
"got commitsig 12: feerate 19746, 0 added, 0 fulfilled, 0 failed, 1 changed",
"HTLC out 1 RCVD_ADD_REVOCATION->RCVD_ADD_ACK_COMMIT",
"HTLC out 1 RCVD_ADD_ACK_COMMIT->SENT_ADD_ACK_REVOCATION",
"got commitsig 13: feerate 19746, 0 added, 0 fulfilled, 1 failed, 0 changed",
"HTLC out 1 SENT_ADD_ACK_REVOCATION->RCVD_REMOVE_COMMIT",
"Our HTLC 1 failed (0)",
"HTLC out 1 RCVD_REMOVE_COMMIT->SENT_REMOVE_REVOCATION",
"HTLC out 1 SENT_REMOVE_REVOCATION->SENT_REMOVE_ACK_COMMIT",
"got revoke 12: 1 changed",
"HTLC out 1 SENT_REMOVE_ACK_COMMIT->RCVD_REMOVE_ACK_REVOCATION",
"Removing out HTLC 1 state RCVD_REMOVE_ACK_REVOCATION REMOTEFAIL",
"htlc 1 failed from 1th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE)",
"got revoke 13: 0 changed",
"got commitsig 14: feerate 22619, 0 added, 0 fulfilled, 0 failed, 0 changed",
"HTLC out 2 SENT_ADD_HTLC->SENT_ADD_COMMIT",
"got revoke 14: 1 changed",
"HTLC out 2 SENT_ADD_COMMIT->RCVD_ADD_REVOCATION",
"got commitsig 15: feerate 22619, 0 added, 0 fulfilled, 0 failed, 1 changed",
"HTLC out 2 RCVD_ADD_REVOCATION->RCVD_ADD_ACK_COMMIT",
"HTLC out 2 RCVD_ADD_ACK_COMMIT->SENT_ADD_ACK_REVOCATION",
"got commitsig 16: feerate 22619, 0 added, 0 fulfilled, 1 failed, 0 changed",
"HTLC out 2 SENT_ADD_ACK_REVOCATION->RCVD_REMOVE_COMMIT",
"Our HTLC 2 failed (0)",
"HTLC out 2 RCVD_REMOVE_COMMIT->SENT_REMOVE_REVOCATION",
"HTLC out 2 SENT_REMOVE_REVOCATION->SENT_REMOVE_ACK_COMMIT",
"got revoke 15: 1 changed",
"HTLC out 2 SENT_REMOVE_ACK_COMMIT->RCVD_REMOVE_ACK_REVOCATION",
"Removing out HTLC 2 state RCVD_REMOVE_ACK_REVOCATION REMOTEFAIL",
"htlc 2 failed from 1th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE)",
"got revoke 16: 0 changed",
"got commitsig 17: feerate 23828, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 17: 0 changed",
"got commitsig 18: feerate 23835, 0 added, 0 fulfilled, 0 failed, 0 changed",
"got revoke 18: 0 changed",
"got commitsig 19: feerate 23795, 0 added, 0 fulfilled, 0 failed, 0 changed",
"HTLC out 3 SENT_ADD_HTLC->SENT_ADD_COMMIT",
"got revoke 19: 1 changed",
"HTLC out 3 SENT_ADD_COMMIT->RCVD_ADD_REVOCATION",
"got commitsig 20: feerate 23795, 0 added, 0 fulfilled, 0 failed, 1 changed",
"HTLC out 3 RCVD_ADD_REVOCATION->RCVD_ADD_ACK_COMMIT",
"HTLC out 3 RCVD_ADD_ACK_COMMIT->SENT_ADD_ACK_REVOCATION",
"got commitsig 21: feerate 23795, 0 added, 0 fulfilled, 1 failed, 0 changed",
"HTLC out 3 SENT_ADD_ACK_REVOCATION->RCVD_REMOVE_COMMIT",
"Our HTLC 3 failed (0)",
"HTLC out 3 RCVD_REMOVE_COMMIT->SENT_REMOVE_REVOCATION",
"HTLC out 3 SENT_REMOVE_REVOCATION->SENT_REMOVE_ACK_COMMIT",
"got revoke 20: 1 changed",
"HTLC out 3 SENT_REMOVE_ACK_COMMIT->RCVD_REMOVE_ACK_REVOCATION",
"Removing out HTLC 3 state RCVD_REMOVE_ACK_REVOCATION REMOTEFAIL",
"htlc 3 failed from 1th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE)",
"got revoke 21: 0 changed",
"got commitsig 22: feerate 26450, 0 added, 0 fulfilled, 0 failed, 0 changed"
]
}
]
}
The problem was resolved for me in #823. There is getinfo output in case if you need it:
{ "id" : "02aa4c89b04aab2f37cf1590ba48e6cb80ead72781e94648254f3b2cca6cb72f59", "port" : 9735, "address" :
[
{ "type" : "ipv4", "address" : "64.99.224.88", "port" : 9735 } ], "version" : "v0.5.2-2016-11-21-1703-gd03ca59", "blockheight" : 506663, "network" : "bitcoin" }
3 days passed and its still CHANNELD_AWAITING_LOCKIN.
Most helpful comment
Ok, so can everybody confirm that once a channel gets stuck in this situation then all subsequent channels will also get stuck?