Hi Roei, You might have a mechanism to lower trust in zero-conf channel opener. Actually the local party can be in charge of broadcasting the funding transaction, thus ensuring it's well-propagated across network mempools and then start to accept incoming payment on the zero-conf channel. Per BIP 125 rules, a malicious funder/opener would have to pay a higher fee to replace the channel funding tx and thus double-spend the HTLC. A local party may require a higher fee funding transaction than it is necessary wrt ongoing congestion to increase level of protection. And I think it's okay on the economic-side, you will amortize this fee premium on the channel lifecycle. Until the transaction gets confirmed you might only accept HTLC under this fee. So you have game-theory security for your zero-conf channels as it would cost more in fees than a HTLC double-spend win for the malicious opener, under the assumption of non-miner-collusion with the attacker.
Actually this higher fee could be attached by a zero-conf channel insurance service through a CPFP on a special output, and spread across a batch of funding transaction, thus replacement cost would be far higher for attacker but give the same value protection to any user involved in the batch. That said, it might be a bit slower and more expensive than a UX-fast zero-conf channel, as it's likely offered by wallet today, so maybe not a user demand for zero-conf channel improved safety. With regards to the current proposal in itself, skimming quickly on BOLT 2 we don't explicitly require minimum_depth > 0 ? So only the new requirement zero-conf chan is about the channel identifier in the lack of an anchoring block ? If the channel is private, it doesn't matter id to be random, that's just a convention between channel peers. A local alias short_channel_id can be sent to any potential payer. Overall, I lean to think this kind of proposal might belong to a higher layer spec, as it's more a matter of policy between nodes than a global network mechanism. Such higher spec could gather specifications on other point-to-point Lightning programmable interfaces, like onion content, assuming we keep track of collision types. It would fasten ecosystem features while letting BOLT specifications focus on the core layer requirements. Though it might be too early for such a thing. Cheers, Antoine Le lun. 24 août 2020 à 20:22, Matt Corallo <lf-li...@mattcorallo.com> a écrit : > 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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
