ElementsProject / lightning

Core Lightning — Lightning Network implementation focusing on spec compliance and performance
Other
2.86k stars 906 forks source link

Problems opening and closing channels #1226

Closed joepetrowski closed 6 years ago

joepetrowski commented 6 years ago

Issue and Steps to Reproduce

I have a few questions/issues, so I will ask here and put info at the bottom.

  1. I tried opening a new channel with SLEEPYARK, but the state has been "CHANNELD_AWAITING_LOCKIN" for almost 24 hours and the transaction is not on the blockchain. However, the funds are not listed in the wallet. Is there a way to cancel this open and restore the funds? Any idea what went wrong? (TXID: c2a1c0b8223608307ab14fa8dd3bc04165dc49592dcb6d95bd79a9257bc57afa) Note that I did change "dev-setfees" to 250 250 250 before opening the channel, so maybe that is related?

  2. I tried closing a channel two weeks ago with OLD.rompert.com, but it is still "CLOSINGD_SIGEXCHANGE". Is it possible to force this to close?

  3. In "listfunds", is it possible to see a list of addresses in your lightning wallet?

Thanks. Relevant outputs below:

getinfo output

$ ./cli/lightning-cli getinfo
{ "id" : "0383833f156304e98fb1be1e85ca93eac09a521c1620173c3f76e7f031ecefcb97", "port" : 9735, "address" : 
    [  ], "version" : "v0.5.2-2016-11-21-2315-gf9bc0353", "blockheight" : 513767, "network" : "bitcoin" }

listfunds output

$ ./cli/lightning-cli listfunds
{ "outputs" : 
    [ 
        { "txid" : "c2a1c0b8223608307ab14fa8dd3bc04165dc49592dcb6d95bd79a9257bc57afa", "output" : 0, "value" : 18265, "status" : "unconfirmed" } ], "channels" : 
    [ 
        { "peer_id" : "03cbf298b068300be33f06c947b9d3f00a0f0e8089da3233f5db37e81d3a596fe1", "short_channel_id" : "509803:1299:1", "channel_sat" : 115000, "channel_total_sat" : 115000, "funding_txid" : "0e0a104a661a0d52d152827d69834392fb6c30af53f654385c5269896cdec51c" }, 
        { "peer_id" : "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432", "channel_sat" : 100000, "channel_total_sat" : 100000, "funding_txid" : "c2a1c0b8223608307ab14fa8dd3bc04165dc49592dcb6d95bd79a9257bc57afa" } ] }

listpeers output

$ ./cli/lightning-cli listpeers
{ "peers" : 
    [ 
        { "id" : "03cbf298b068300be33f06c947b9d3f00a0f0e8089da3233f5db37e81d3a596fe1", "connected" : true, "netaddr" : 
            [ "45.55.47.17:9735" ], "alias" : "OLD.rompert.com", "color" : "0000ff", "channels" : 
            [ 
                { "state" : "CLOSINGD_SIGEXCHANGE", "owner" : "lightning_closingd", "short_channel_id" : "509803:1299:1", "funding_txid" : "0e0a104a661a0d52d152827d69834392fb6c30af53f654385c5269896cdec51c", "msatoshi_to_us" : 115000000, "msatoshi_total" : 115000000, "dust_limit_satoshis" : 546, "max_htlc_value_in_flight_msat" : 18446744073709551615, "channel_reserve_satoshis" : 0, "htlc_minimum_msat" : 0, "their_to_self_delay" : 144, "our_to_self_delay" : 144, "to_self_delay" : 144, "max_accepted_htlcs" : 483, "status" : 
                    [ "CLOSINGD_SIGEXCHANGE:Negotiating closing fee between 724 and 1134 satoshi (ideal 724)", "CLOSINGD_SIGEXCHANGE:Waiting for their initial closing fee offer: ours was 724 satoshi" ] } ] }, 
        { "id" : "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432", "connected" : true, "netaddr" : 
            [ "104.198.32.198:9735" ], "alias" : "SLEEPYARK", "color" : "02f672", "channels" : 
            [ 
                { "state" : "CHANNELD_AWAITING_LOCKIN", "owner" : "lightning_channeld", "funding_txid" : "c2a1c0b8223608307ab14fa8dd3bc04165dc49592dcb6d95bd79a9257bc57afa", "msatoshi_to_us" : 100000000, "msatoshi_total" : 100000000, "dust_limit_satoshis" : 546, "max_htlc_value_in_flight_msat" : 18446744073709551615, "channel_reserve_satoshis" : 0, "htlc_minimum_msat" : 0, "their_to_self_delay" : 144, "our_to_self_delay" : 144, "to_self_delay" : 144, "max_accepted_htlcs" : 483, "status" : 
                    [ "CHANNELD_AWAITING_LOCKIN:Reconnected, and reestablished.", "CHANNELD_AWAITING_LOCKIN:Funding needs more confirmations." ] } ] } ] }

