📅 Original date posted:2019-03-30
📝 Original message:
> I am forking this thread as my reply is not at all related to the JIT-Routing.
Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread
> Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).
I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.
The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guesses.
> A good pruning heuristic is "channel capacity", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.
> So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.
I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected.
> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.
> In effect, the high-capacity channel is very likely to successfully route in either direction.
> But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.
Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to be employed.
Cheers
Ariel Lorenzo-Luaces
On Mar 28, 2019, 9:51 PM, at 9:51 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>Good morning Ariel,
>
>I am forking this thread as my reply is not at all related to the
>JIT-Routing.
>
>
>Sent with ProtonMail Secure Email.
>
>> Public nodes could advertise channels which don't actually exist
>directly but are instead hidden paths that the source node doesn't need
>to know or care about. The fees advertised for these aggregate-channels
>would be the aggregate fees expected from the sub-route.
>
>Nonexistent channels (i.e. channels that do not have some backing UTXO
>in the Bitcoin blockchain) are not safe to propagate on the network
>since they are trivially spammable (i.e. can generate a large number of
>fake channels to waste network bandwidth).
>
>> I think the biggest gain from this system is that the network can be
>more abstract. This abstraction allows all possible subsets of public
>nodes to be a clique since all subsets of nodes can be maximally
>connected with aggregate-channels as long as the entire network is well
>connected.
>> This new property of the network could allow a source node to select
>a random privacy-clique and rely on payments to be routed along
>aggregate-channels without the source node needing to compute or even
>know the exact sub-routes. Futhermore, the source node could
>exclusively download and listen to the privacy-clique and ignore the
>rest of the network structure thus reducing the burden of keeping up to
>date network information.
>
>Let me suggest something else.
>
>As the LN grows, the public routemap becomes larger and larger, until
>keeping them in a fast in-memory data structure becomes infeasible on
>cheap hardware.
>In all likelihood, at some point in the future, users will want to be
>able to limit the memory consumed by implementations for routemaps.
>
>So, some pruning heuristic is needed, to reduce the resource usage of
>large routemaps.
>
>A good pruning heuristic is "channel capacity", which can be checked
>onchain (the value of the UTXO backing the channel is the channel
>capacity).
>It is good to keep channels with large capacity in the routemap,
>because such large channels are more likely to successfully route a
>payment than smaller channels.
>So it is reasonable to delete channels with low capacity when the
>routemap memory is becoming close to full.
>
>It seems to me that s/aggregate-channel/high-capacity-channel/g in your
>idea would still work.
>In effect, the high-capacity channel is very likely to successfully
>route in either direction.
>But if by chance it falls into a state where it is unable to route in
>one direction or other, the intermediate node has other, lower-capacity
>channels that it can use JIT-Routing with to improve the directionality
>of the high-capacity channel.
>Nothing in the JIT-Routing idea requires that the rebalancing loop is
>small, only that a loop exists.
>
>Nodes still need to track their direct channels (so they are implicitly
>always in the routemap).
>But payee nodes making BOLT1 invoices could also provide `r` routes in
>the invoice, with the given routes being from nodes with high-capacity
>channels, so that even if the intermediate channels are pruned due to
>low capacity, it is possible to get paid.
>
>Regards,
>ZmnSCPxj
Ariel Lorenzo-Luaces [ARCHIVE] /
npub1t5…vlpha
2023-06-09 12:54:40
in reply to nevent1q…fcsy
Author Public Key
npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlphaPublished at
2023-06-09 12:54:40Event JSON
{
"id": "dc398749ba0bd20b323a9c0350694e3375f85fc3087eabe8e78c3a369aef1570",
"pubkey": "5d373bc44b6cb694f096ec148573e6a122bc33455bc167ade3ae63d1189185d2",
"created_at": 1686315280,
"kind": 1,
"tags": [
[
"e",
"51aa2604767b047b656b0c7b3002b6e04df5103011e56634c097f530dbf94ff3",
"",
"root"
],
[
"e",
"2e342ce14260e6155e1bcffc6654e1f9e147bb428707e9e0e8c4395005289fc0",
"",
"reply"
],
[
"p",
"ebed449fcaac35befed3b0f55f70eef25ed95542b26fd12595522daa62016304"
]
],
"content": "📅 Original date posted:2019-03-30\n📝 Original message:\n\u003e I am forking this thread as my reply is not at all related to the JIT-Routing.\n\nSorry I think my last reply was also getting off subject as well.\nThank you for forking the thread\n\n\u003e Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).\n\nI hadn't considered the effect this gossip would have on the network.\nDefinitely nodes should not trust one another to tell the truth about\nnonexistent channels.\n\nThe source node could blindly allow intermediate nodes to create\nsub-routes to the next hop.\nBut I wouldn't favor this blind routing idea because fee calculations\nwould be a complete guesses.\n\n\u003e A good pruning heuristic is \"channel capacity\", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).\n\u003e It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.\n\u003e So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.\n\nI'm generally concerned about these heuristics because any time nodes\ncan game a heuristic they will be expected to do so.\nGaming a heuristic can be good or bad depending on the side-effects.\nOne side effect of the \"channel capacity\" heuristic is more reliable\npayments but another side effect is that low capacity (but possibly\nreliable) channels are neglected.\n\n\u003e It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.\n\u003e In effect, the high-capacity channel is very likely to successfully route in either direction.\n\u003e But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.\n\u003e Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.\n\u003e\n\u003e Nodes still need to track their direct channels (so they are implicitly always in the routemap).\n\u003e But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.\n\nWithout low capacity channels spontaneous payments would not work. Or\nthey would depend on asking for an invoice under the hood.\nIt feels to me that at some point, someone with complete knowledge of\nthe network needs to be employed.\n\nCheers\nAriel Lorenzo-Luaces\n\nOn Mar 28, 2019, 9:51 PM, at 9:51 PM, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003eGood morning Ariel,\n\u003e\n\u003eI am forking this thread as my reply is not at all related to the\n\u003eJIT-Routing.\n\u003e\n\u003e\n\u003eSent with ProtonMail Secure Email.\n\u003e\n\u003e\u003e Public nodes could advertise channels which don't actually exist\n\u003edirectly but are instead hidden paths that the source node doesn't need\n\u003eto know or care about. The fees advertised for these aggregate-channels\n\u003ewould be the aggregate fees expected from the sub-route.\n\u003e\n\u003eNonexistent channels (i.e. channels that do not have some backing UTXO\n\u003ein the Bitcoin blockchain) are not safe to propagate on the network\n\u003esince they are trivially spammable (i.e. can generate a large number of\n\u003efake channels to waste network bandwidth).\n\u003e\n\u003e\u003e I think the biggest gain from this system is that the network can be\n\u003emore abstract. This abstraction allows all possible subsets of public\n\u003enodes to be a clique since all subsets of nodes can be maximally\n\u003econnected with aggregate-channels as long as the entire network is well\n\u003econnected.\n\u003e\u003e This new property of the network could allow a source node to select\n\u003ea random privacy-clique and rely on payments to be routed along\n\u003eaggregate-channels without the source node needing to compute or even\n\u003eknow the exact sub-routes. Futhermore, the source node could\n\u003eexclusively download and listen to the privacy-clique and ignore the\n\u003erest of the network structure thus reducing the burden of keeping up to\n\u003edate network information.\n\u003e\n\u003eLet me suggest something else.\n\u003e\n\u003eAs the LN grows, the public routemap becomes larger and larger, until\n\u003ekeeping them in a fast in-memory data structure becomes infeasible on\n\u003echeap hardware.\n\u003eIn all likelihood, at some point in the future, users will want to be\n\u003eable to limit the memory consumed by implementations for routemaps.\n\u003e\n\u003eSo, some pruning heuristic is needed, to reduce the resource usage of\n\u003elarge routemaps.\n\u003e\n\u003eA good pruning heuristic is \"channel capacity\", which can be checked\n\u003eonchain (the value of the UTXO backing the channel is the channel\n\u003ecapacity).\n\u003eIt is good to keep channels with large capacity in the routemap,\n\u003ebecause such large channels are more likely to successfully route a\n\u003epayment than smaller channels.\n\u003eSo it is reasonable to delete channels with low capacity when the\n\u003eroutemap memory is becoming close to full.\n\u003e\n\u003eIt seems to me that s/aggregate-channel/high-capacity-channel/g in your\n\u003eidea would still work.\n\u003eIn effect, the high-capacity channel is very likely to successfully\n\u003eroute in either direction.\n\u003eBut if by chance it falls into a state where it is unable to route in\n\u003eone direction or other, the intermediate node has other, lower-capacity\n\u003echannels that it can use JIT-Routing with to improve the directionality\n\u003eof the high-capacity channel.\n\u003eNothing in the JIT-Routing idea requires that the rebalancing loop is\n\u003esmall, only that a loop exists.\n\u003e\n\u003eNodes still need to track their direct channels (so they are implicitly\n\u003ealways in the routemap).\n\u003eBut payee nodes making BOLT1 invoices could also provide `r` routes in\n\u003ethe invoice, with the given routes being from nodes with high-capacity\n\u003echannels, so that even if the intermediate channels are pruned due to\n\u003elow capacity, it is possible to get paid.\n\u003e\n\u003eRegards,\n\u003eZmnSCPxj",
"sig": "bdac2aa1ba04b976bc1f240f3e667785a84b95c5d5ea7928d5d96cdb59b0a1a772afc5d1a43b2ea3fe85325dfb7f67b4834ae2ea782d82c75375c1424e9e2d00"
}