From lf-lists at mattcorallo.com Mon Aug 24 19:22:33 2020 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Mon, 24 Aug 2020 15:22:33 -0400 Subject: [Lightning-dev] Proposal for skip channel confirmation. In-Reply-To: References: Message-ID: 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 >