Lightning: Funds stuck in limbo after incorrect order of fundchannel_* RPC calls

[meeDamian]

Issue and Steps to Reproduce

As an attempt to do what #1936 aims to streamline:

1. Run lightning-cli fundchannel_start
2. Create & broadcast BTC transaction
3. Run lightning-cli fundchannel_complete with non-zero delay

getinfo output

{
  "id": "032260c3b64b471b7eb0630b4af5d07ca94ff4e759573cbbe1bfb25845c375ed6e",
  "alias": "lncm-dm-1",
  "color": "ef4e91",
  "num_peers": 32,
  "num_pending_channels": 19,
  "num_active_channels": 13,
  "num_inactive_channels": 0,
  "address": [
    {
      "type": "ipv4",
      "address": "203.150.177.97",
      "port": 9735
    },
    {
      "type": "torv3",
      "address": "o3s5j4j37nbyzgvbngn3ahpmttvviyensw34klhqzw7in7vfzz646lqd.onion",
      "port": 9735
    }
  ],
  "binding": [
    {
      "type": "ipv4",
      "address": "192.168.0.201",
      "port": 9735
    },
    {
      "type": "ipv4",
      "address": "127.0.0.1",
      "port": 9735
    }
  ],
  "version": "v0.7.1",
  "blockheight": 591066,
  "network": "bitcoin",
  "msatoshi_fees_collected": 2083,
  "fees_collected_msat": "2083msat"
}

More details here: https://bitcoin.stackexchange.com/q/89817/9223

Some thoughts:

• Perhaps fundchannel_complete could be renamed to something along the lines of:

  • _commit
  • _ensure
  • _preconfirm
  • _confirm
  • _confirmcommit

• Perhaps wording in help fundchannel_complete should be changed to:

  Note that the funding transaction ~should not~ MUST NOT be broadcast until…

PS. Funds still stuck here: 1e643a835a9d1b0d2d0066bfaec516e2f8c282f8968dc74c12c2e430c8be9721

[ZmnSCPxj]

Originally it was named fundchannel_continue, @rustyrussell insisted on _complete: https://github.com/ElementsProject/lightning/pull/2672#issuecomment-498455900

Given it is difficult to change the interface after-the-fact it is unlikely we can change the name at this point.

I do agree MUST NOT must be better verbiage for this.

See #2740 about proper order of operations.

fundchannel_start and fundchannel_continue are low-level operations and should be wrapped by proper plugins with really good test suites, as low-level operations.

[rustyrussell]

I think we should need to write the plugin, to avoid such mistakes in future. And since i was the one (IIRC) who insisted we expose at this low-level, I think I should be the one to do it.

[ZmnSCPxj]

We need #2740 first, and probably some kind of workaround for #2741.

[meeDamian]

So while I'm obviously not blaming anyone for my #reckless mistake 🙈, shall I consider the coins sent to channels that never opened to be my accidental donation to Bitcoin's scarcity, or is there still a chance to somehow recover any of it?

$ lightning-cli listpeers | jq -r '[.peers[].channels[] | select((.funding_txid == "1e643a835a9d1b0d2d0066bfaec516e2f8c282f8968dc74c12c2e430c8be9721") and .state != "CHANNELD_NORMAL") | .msatoshi_total] | add | . / 1e3 / 1e8 | tostring | . + " BTC donated"'
0.07004436 BTC donated

And if it indeed is a donation, is there a way to make c-lightning allow me to move past my _past_ mistakes, and allow me to open, this time hopefully functional, channels to these peers again?

Happy to do any of it manually, if needed.

[ZmnSCPxj]

Those are unrecoveranle.

If you have DEVELOPER set up for the compile then dev-forget-channel command exists.