Lightning: fundchannel doesn't do anything

[thestick613]

On testnet, i was able to connect, but i wasn't able to fund the channel:

./cli/lightning-cli connect 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df 85.103.49.22
{ "id" : "039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df" }
./cli/lightning-cli fundchannel 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df 16000000

It's been like that for 5 minutes. I think it should have a timeout. The output of lightningd is too big to follow.

[ZmnSCPxj]

Channel opens are onchain operations and long wait times are normal here. Even on testnet blocks will still arrive about every 10minutes, so waiting more than 10 minutes can occur every now and then.

[thestick613]

No, i mean the program seems to have hanged. After some time (i left my computer, don't know when), it outputed this:
"Owning subdaemon lightning_openingd died (33792)"

The listfunds command shows the same output as before running fundchannel but getpeers shows me

                { "state" : "ONCHAIND_THEIR_UNILATERAL", "netaddr" :
                        [  ], "peerid" : "03f7ca17791a976478e7511f10a36191a8c4e70380a5e18d7e173a0efcd23edcdf", "connected" : false, "channel" : "1258049:33:0", "msatoshi_to_us" : 0, "msatoshi_total" : 230
00000 },

[ZmnSCPxj]

Looks like the counterparty closed it while you were waiting, or maybe db got thrashed. Openingd runs up to funding_signed only, though. Logs probably needed especially what openingd said before dying.

[cdecker]

their-unilateral suggests that the channel creation worked ok, but the the other side decided to close and refund you your coins. Since it's them closing unilaterally you get your funds back immediately. From the funding transaction I can see that you attempted to open more channels, is that correct?

[thestick613]

I messed up, the getpeers output was from another peer. I thought it was the same one

039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df
is the right one, not
03f7ca17791a976478e7511f10a36191a8c4e70380a5e18d7e173a0efcd23edcdf

getpeers doesn't show me anything related to 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df, so i guess nothing happened.

[cdecker]

If we don't have any stake in the channel we forget it immediately, not only after resolving all funds, so that is still a possibility. their-unilateral definitely requires some interaction with the remote peer.

[thestick613]

Only the first half of this comment is accurate. The getpeers output is from a different peer, totally unrelated to this issue.

[cdecker]

Let's reconstruct the complete picture:

• Node1 03f7ca17791a976478e7511f10a36191a8c4e70380a5e18d7e173a0efcd23edcdf connected to Node2 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df
  
  
  
  • Node1 funds a channel with Node2, with a total capacity of 16000000 msatoshi
  
  
  • Funding hangs for a long time (could be due to low value, testnet flakyness, ...)
  
  
  • After a while Node2 says that Node1 did a unilateral close and has no added funds (since it didn't own anything in the channel)
  
  
  • Node1 doesn't say anything when using getpeers?
  
  

Somehow there is a mismatch between the funding amount (16k satoshi) and the funding transaciton on-chain (230 satoshi). are you sure that is all part of the same test?

[thestick613]

Nope, i'm 02cbaa0f40db314ef15ad2b1340e3c5c18b0a5c88551ce2debc1fd76d64e061873. I connected to 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df. I funded 16000000. Funding hanged for 15 minutes (i think). The command outputed
"Owning subdaemon lightning_openingd died (33792)">
getpeers doesn's how anything about 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df. The node 03f7ca17791a976478e7511f10a36191a8c4e70380a5e18d7e173a0efcd23edcdf is completely unrelated to this issue. I thought it was the same one because it started with 03 and ended with df.

[cdecker]

Ok, do you happen to have access to the logs of 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df? And your full logs would also be helpful.

[thestick613]

No logs for 039def126364b80424cafa2fa2a3c5bea614237edbcd134066f552b7d3795301df. My own log has already scrolled, so I'll try to fundchannel again and save the logs to a file.

[cdecker]

Closing since we were unable to reproduce this issue. The JSON-RPC interface has changed quite a bit in the meantime, and we ensure that every command gets a valid response now. Very few commands are synchronous, e.g., wait for things to happen onchain, so this should be solved.