Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-03 📝 Original message: ZmnSCPxj via ...
📅 Original date posted:2018-07-03
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> For myself, I think, for old nodes, it should just appear as a
> "normal" close followed by a "normal" open.
That's exactly what they should look like, since the channel is being
closed with the existing protocol and opened (possibly with a slightly
different value).
> So, instead, maybe a new `channel_announce_reopen` which informs
> everyone that an old scid will eventually become a new scid, and that
> the nodes involved will still consider routes via the old scid to be
> valid regardless.
I thought of it more as a new alias for the old channel, so that the
update in the network view is just switching names after the announce
depth is reached.
> Then an ordinary `channel_announce` once the announce depth of the new
> scid is reached.
>
> From point of view of old nodes, the channel is closed for some
> blocks, but a new channel between the two nodes is then announced.
>
> From point of view of new nodes, the channel is referred to using the
> previous scid, until an ordinary `channel_announce` is received, and
> then the channel is referred to using the new scid.
The message announcing the reopen or the alias should probably preceed
the actual close, otherwise nodes may prune the channel from their view
upon seeing the close. The message then simply has the effect of saying
"ignore the close, let it linger for 6 more blocks before really
removing from your network view".
> For myself, I think splice is less priority than AMP. But I prefer an
> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
> implies receipt of payment at payee, to facilitate trustless
> on-to-offchain and off-to-onchain bridges).
Agreed, multipath routing is a priority, but I think splicing is just as
much a key piece to a better UX, since it allows to ignore differences
between on-chain and off-chain funds, showing just a single balance for
all use-cases.
> With AMP, size of channels is less important, and many small channels
> will work almost as well as a few large channels.
Well, capacities are still very much important, and if there is a
smaller min-cut separating source and destination than the total amount
of the payment, then the payment will still fail. We now simply no
longer require a single channel with sufficient capacity to exist.
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> For myself, I think, for old nodes, it should just appear as a
> "normal" close followed by a "normal" open.
That's exactly what they should look like, since the channel is being
closed with the existing protocol and opened (possibly with a slightly
different value).
> So, instead, maybe a new `channel_announce_reopen` which informs
> everyone that an old scid will eventually become a new scid, and that
> the nodes involved will still consider routes via the old scid to be
> valid regardless.
I thought of it more as a new alias for the old channel, so that the
update in the network view is just switching names after the announce
depth is reached.
> Then an ordinary `channel_announce` once the announce depth of the new
> scid is reached.
>
> From point of view of old nodes, the channel is closed for some
> blocks, but a new channel between the two nodes is then announced.
>
> From point of view of new nodes, the channel is referred to using the
> previous scid, until an ordinary `channel_announce` is received, and
> then the channel is referred to using the new scid.
The message announcing the reopen or the alias should probably preceed
the actual close, otherwise nodes may prune the channel from their view
upon seeing the close. The message then simply has the effect of saying
"ignore the close, let it linger for 6 more blocks before really
removing from your network view".
> For myself, I think splice is less priority than AMP. But I prefer an
> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
> implies receipt of payment at payee, to facilitate trustless
> on-to-offchain and off-to-onchain bridges).
Agreed, multipath routing is a priority, but I think splicing is just as
much a key piece to a better UX, since it allows to ignore differences
between on-chain and off-chain funds, showing just a single balance for
all use-cases.
> With AMP, size of channels is less important, and many small channels
> will work almost as well as a few large channels.
Well, capacities are still very much important, and if there is a
smaller min-cut separating source and destination than the total amount
of the payment, then the payment will still fail. We now simply no
longer require a single channel with sufficient capacity to exist.