[Lightning-dev] Proposal for skip channel confirmation.

[Roei Erez]

Hi Matt and thanks for your notes.

On Mon, 24 Aug 2020 at 22:22, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> A few notes.
>
> Given gossip messages will be rejected by many nodes if no such on-chain transaction exists, I don't think you can
> "re-broadcast" gossip messages at that time, instead I believe you simply need to not gossip until the funding
> transaction has some confirmations. Still, this shouldn't prevent receiving payments, as invoices carrying a last-hop
> hint should be able to indicate any short_channel_id value and have it be accepted.

You are right.  They really should be broadcasted once after the
funding transaction is sufficiently deep. I confused
that with the exchange of channel_update privately between them before
the channel is confirmed so they both
will be able to relay payments using this channel.

>
> It may make sense to reuse some "private short channel ID negotiation" feature for the temporary 0-conf short channel id
> value.
>
> One thing this protocol doesn't capture is unidirectional 0-conf - maybe the channel initiator is happy to receive
> payments (since its their funds which opened the channel, this is reasonable), but the channel initie-ee (?) isn't
> (which, again, is reasonable). This leaves only the push_msat value pay-able, and only once, but is a perfectly
> reasonable trust model and I believe some wallets use this today.

Although this proposal addresses the bi-directional zero-conf channel
both parties are able to "hold" any payment.
When the payee decides not to release the preimage based on  some
policy (total funds at risk, wait for confirmation)
the channel becomes unidirectional.
Implementing a unidirectional channel this way also has some advantages such as:
1. It gives you the ability to increase trust on an existing zero-conf
channel. Sometimes this is preferable because
    it saves the need to open additional channels and it shortens the
trust period (waiting for confirmation for a
    previously opened channel).
2. The funds sent to the channel acceptor can be a result of a
lightning payment, including proof of payment for the
    payer.

Roei

>
> Matt
>
> On 8/24/20 4:16 AM, Roei Erez wrote:
> > 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
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >