Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-24 📝 Original message: A few notes. Given gossip ...
📅 Original date posted:2020-08-24
📝 Original message:
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
>
📝 Original message:
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
>