📅 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.
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:03
in reply to nevent1q…9kg3
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:03Event JSON
{
"id": "530617235c96cd8892cd67df728b036271d6352ba587fba5edb5b2d0c0711242",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315063,
"kind": 1,
"tags": [
[
"e",
"8705da9b85f9ef58ca8afd03c294dca93ff511081b81057f36ea2baa8a76a7e6",
"",
"root"
],
[
"e",
"0ad07c0efd32aefe955b9f6c99011c0bd3188421249aed33e10c5b29e29a8bf4",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-07-03\n📝 Original message:\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\u003e For myself, I think, for old nodes, it should just appear as a\n\u003e \"normal\" close followed by a \"normal\" open.\n\nThat's exactly what they should look like, since the channel is being\nclosed with the existing protocol and opened (possibly with a slightly\ndifferent value).\n\n\u003e So, instead, maybe a new `channel_announce_reopen` which informs\n\u003e everyone that an old scid will eventually become a new scid, and that\n\u003e the nodes involved will still consider routes via the old scid to be\n\u003e valid regardless.\n\nI thought of it more as a new alias for the old channel, so that the\nupdate in the network view is just switching names after the announce\ndepth is reached.\n\n\u003e Then an ordinary `channel_announce` once the announce depth of the new\n\u003e scid is reached.\n\u003e\n\u003e From point of view of old nodes, the channel is closed for some\n\u003e blocks, but a new channel between the two nodes is then announced.\n\u003e\n\u003e From point of view of new nodes, the channel is referred to using the\n\u003e previous scid, until an ordinary `channel_announce` is received, and\n\u003e then the channel is referred to using the new scid.\n\nThe message announcing the reopen or the alias should probably preceed\nthe actual close, otherwise nodes may prune the channel from their view\nupon seeing the close. The message then simply has the effect of saying\n\"ignore the close, let it linger for 6 more blocks before really\nremoving from your network view\".\n\n\n\u003e For myself, I think splice is less priority than AMP. But I prefer an\n\u003e AMP which retains proper ZKCP (i.e. receipt of preimage at payer\n\u003e implies receipt of payment at payee, to facilitate trustless\n\u003e on-to-offchain and off-to-onchain bridges).\n\nAgreed, multipath routing is a priority, but I think splicing is just as\nmuch a key piece to a better UX, since it allows to ignore differences\nbetween on-chain and off-chain funds, showing just a single balance for\nall use-cases.\n\n\u003e With AMP, size of channels is less important, and many small channels\n\u003e will work almost as well as a few large channels.\n\nWell, capacities are still very much important, and if there is a\nsmaller min-cut separating source and destination than the total amount\nof the payment, then the payment will still fail. We now simply no\nlonger require a single channel with sufficient capacity to exist.",
"sig": "2b56797ac50ee796c979938a01e44e1aac9e562ab6fbc978c3325d6388bc1319af366a14c9257651d5496635e60411f2935400edfd5376e58373142095be7ea5"
}