📅 Original date posted:2018-01-18
📝 Original message:
Mark Friedenbach <mark at friedenbach.org> writes:
> It is not the case that all instances where you might have negative
> fees would have loops.
If we don't have a cycle we can hardly talk about rebalancing
channels. At that point you're paying for someone else's payment to go
through your channel, and I'm unclear what the motivation for that might
be. Anyway, this is still possible by communicating this out of band
with the payment creator, and should not be baked into the gossip
protocol itself, in my opinion. It's obscure enough to not be worth the
extra effort.
> One instance where you want this feature is when the network becomes
> too weighted in one side of the graph.
There is little you can do to prevent this: if we have a network with a
small cut, with a source and sink on opposite sides of that cut, no
amount of voluntary sacrifice from the nodes along the cut will have a
lasting effect. The better solution would be to change the topology of
the network to remove the cut, or balance traffic over it, e.g., moving
a sink to the other side of the cut.
> Another is when the other side is a non-routable endpoint. In both
> cases would be useful to signal to others that you were willing to pay
> to rebalance, and this hand wavy argument about loops doesn’t seem to
> apply.
I'm not sure I understand what you mean with non-routable endpoint, so
correct me if I'm wrong. I'm assuming that non-routable endpoint is a
non-publicly announced node in the network? In that case no fee tricks
will ever get people to route over it, since they can't even construct
the onion to talk to it. Notice that the payment requests allow for
recipients of payments to get paid by explicitly including the necessary
information to construct the onion to talk to that node.
Not trying to be dismissive here, and I might be getting this wrong, so
let me know if I did and what use-cases you had in mind :-)
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:48:36
in reply to nevent1q…cc5g
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:48:36Event JSON
{
"id": "e66dda96f1b4572b609a24fa3fa6d7c2dfda7a5d3fcbe8f09a2ed5789de96473",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314916,
"kind": 1,
"tags": [
[
"e",
"4aac94e2520d5d85249e479c2e245742d89199e35c82a898ea938aaf0a3c0a1b",
"",
"root"
],
[
"e",
"c9251b437a47ab2671952a1e7b5403ff8c45b831ffed743decd34e39e2edc937",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2018-01-18\n📝 Original message:\nMark Friedenbach \u003cmark at friedenbach.org\u003e writes:\n\n\u003e It is not the case that all instances where you might have negative\n\u003e fees would have loops.\n\nIf we don't have a cycle we can hardly talk about rebalancing\nchannels. At that point you're paying for someone else's payment to go\nthrough your channel, and I'm unclear what the motivation for that might\nbe. Anyway, this is still possible by communicating this out of band\nwith the payment creator, and should not be baked into the gossip\nprotocol itself, in my opinion. It's obscure enough to not be worth the\nextra effort.\n\n\u003e One instance where you want this feature is when the network becomes\n\u003e too weighted in one side of the graph.\n\nThere is little you can do to prevent this: if we have a network with a\nsmall cut, with a source and sink on opposite sides of that cut, no\namount of voluntary sacrifice from the nodes along the cut will have a\nlasting effect. The better solution would be to change the topology of\nthe network to remove the cut, or balance traffic over it, e.g., moving\na sink to the other side of the cut.\n\n\u003e Another is when the other side is a non-routable endpoint. In both\n\u003e cases would be useful to signal to others that you were willing to pay\n\u003e to rebalance, and this hand wavy argument about loops doesn’t seem to\n\u003e apply.\n\nI'm not sure I understand what you mean with non-routable endpoint, so\ncorrect me if I'm wrong. I'm assuming that non-routable endpoint is a\nnon-publicly announced node in the network? In that case no fee tricks\nwill ever get people to route over it, since they can't even construct\nthe onion to talk to it. Notice that the payment requests allow for\nrecipients of payments to get paid by explicitly including the necessary\ninformation to construct the onion to talk to that node.\n\nNot trying to be dismissive here, and I might be getting this wrong, so\nlet me know if I did and what use-cases you had in mind :-)\n\nCheers,\nChristian",
"sig": "c977f3c0d9428c9dc37817afd032c9423a1a3c7860467101d028838156578e4967db2c0b66b342b9c75f1195d1083750973d16d9182de4593fb43a4da7baf4dd"
}