ChannelArbitrator still awaiting contract resolution (Bitcoin TXN not broadcast) #1071
Comments
|
So I see the closing transaction here: https://www.smartbit.com.au/tx/306842fa2172d2142909d2f483390cb5289708433b1d6b52809be1e1320e8a60 Note that if you force closed a channel, but didn't have any active funds, then we won't need to track it any longer. |
|
We'll auto broadcast transactions at this point. Perhaps the remote party also force closed the transaction, and it was the alternative transaction that was chosen for block inclusion. If this was the case, a pending PR will resolve this issue. |
|
Looking at the |
|
Isn't 306842fa2172d2142909d2f483390cb5289708433b1d6b52809be1e1320e8a60 the opening transaction to create the channel? The funding amount was 0.00125 BTC. The closing transaction would be less than the 0.00125 BTC minus on-chain fees--shown in the output in the Background section above. I believe I did the force close "around April 6" so, yes, I could be off a day or two. :) I pulled that transaction from my bitcoind debug.log: bitcoin-cli gettxout "306842fa2172d2142909d2f483390cb5289708433b1d6b52809be1e1320e8a60" 0 Thank you for looking at this. Please let me know if there is anything further. I will wait on the PR and maintain this node in its current state until resolved. Thank you again. :) |
|
You sent a chan point of: That means the opening transaction txid is |
|
From examining the chain: all funds were fully swept. |
|
Output as of now...note limbo balance: |
|
What I'm saying is the other commitment transaction was confirmed, and the funds were swept (as both outputs are spent on-chain), but it's a cosmetic bug that the RPC itself wasn't properly updated. One restarts, if you set |
|
This is the commitment transaction: https://www.smartbit.com.au/tx/433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289 Observe that both outputs are spent. |
|
If this is cosmetic, I don't want to bother everyone with a low priority item. I will continue to provide detail if needed. :) With the CNCT=trace option and grep for the commitment transaction: cat lnd.log | grep 433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289 2018-04-10 18:52:43.282 [ERR] CNCT: ChannelArbitrator(433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1): unable to progress resolver: quitting |
|
Full output of the CNCT grep... |
|
Should be fixed by #1088? |
|
After updating to the current master, I believe I successfully installed the PR 1088 since it is not merged into the master as of now. If I recall correctly, I did a 'git checkout 1088' and a 'make && make install.' (Note: This is my first experience with git. This may not be the correct/appropriate/complete way to add a PR to your install.) (which matches the commit for 1088) Currently: And logs (with CNCT trace on): I also noticed this but not sure if it is relevant: I will continue to monitor and update. Please let me know what additional information you need. |
|
Worth noting that all funds have been swept from that channel, so your wallet has the proper balance. The issue is that we attempted to play one commit, while the other confirmed. This will be fixed by #1017. |
|
Thank you. I will continue to monitor and return to the master version--likely after #1017 is merged. |
|
Changed back to master earlier today in anticipation of this merge. Updated lnd to this commit:
I let lnd run for ~10 minutes and here are the results: And relevant log entries with the CNCT=trace level on: Please let me know if you need additional detail. Thanks! |
|
Both outputs on that commitment have been swept. This means that all the coins in the channel has been fully recovered by Basically, the resolver is waiting for a transaction that will never confirm, since it's the case that another commitment transaction confirmed instead. |
|
We'll be adding a "forget channels" debug RPC soon-ish. This will let users clear up state like this due to fixed bugs. |
|
Understood...just providing follow-up. Thank you for the explanation. I'm not a dev but I follow instructions fairly well. ;) |
Background
First, my intent was to increase my channel funding across the board so I was starting to close channels. I was unable to close a channel normally and also with --force. I received the "channel not found" error. I then learned about adding the --output_value which did find/close the channel but I forgot to remove the --force option. I believe the remote node was online when this command executed and did not intend to force close a active node's channel.
The force close was executed around April 6 and today is still in the state below.
{
"channel": {
"remote_node_pub": "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
"channel_point": "433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1",
"capacity": "125000",
"local_balance": "123733",
"remote_balance": "0"
},
"closing_txid": "842ca6090873a685ca47dd736b65445bb8a894edceeb69a738d7514605aae381",
"limbo_balance": "123733",
"maturity_height": 0,
"blocks_til_maturity": 0,
"recovered_balance": "0",
"pending_htlcs": [
]
The transaction is not found on the Bitcoin explorer (https://blockchain.info/search?search=842ca6090873a685ca47dd736b65445bb8a894edceeb69a738d7514605aae38). I thought this was due to the contract timeout/wait period due to the --force (uncooperative close). To test, I force closed another channel (with an offline node) and the transaction was broadcast immediately and shows a positive value for "blocks_til_maturity" (which is now decreasing normally).
From lnd.log:
2018-04-10 09:09:48.450 [ERR] CNCT: ChannelArbitrator(433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1): unable to progress resolver: quitting
2018-04-10 09:11:12.651 [INF] CNCT: ChannelArbitrator(433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1): starting state=StateWaitingFullResolu
tion
2018-04-10 09:11:12.655 [INF] CNCT: ChannelArbitrator(433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1): still awaiting contract resolution
2018-04-10 09:11:12.724 [INF] CNCT: ChannelArbitrator(433cf78c90da64870ffa918e19b52761eae463855f9f56bff1374613aa46f289:1): relaunching 1 contract resolvers
Apologies but I have overrun the logs after switching to a "debug" level of logging to find more detail so I am not able to provide any further logs of the actual closing. There is nothing in the bitcoin logs for:
bitcoin-cli gettxout "842ca6090873a685ca47dd736b65445bb8a894edceeb69a738d7514605aae381" 0
To check, the following transaction does appear for the test "force" channel close mentioned earlier:
bitcoin-cli gettxout "1d0d51f27d7f7d0670db8547a76fa39abea55d51d5009ae405db032da0ee781d" 0
{
"bestblock": "00000000000000000006a1f76c18d2d0445e98991e29e26832955b6b217092fd",
"confirmations": 122,
"value": 0.00121923,
"scriptPubKey": {
"asm": "0 32cb2dd2957bda0be6b3ba17c93365654840d616e6f9451671e1c69de594b79f",
"hex": "002032cb2dd2957bda0be6b3ba17c93365654840d616e6f9451671e1c69de594b79f",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"bc1qxt9jm55400dqhe4nhgtujvm9v4yyp4skumu529n3u8rfmev5k70sywcyzx"
]
},
"coinbase": false
}
Is there a mechanism for the LND to rebroadcast a transaction in this state? Is there a manual process to use in order to recover the funds?
Your environment
Steps to reproduce
Unable to reproduce--tested with another channel close with --force but with an offline node. This test is proceeding normally as shown by "blocks_til_maturity" decreasing.
Expected behaviour
(I'm not a developer/coder so this is just my logic as a suggestion.) If the contract resolution or other timeouts expire without resolution maybe the transaction could be rebroadcast. Or, an error condition should be pushed to the user for further action (even if manual during beta phase). Otherwise, you are the experts. :)
Actual behaviour
Force channel close has resulted in a hung state at "blocks_til_maturity" at 0 value. Transaction was never sent by bitcoind or possibly LND. No re-transmit mechanism or error to user exists for this case. See information above.
Next steps
Please let me know if additional detail is required. The LND logs are probably a no-go for any historical information but the bitcoind logs should be fine.
Thank you for all your efforts and expertise.
The text was updated successfully, but these errors were encountered: