Consider setting RBF flag for Lightning funding transactions

[SomberNight]

Currently we intentionally don't set the RBF flag for LN funding transactions (channel opening txs).

electrum/electrum/lnpeer.py

Line 686 in 84326cf

funding_tx.set_rbf(False)

This means that if the user lowballs the fee, the funding tx can get stuck in the mempool in limbo for a very long time, and the user has essentially no recourse: all they can do is wait.

To be clear, with current the Lightning/BOLT v1 spec, it is not possible to non-destructively bump the fee of a funding transaction. That is, if we bump the fee and keep the funding output, the txid changes which invalidates the channel id, and the remote peer will not find the funding outpoint -- the funds then can only be recovered manually through with the help of the channel counterparty.
Bumping the fee should be possible in the future with the channel v2 spec (lightning/bolts#524), but naturally only in a collaborative way (the peers need to exchange messages).

Code in wallet.py only allows bumping the fee of a tx that both (1) opted in to RBF, and (2) is not a LN funding tx for one of our channels:

electrum/electrum/wallet.py

Line 618 in 84326cf

can_bump = is_any_input_ismine and not tx.is_final()

electrum/electrum/wallet.py

Lines 647 to 648 in 84326cf

	if is_lightning_funding_tx:
	can_bump = False # would change txid

As said at the beginning, we don't set RBF for our funding txs, so check (2) is actually not relied on right now.

The issue is that not opting in to RBF not only disables bump_fee but also e.g. double-spend cancelling the tx:

electrum/electrum/wallet.py

Line 619 in 84326cf

can_dscancel = (is_any_input_ismine and not tx.is_final()

(and not just in the code but on a bitcoin p2p relay level as well).

So, we could opt-in to RBF, detect the tx is a funding tx, and not allow bump_fee but still allow dscancel.
Further, advanced users can always manually craft conflicting txs that spend the coins in a custom manner, but relaying the tx on bitcoin peer-to-peer is kind of hopeless without opt-in RBF.

However, what if the user uses the same wallet (seed) on multiple devices?! Check (2) only works on the device that has the Lightning state for said channel. If we opt-in to RBF, the user might shoot themselves in the foot and run bump_fee on the funding tx on another device.

Note that even with channel v2, this core problem remains: and it actually becomes more likely I expect! LN peers likely will want to opt-in to RBF, and users with multiple devices might run bump_fee on the funding tx - and the second device does not know to notify the channel counterparty about the replacement.

---

Note that we have been thinking about putting an OP_RETURN output on funding txs, with some encrypted data, for channel-recovery purposes. That would also mitigate this, if the second device is able to decrypt the data and identify the tx as a funding tx (and disable bump_fee in that case in the UI).

[SomberNight]

related:
#6127
#6134

[SomberNight]

However, what if the user uses the same wallet (seed) on multiple devices?! Check (2) only works on the device that has the Lightning state for said channel. If we opt-in to RBF, the user might shoot themselves in the foot and run bump_fee on the funding tx on another device.
Note that we have been thinking about putting an OP_RETURN output on funding txs, with some encrypted data, for channel-recovery purposes. That would also mitigate this, if the second device is able to decrypt the data and identify the tx as a funding tx (and disable bump_fee in that case in the UI).

Note: onchain backups were added in 4.1, and so with check (2), not only the device that has the lightning state knows whether a tx is a funding tx but also any other device with the same seed if they have onchain backups ("recoverable channels") enabled (or if they manually imported a channel backup).

[ecdsa]

Note: on-chain backups are optional. In the long term, I think we should try to have a model where channels are opened by a server to the user, and where any user who open a channel themselves should be considered advanced/expert.