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
