[Lightning-dev] Proposal for skip channel confirmation.

Matt Corallo lf-lists at mattcorallo.com
Mon Aug 24 19:22:33 UTC 2020


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.

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.

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
> 


More information about the Lightning-dev mailing list