Allow configuring the number of confs required for lightning channels

[supertestnet]

Description

Feature request

Please give electrum users and devs the ability to configure how many confirmations electrum requires for channels opened to them by a third party. The options I would like are:

• require 3 confs (this is what is currently hard-coded and should remain an option imo)
• require 0 confs (this is common in other lightning wallets with LSP support)
• require 0 confs if the user confirms via a popup that they trust this channel provider (this could be particularly useful since electrum does not hard-code any particular LSP)
• require 6 confs (this used to be recommended in bitcoin and should be an option too, imo)
• require N confs (where N is set by the user or a dev implementing something on top of electrum)

Motivation

There are two motivations. First, some bitcoin devs have recently argued that 6 confirmations is no longer good enough due to mining centralization. It would be great if users and devs who agree could set their software to require more.

But another, also significant concern, for me, is the fantastic UX provided by other wallets which sometimes allow 0-conf channels. For example, one of the things I like best about Phoenix Wallet is their onboarding procedure, which is something like this:

1. Hit Receive
2. The wallet displays a bitcoin address and a lightning invoice
3. Send money to either one

That’s it. The wallet handles the rest. If you send on L1, the wallet asks an LSP to open a channel with it, then uses an atomic swap to give the money on L1 to the LSP in exchange for a slightly smaller payment on LN (the LSP keeps the rest as a fee). If you send on LN, the money goes into a hodl invoice held by the LSP but whose preimage is known only to the user. The wallet then asks the LSP to open a channel with it, and deposit an amount slightly smaller than the intended amount into a second hodl invoice held by the user. Then, in order to accept that payment, the wallet discloses the preimage to the LSP, thus settling the second hold invoice; and the LSP uses it to settle the "first" hodl invoice, thus completing the protocol. (Again, the LSP keeps the rest as a fee.)

I am thinking about making a wallet based on electrum -- or perhaps a plugin -- with a similar onboarding UX as Phoenix Wallet has, but there are a couple of issues in the way of doing so. One of them is: electrum requires 3 confirmations before a lightning channel is usable, whereas Phoenix requires 0 confirmations in certain circumstances, namely, if the utxo(s) that created the channel came from the LSP.

Due to that limitation, I think the closest I can currently get to Phoenix's onboarding UX -- using Electrum as currently coded -- is the following: start by having the user's device generate a preimage and give it to an LSP service to be written by me (as usual, I would only write a proof of concept, and then hope a better coder than me makes a real version). The LSP service then creates a hodl invoice with that preimage, which is the invoice displayed to the user in step 2. When someone pays it, the LSP now has a pending payment, and opens a channel to the user's device.

Here is where the issue comes in: currently, it seems my only option at this point is to inform the user that their new channel is not usable til it has 3 confirmations, so please wait and do not turn off their device. When those confirmations come in, the wallet can ask the LSP to pay a hodl invoice with the user's preimage, then disclose it to the LSP to settle the payment, just like Phoenix does, except Electrum required waiting for 3 confs.

If electrum supported 0-conf inbound channels, my code could, instead, ask the user if they are willing to trust this LSP for their initial payment, notifying them that if they say No, they'll have to await 3 confirmations. But if they say Yes, the LSP immediately pays the user's device via this new, unconfirmed channel, just like Phoenix does, and the user's device discloses the preimage to the LSP, thus completing the onboarding protocol.

Since the latter offers far superior UX, I would like to make it an option, and this seems to require the ability to configure electrum to allow 0-conf channels at least in some cases (e.g. with user approval).

[f321x]

Zeroconf/just-in-time channel opening is definitely on the roadmap and is already partially implemented in Electrum.

To test this you can set zeroconf_trusted_node to pubkey@host:port, accept_zeroconf_channel true and use_recoverable_channels False on the client, and spin up a forwarding Electrum node that acts as LSP with accept_zeroconf_channel true, lightning_listen to host:port, lightning_forward_payments and lightning_forward_trampoline_payments true.

If the client then tries to receive a lightning payment exceeding the available inbound liquidity the GUI should ask to request a channel just in time and release the preimage to the forwarding node before the channel is confirmed (client trusts the LSP).

See the regtest covering this flow for the exact procedure:

electrum/tests/regtest/regtest.sh

Lines 770 to 787 in 3695e00

	if [[ $1 == "just_in_time" ]]; then
	bob_node=$($bob nodeid)
	$alice setconfig zeroconf_trusted_node $bob_node
	$alice setconfig use_recoverable_channels false
	wait_for_balance carol 1
	echo "carol opens channel with bob"
	$carol open_channel $bob_node 0.15 --password=''
	new_blocks 3
	wait_until_channel_open carol
	echo "carol pays alice"
	# note: set amount to 0.001 to test failure: 'payment too low'
	invoice=$($alice add_request 0.01 --lightning --memo "invoice" | jq -r ".lightning_invoice")
	success=$($carol lnpay $invoice| jq '.success')
	if [[ $success != "true" ]]; then
	echo "JIT payment failed"
	exit 1
	fi
	fi

Please note this code is experimental (forwarding and zeroconf opening) and has known issues, using it on mainnet is reckless.
If you encounter issues while playing around with this please report them, there is already an open PR fixing some zeroconf issues: #10463.

require N confs (where N is set by the user or a dev implementing something on top of electrum)

this could be made a config variable.

[supertestnet]

you can set accept_zeroconf_channels to pubkey@host:port

Awesome, what a cool feature! Can you make it so it accepts a list? I might build a POC where you can select from multiple LSPs depending on their rates or other factors, and it would be easier if I didn't have to stop accepting them from LSP A just because I added LSP B

[requiring N confs] could be made a config variable

Awesome, that sounds very promising

[f321x]

Can you make it so it accepts a list?

I see the point of why it would be useful to have a list, but as we don't yet expose the functionality, and the way zeroconf node(s) get selected might change fundamentally before we release/expose this feature, I don't think it is worth the work refactoring the code to take a list at this moment as we might have to change it again later once the other parts are more clear (e.g. how the user will actually select an LSP in the GUI).
For now you could change the config variable on demand in your plugin, or if you require this you could also open a PR.

[ecdsa]

@supertestnet The fantastic UX provided by Phoenix works because they can steal your money!

Phoenix users cannot choose their LSP, they must connect to the ACINQ node, which is assumed to be honest. This creates centralization: their node is a huge single point of failure for the Lightning Network. It also creates insomnia for their sysadmins. We do not want to follow that model.

We have a plan to enable zeroconf channels in Electrum, but not in the current state. Here is the plan:

• In the short term, we will allow zeroconf channels, but only with our own Electrum trampoline.
• Later, we will implement fraud proofs: public proofs that the LSP cheated, combined with fidelity bonds. This will allow anyone to become a LSP for Electrum clients, but they will have to sacrifice bitcoins in order to be punishable if they cheat..

I am currently writing a proposal regarding fraud proofs for LSPs, it will be public soon.