📅 Original date posted:2022-06-28
📝 Original message:
Hi Roasbeef,
This is over-design: if you fail to get reliable gossip, your routing
will suffer anyway. Nothing new here.
And if you *know* you're missing gossip, you can simply delay onchain
closures for longer: since nodes should respect the old channel ids for
a while anyway.
Matt's proposal to simply defer treating onchain closes is elegant and
minimal. We could go further and relax requirements to detect onchain
closes at all, and optionally add a perm close message.
Cheers,
Rusty.
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi y'all,
>
> This mail was inspired by this [1] spec PR from Lisa. At a high level, it
> proposes the nodes add a delay between the time they see a channel closed on
> chain, to when they remove it from their local channel graph. The motive
> here is to give the gossip message that indicates a splice is in process,
> "enough" time to propagate through the network. If a node can see this
> message before/during the splicing operation, then they'll be able relate
> the old and the new channels, meaning it's usable again by senders/receiver
> _before_ the entire chain of transactions confirms on chain.
>
> IMO, this sort of arbitrary delay (expressed in blocks) won't actually
> address the issue in practice. The proposal suffers from the following
> issues:
>
> 1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement
> takes longer than 2 hours to reach the "economic majority" of
> senders/receivers, then the channel won't be able to mask the splicing
> downtime.
>
> 2. Gossip propagation delay and offline peers. These days most nodes
> throttle gossip pretty aggressively. As a result, a pair of nodes doing
> several in-flight splices (inputs become double spent or something, so
> they need to try a bunch) might end up being rate limited within the
> network, causing the splice update msg to be lost or delayed significantly
> (IIRC CLN resets these values after 24 hours). On top of that, if a peer
> is offline for too long (think mobile senders), then they may miss the
> update all together as most nodes don't do a full historical
> _channel_update_ dump anymore.
>
> In order to resolve these issues, I think instead we need to rely on the
> primary splicing signal being sourced from the chain itself. In other words,
> if I see a channel close, and a closing transaction "looks" a certain way,
> then I know it's a splice. This would be used in concert w/ any new gossip
> messages, as the chain signal is a 100% foolproof way of letting an aware
> peer know that a splice is actually happening (not a normal close). A chain
> signal doesn't suffer from any of the gossip/time related issues above, as
> the signal is revealed at the same time a peer learns of a channel
> close/splice.
>
> Assuming, we agree that a chain signal has some sort of role in the ultimate
> plans for splicing, we'd need to decide on exactly _what_ such a signal
> looks like. Off the top, a few options are:
>
> 1. Stuff something in the annex. Works in theory, but not in practice, as
> bitcoind (being the dominant full node implementation on the p2p network,
> as well as what all the miners use) treats annexes as non-standard. Also
> the annex itself might have some fundamental issues that get in the way of
> its use all together [2].
>
> 2. Re-use the anchors for this purpose. Anchor are nice as they allow for
> 1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs,
> both sides will want to make sure it gets confirmed in a timely manner.
> Ofc, RBF can be used here, but that requires both sides to be online to
> make adjustments. Pre-signing can work too, but the effectiveness
> (minimizing chain cost while expediting confirmation) would be dependent
> on the fee step size.
>
> In this case, we'd use a different multi-sig output (both sides can rotate
> keys if they want to), and then roll the anchors into this splicing
> transaction. Given that all nodes on the network know what the anchor size
> is (assuming feature bit understanding), they're able to realize that it's
> actually a splice, and they don't need to remove it from the channel graph
> (yet).
>
> 3. Related to the above: just re-use the same multi-sig output. If nodes
> don't care all that much about rotating these keys, then they can just use
> the same output. This is trivially recognizable by nodes, as they already
> know the funding keys used, as they're in the channel_announcement.
>
> 4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in
> an OP_RETURN and use that as the marker.
>
> 5. Fiddle w/ the locktime+sequence somehow to make it identifiable to
> verifiers. This might run into some unintended interactions if the inputs
> provided have either relative or absolute lock times. There might also be
> some interaction w/ the main constructing for eltoo (uses the locktime).
>
> Of all the options, I think #2 makes the most sense: we already use anchors
> to be able to do fee bumping after-the-fact for closing transactions, so why
> not inherit them here. They make the splicing transaction slightly larger,
> so maybe #3 (or something else) is a better choice.
>
> The design space for spicing is preeetty large, so I figure the most
> productive route might be discussing isolated aspects of it at a time.
> Personally, I'm not suuuper caught up w/ what the latest design drafts are
> (aside from convos at the recent LN Dev Summit), but from my PoV, how to
> communicate the splice to other peers has been an outstanding design
> question.
>
> [1]: https://github.com/lightning/bolts/pull/1004
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html
>
> -- Laolu
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:06:20
in reply to nevent1q…sspd
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:06:20Event JSON
{
"id": "a7562e9d6baa6a554d5a12d3d3c672b29399648c8dc65d09342091c7e4f9c5b4",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315980,
"kind": 1,
"tags": [
[
"e",
"68aec1f99cd4e5b941681a4766e53315d87dc392151785eee1eb3e4b5e7f9a3f",
"",
"root"
],
[
"e",
"8f1d2fa2deda099816365e02b1051e5a15d773c80fef3bc7bd87f13032fd2151",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-06-28\n📝 Original message:\nHi Roasbeef,\n\nThis is over-design: if you fail to get reliable gossip, your routing\nwill suffer anyway. Nothing new here.\n\nAnd if you *know* you're missing gossip, you can simply delay onchain\nclosures for longer: since nodes should respect the old channel ids for\na while anyway.\n\nMatt's proposal to simply defer treating onchain closes is elegant and\nminimal. We could go further and relax requirements to detect onchain\ncloses at all, and optionally add a perm close message.\n\nCheers,\nRusty.\n\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e Hi y'all,\n\u003e\n\u003e This mail was inspired by this [1] spec PR from Lisa. At a high level, it\n\u003e proposes the nodes add a delay between the time they see a channel closed on\n\u003e chain, to when they remove it from their local channel graph. The motive\n\u003e here is to give the gossip message that indicates a splice is in process,\n\u003e \"enough\" time to propagate through the network. If a node can see this\n\u003e message before/during the splicing operation, then they'll be able relate\n\u003e the old and the new channels, meaning it's usable again by senders/receiver\n\u003e _before_ the entire chain of transactions confirms on chain.\n\u003e\n\u003e IMO, this sort of arbitrary delay (expressed in blocks) won't actually\n\u003e address the issue in practice. The proposal suffers from the following\n\u003e issues:\n\u003e\n\u003e 1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement\n\u003e takes longer than 2 hours to reach the \"economic majority\" of\n\u003e senders/receivers, then the channel won't be able to mask the splicing\n\u003e downtime.\n\u003e\n\u003e 2. Gossip propagation delay and offline peers. These days most nodes\n\u003e throttle gossip pretty aggressively. As a result, a pair of nodes doing\n\u003e several in-flight splices (inputs become double spent or something, so\n\u003e they need to try a bunch) might end up being rate limited within the\n\u003e network, causing the splice update msg to be lost or delayed significantly\n\u003e (IIRC CLN resets these values after 24 hours). On top of that, if a peer\n\u003e is offline for too long (think mobile senders), then they may miss the\n\u003e update all together as most nodes don't do a full historical\n\u003e _channel_update_ dump anymore.\n\u003e\n\u003e In order to resolve these issues, I think instead we need to rely on the\n\u003e primary splicing signal being sourced from the chain itself. In other words,\n\u003e if I see a channel close, and a closing transaction \"looks\" a certain way,\n\u003e then I know it's a splice. This would be used in concert w/ any new gossip\n\u003e messages, as the chain signal is a 100% foolproof way of letting an aware\n\u003e peer know that a splice is actually happening (not a normal close). A chain\n\u003e signal doesn't suffer from any of the gossip/time related issues above, as\n\u003e the signal is revealed at the same time a peer learns of a channel\n\u003e close/splice.\n\u003e\n\u003e Assuming, we agree that a chain signal has some sort of role in the ultimate\n\u003e plans for splicing, we'd need to decide on exactly _what_ such a signal\n\u003e looks like. Off the top, a few options are:\n\u003e\n\u003e 1. Stuff something in the annex. Works in theory, but not in practice, as\n\u003e bitcoind (being the dominant full node implementation on the p2p network,\n\u003e as well as what all the miners use) treats annexes as non-standard. Also\n\u003e the annex itself might have some fundamental issues that get in the way of\n\u003e its use all together [2].\n\u003e\n\u003e 2. Re-use the anchors for this purpose. Anchor are nice as they allow for\n\u003e 1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs,\n\u003e both sides will want to make sure it gets confirmed in a timely manner.\n\u003e Ofc, RBF can be used here, but that requires both sides to be online to\n\u003e make adjustments. Pre-signing can work too, but the effectiveness\n\u003e (minimizing chain cost while expediting confirmation) would be dependent\n\u003e on the fee step size.\n\u003e\n\u003e In this case, we'd use a different multi-sig output (both sides can rotate\n\u003e keys if they want to), and then roll the anchors into this splicing\n\u003e transaction. Given that all nodes on the network know what the anchor size\n\u003e is (assuming feature bit understanding), they're able to realize that it's\n\u003e actually a splice, and they don't need to remove it from the channel graph\n\u003e (yet).\n\u003e\n\u003e 3. Related to the above: just re-use the same multi-sig output. If nodes\n\u003e don't care all that much about rotating these keys, then they can just use\n\u003e the same output. This is trivially recognizable by nodes, as they already\n\u003e know the funding keys used, as they're in the channel_announcement.\n\u003e\n\u003e 4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in\n\u003e an OP_RETURN and use that as the marker.\n\u003e\n\u003e 5. Fiddle w/ the locktime+sequence somehow to make it identifiable to\n\u003e verifiers. This might run into some unintended interactions if the inputs\n\u003e provided have either relative or absolute lock times. There might also be\n\u003e some interaction w/ the main constructing for eltoo (uses the locktime).\n\u003e\n\u003e Of all the options, I think #2 makes the most sense: we already use anchors\n\u003e to be able to do fee bumping after-the-fact for closing transactions, so why\n\u003e not inherit them here. They make the splicing transaction slightly larger,\n\u003e so maybe #3 (or something else) is a better choice.\n\u003e\n\u003e The design space for spicing is preeetty large, so I figure the most\n\u003e productive route might be discussing isolated aspects of it at a time.\n\u003e Personally, I'm not suuuper caught up w/ what the latest design drafts are\n\u003e (aside from convos at the recent LN Dev Summit), but from my PoV, how to\n\u003e communicate the splice to other peers has been an outstanding design\n\u003e question.\n\u003e\n\u003e [1]: https://github.com/lightning/bolts/pull/1004\n\u003e [2]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html\n\u003e\n\u003e -- Laolu\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "f03f5207c2850af18423a4c453b769a3e37fd6fe0c586add9dfa594742608446e2af987307a69b68f2e34f1849627ee0f6b00235f9d0b8268d5a5502e902734a"
}