Channel "AWAITING_UNILATERAL" since days. Attempted force closing, CPU 100% #2171
Comments
|
The funding tx |
|
Yeah. Exactly. I will look into the log files and report. |
|
These are some lines of the log in which also appears the opening tx with some error. |
|
The 2nd input (txid The software version says it has been modified, anything related to the wallet or coin selection perhaps? |
|
mmh. Honestly I don't know.
These steps could lead to a modded version? Months ago I built a version to use This is the last line of |
|
Admittedly I am not an If you have EDIT: Best to shut down c-lightning before query the db, or make a copy of To see what the database says about any outputs from that |
|
|
I have similar issues awaiting forever.. looks like i lost a couple hundred usd on my LN node.. server was down for 8 days when i got it repaired and put it up.. i cant close channels. and have no outputs :( |
|
Also: Sorry to be a noob about sqlite3 but it seems like I can't see the database. |
|
Hmmm ... strange, are you sure you opened the correct database file? The default location is EDIT: txid's in the database are stored in internal-byte-order (not RPC-byte-order as shown by bitcoin-cli and lightning-cli etc.), so had to reverse that ... sorry Then from within that directory try: if that still doesn't show anything, then the other (#0) input of the funding-tx should definitely show up: Note that the |
|
|
Sorry if it wasn't clear in my previous post, but the byte-order of the My previous post shows the correct command. |
|
Bingo! |
|
Thank you for reporting this. Clearly the database does not reflect the reality of the blockchain, i.e. both outputs have I have no idea how that happened, but if your clightning source directory is still in the same state as during build, could you try there a I am a bit hesitant to recommend a |
|
OTOH if you guys think it doesn't worth to investigate further due to the "modded" nature of my tree |
|
I just learned that However unconfirmed change_outputs from a funding tx can be selected as inputs for the next funding tx (for a new channel). This works fine as long as the first funding tx is broadcasted (accepted in mempool), but if for some reason the first funding tx was not broadcasted (maybe due to So somewhere up the chain of our outputs, a funding tx was not properly broadcasted. It would be interesting to find out why, so maybe a: in the logfile to find the corresponding Please don't broadcast or post the original failed tx before we know more why it failed. |
|
Likely cause of the -modded version name is that, when doing Instead, use |
"chan #10" doesn't seem to me the channel ID. Do I have to |
|
I was able to get some of my channels unstuck by re-broadcasting the funding transaction the other day, and then using That'll give you a list of transactions that we broadcast but where not yet confirmed. We can then take those transactions and identify the funding transaction (complicated a bit by the fact that we store the You can then take the rawtx and re-broadcast it either with one of the You might also want to first check that it is the transaction you were expecting using |
|
Thank you Christian: The transaction id of the two are:
If I look for them with the second query you gave me they give me bak the raw funding transaction which have no inputs: I'm probably missing something but if the raw funding transaction had no input (see above), if I rebroadcast it still haven't. EDIT: it turns out that 1 input of the first transaction and 1 of the second funding transaction belonged to two NON broadcast transactions. I did broadcast them (NOW). Waiting... Stay tuned. :) |
|
Ok. The txs are all confirmed. |
|
Update: I have tried to rebroadcast all the transaction I had in result of the query and now the situation is: I have still three transactions not broadcasted, using the first query. The first and the second ones use inputs already spent by other transactions and the third is already on the blockchain. |
|
The situation seems to be resolved: I would like thank you @SimonVrouwe and @Snyke for the precious help.
|
|
@gabridome thanks for the tip. I think the most likely cause for a stuck tx is when, for whatever reason, a dependent (parent) tx was not broadcast, i.e. not accepted in mempool. in code below lightning/lightningd/opening_control.c Lines 366 to 376 in b542377 For example when you call In my opinion this should be improved, but it appears not so simple because |
So, if I understand correctly, if c-lightning was aware of the failure would consider all the inputs as unspent output for subsequent transactions. Instead it considers the change_output of the failed transaction as available and this is why subsequent transactions, using those change_outputs fail as well. It seems like something like a "rollback" function is needed in this case, given the negative outcome of |
Have been thinking about this also, not sure what is the right approach. I think once the |
Or until confirmation? before confirmation a new output shouldn't be considered spendable IMVHO. It seems a problem also normal wallets have: when change output are to be considered spendable and what to do in the meanwhile? |
SimonVrouwe
added a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 17, 2019
- result 'fundchannel' command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - failure still fails the channel into -> AWAITING_UNILATERAL This gives the user a more explicit warning of broadcast failure, so it (hopefully) doesn't try to broadcast new tx's that depend on its change_outputs, see issue ElementsProject#2171 openingd/opening_funder_finished: broadcast_tx callback function now handles both success and failure pytest: mock_sendrawtransaction now returns error _number_, the jsonrpc's command_fail needs a _number_ instead of 'error' jsonrpc: added error code FUNDING_BROADCAST_FAIL improved some comments
SimonVrouwe
added a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 18, 2019
- result 'fundchannel' command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in `CHANNELD_AWAITING_LOCKIN` - user could then manually rebroadcast tx and keep the channel This gives the user a more explicit warning of broadcast failure, so it (hopefully) doesn't try to broadcast new tx's that depend on its change_outputs, see issue ElementsProject#2171 openingd/opening_funder_finished: broadcast_tx callback function now handles both success and failure pytest: mock_sendrawtransaction now returns error _number_, the jsonrpc's command_fail needs a _number_ instead of 'error' jsonrpc: added error code FUNDING_BROADCAST_FAIL improved some comments
rustyrussell
pushed a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 23, 2019
- result 'fundchannel' command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in `CHANNELD_AWAITING_LOCKIN` - user could then manually rebroadcast tx and keep the channel This gives the user a more explicit warning of broadcast failure, so it (hopefully) doesn't try to broadcast new tx's that depend on its change_outputs, see issue ElementsProject#2171 openingd/opening_funder_finished: broadcast_tx callback function now handles both success and failure jsonrpc: added error code FUNDING_BROADCAST_FAIL
rustyrussell
pushed a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 24, 2019
- result 'fundchannel' command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in `CHANNELD_AWAITING_LOCKIN` - user could then manually rebroadcast tx and keep the channel This gives the user a more explicit warning of broadcast failure, so it (hopefully) doesn't try to broadcast new tx's that depend on its change_outputs, see issue ElementsProject#2171 openingd/opening_funder_finished: broadcast_tx callback function now handles both success and failure jsonrpc: added error code FUNDING_BROADCAST_FAIL
SimonVrouwe
added a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 26, 2019
- result fundchannel command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in CHANNELD_AWAITING_LOCKIN - after fixing the initial broadcast failure, the user could manually rebroadcast the tx and keep the channel openingd/opening_funder_finished: - broadcast_tx callback function now handles both success and failure jsonrpc: added error code FUNDING_BROADCAST_FAIL manpage: added error code returned by fundchannel command This makes the user more aware of broadcast failure, so it hopefully doesn't try to broadcast new tx's that depend on its change_outputs. Some users have reported (see issue ElementsProject#2171) a whole sequence of fundings failing, because each funding was using the change output of the previous one, which would not confirm.
SimonVrouwe
added a commit
to SimonVrouwe/lightning
that referenced
this issue
Jan 26, 2019
- result fundchannel command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in CHANNELD_AWAITING_LOCKIN - after fixing the initial broadcast failure, the user could manually rebroadcast the tx and keep the channel openingd/opening_funder_finished: - broadcast_tx callback function now handles both success and failure jsonrpc: added error code FUNDING_BROADCAST_FAIL manpage: added error code returned by fundchannel command This makes the user more aware of broadcast failure, so it hopefully doesn't try to broadcast new tx's that depend on its change_outputs. Some users have reported (see issue ElementsProject#2171) a whole sequence of fundings failing, because each funding was using the change output of the previous one, which would not confirm.
rustyrussell
pushed a commit
that referenced
this issue
Jan 29, 2019
- result fundchannel command now depends on successful or failed broadcast of the funding tx - failure returns error code FUNDING_BROADCAST_FAIL - don't fail the channel when broadcast failed, but keep in CHANNELD_AWAITING_LOCKIN - after fixing the initial broadcast failure, the user could manually rebroadcast the tx and keep the channel openingd/opening_funder_finished: - broadcast_tx callback function now handles both success and failure jsonrpc: added error code FUNDING_BROADCAST_FAIL manpage: added error code returned by fundchannel command This makes the user more aware of broadcast failure, so it hopefully doesn't try to broadcast new tx's that depend on its change_outputs. Some users have reported (see issue #2171) a whole sequence of fundings failing, because each funding was using the change output of the previous one, which would not confirm.
Closed
4 tasks
|
Hi, I'm a noob but wanted to note that I have needed to reference this thread a couple times. Once with a channel stuck at "AWAITING_UNILATERAL" for days and again this morning with a channel stuck at "CHANNELD_AWAITING_LOCKIN" for days. In both cases, rebroadcasting the transaction through bitcoin_cli with the rawtx did the trick. My bitcoin node connects via tor proxy and I also use NordVPN. Maybe I missed something and this config is not recommended with c-lightning? Otherwise, I just wanted to state things for the record... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found one of my channel was in "AWAITING_UNILATERAL" so I waited but days after it was still in that state.
Relevant log with grep peerID:
Today I have tried to force close the channel but the command is stucked and the CPU is 100%.
I have interrupted the command but it seems like every command (getinfo included) is causing 100% CPU and the freezing of the command itself.
Restarting the service, I was able to collect some more infos:
getinfooutputnot possible (due to 100%CPU issue) but running tags/v0.6.2
EDIT: restarting the service:
The text was updated successfully, but these errors were encountered: