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: #2672 (comment)

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.