[Lightning-dev] Proposal for skip channel confirmation.

[Roei Erez]

Hello everyone,

I would like to discuss the ability to skip a channel funding
transaction confirmation, making the channel fully operational before
its on-chain confirmation (aka a zero-conf channel).
Till confirmation, this channel requires trust between its two parties
and in the case of a remote initiator, it puts the received funds of
the local party at risk.
Nevertheless, there are cases where it makes sense to support this
behavior. For example, in cases both parties decide to trust each
other. Or, in cases where trust between the parties already exists
(buying a pre-loaded channel from a service like Bitrefill).

The motivation is gained from the "Immediate on-boarding" use case:
* Bob is connected to a routing node and issues an invoice with a
   routing hint that points to a fake channel between Bob and that node.
* When Alice pays Bob's invoice, the routing node intercepts the HTLC
   and holds it.
* Then, the routing node does the following:
  * Opens a channel to Bob where Bob has a choice of skipping funding
     confirmation (channel is open and active).
  * Pays Bob the original Alices' invoice (potentially, minus a service fee)

>From Bob perspective it is his choice on whether to agree for the
payment via this channel (and by that increase the trust) or disagree
and wait for confirmation.
Another practical way for Bob is to skip confirmation and "hold" the
payment by not providing the pre-image.

Right now different implementations support zero-conf channels in
different ways. These implementations have defined their own way on
how to agree on a short_channel_id (fake one) before the transaction
is confirmed.

The following suggests some changes to the funding flow to support that:
  1. accept_channel message - in case the fundee wants to skip
      confirmation he sends minimum_depth=0
  2. funding_signed message - no change.
  3. funding_locked message - if fundee has sent minimum_depth=0, then
      both parties send funding_locked while the channel_id is derived using a
      convention agreed on both. One proposal for such convention is to take it
      from the temporary_channel_id provided in previous open_channel
      message as follows:
        * Use the first 8 bytes to initialize an unsigned integer,
           call it shortID
        * Apply this transformation:  shortID / 2^6 + 100,000
        * The above transformation ensures the block height falls in the
           range of 100,000 - 2^18+100,000. The rationale is that the id will
           never point to a valid mined transaction and the first 100,000 blocks
           are left for testing in other chains.
        * Assuming the temporary_channel_id is some random number, it is
          not likely that the derived short_channel_id will conflict with other
          channels in both peers but both peers should validate that before
          sending funding_locked.
  4. When the channel is confirmed gossip messages such as
      channel_update are re-broadcasted and refers to the confirmed
      channel_id (such as the case with re-org).

I created a PR in LND that implements these changes
https://github.com/lightningnetwork/lnd/pull/4424

Cheers,
Roei