listconfigs output

$ ./cli/lightning-cli listconfigs
{ "# version" : "v0.5.2-2016-11-21-2315-gf9bc0353", "port" : 9735, "bitcoin-datadir" : "/media/blockstorage/bitcoincore", "rgb" : "038383", "alias" : "TheConcavity", "pid-file" : "lightningd-bitcoin.pid", "channel-update-interval" : 604800, "log-level" : "DEBUG", "log-prefix" : "lightningd(2006):", "lightning-dir" : "/home/cryptonodes/.lightning", "rpc-file" : "lightning-rpc", "daemon" : "false", "ignore-fee-limits" : false, "locktime-blocks" : 144, "max-locktime-blocks" : 432, "anchor-onchain" : 10, "anchor-confirms" : 3, "max-anchor-confirms" : 10, "commit-fee-min" : 200, "commit-fee-max" : 2000, "commit-fee" : 500, "override-fee-rates" : "1000/1000/1000", "default-fee-rate" : 40000, "cltv-delta" : 14, "cltv-final" : 8, "max-htlc-expiry" : 720, "bitcoind-poll" : "30s", "commit-time" : "10ms", "fee-base" : 1000, "fee-per-satoshi" : 10, "network" : "bitcoin", "allow-deprecated-apis" : true, "dev-no-reconnect" : "false", "dev-fail-on-subdaemon-fail" : "false", "dev-broadcast-interval" : 60000 }
ZmnSCPxj commented 6 years ago
  1. We are having problems recently with bitcoind estimatesmartfee suggesting fees so low as to be below the minimum relay fee common on the blockchain layer, possible it is related? Can you check the lightningd log for failure in bitoind sendrawtransaction?
  2. You can try the dev-fail command. It should be present by default unless you deliberately compiled with DEVELOPER=0. This is so useful it should not be a dev command.
  3. This is a surprisingly good idea.
joepetrowski commented 6 years ago
  1. This is a dumb question, but where is the lightningd log file stored? I've been poking around and don't see it, and the tmux terminal it's running in doesn't store enough lines to go back. I do remember seeing an error message like "no inputs". If you can give me the file path/name I can get the exact message and sendrawtransaction info.

  2. That worked! Very useful, the closure is in a valid block now.

  3. Glad I could suggest something useful! Figured the info was in there.

ZmnSCPxj commented 6 years ago
  1. Hmm, well it did not get stored if you did not store it specifically, haha. Use the --log-file= option to indicate a log file. But if you remember a "inputs not found" error, then it is very likely a recent issue (that has been fixed, I think... pinging @cdecker) about tracking unspent transaction outputs. While updating to latest will prevent the error, once the error has been written to database it will persist. @cdecker may be able to give more specific instructions.
joepetrowski commented 6 years ago

Ha, well that explains it. Restarting with a log file for the future. I did upgrade to the most recent version yesterday. Just want to figure out the problem before committing more funds to a new channel. I believe it has to do with fees as I have successfully opened a channel, bought my sticker, and closed it with the default build. I was just playing around with some more options when I ran into this.

"# version" : "v0.5.2-2016-11-21-2315-gf9bc0353"

cdecker commented 6 years ago

"Inputs not found" usually is just an indication that we are either resending a transaction that bitcoind already knows about, therefore the inputs were already spent, or trying to spend the change output of a transaction that was not seen/confirmed. The latter case may be a followup error of the fee estimation being below the relay fee, while the former is ok to ignore.

In the case of the channel with funding tx c2a1c0b8223608307ab14fa8dd3bc04165dc49592dcb6d95bd79a9257bc57afa I can't find it on-chain so it might very well have been caused by fees smaller than the relay fee. In any case dev-rescan-outputs should sync the output state and return them to the internal wallet.

joepetrowski commented 6 years ago

dev-rescan-outputs worked and everything is back to normal. I was thinking that dev-rescan-outputs wouldn't fix a transaction stuck in mempool, but since that tx never made it into mempool it makes sense that it returns those outputs to the internal wallet.

Thanks for you help, closing this issue.

cdecker commented 6 years ago

Glad it worked out, we'll try to address the fee<relay_fee issue asap