From roeierez at gmail.com Mon Aug 24 08:16:44 2020 From: roeierez at gmail.com (Roei Erez) Date: Mon, 24 Aug 2020 11:16:44 +0300 Subject: [Lightning-dev] Proposal for skip channel confirmation. Message-ID: 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