📅 Original date posted:2018-01-17
📝 Original message:
It is not the case that all instances where you might have negative fees would have loops. One instance where you want this feature is when the network becomes too weighted in one side of the graph. 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.
> On Jan 17, 2018, at 12:40 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Benjamin Mord <ben at mord.io> writes:
>> It isn't obvious to me from the BOLTs if fees can be negative, and I'm
>> finding uint in the go source code - which suggests not. In scenarios where
>> the funding of a payment channel has been fully committed in one direction,
>> why not allow negative fees to incent unwinding, in scenarios where nodes
>> consider that cheaper than on-chain rebalancing?
>
> After discussing this for a while we decided not to allow negative fees
> in channel announcements (for now), because they actually do not add to
> the flexibility and require special handling for route finding.
>
> The main argument for negative fees has always been that they allow a
> channel operator to rebalance its channels. However it is neither
> required, nor is it really all that helpful. If a node wants to
> rebalance he needs to find a cycle, that it can use to rebalance. The
> simplest rebalancing is that the node itself sends a payment along that
> cycle back to itself, giving the rebalancing node full control over the
> amount to rebalance, timing and costs.
>
> The negative fees were intended to encourage other participants to use
> any cycle and rebalance for the node offering the negative fees. However
> that results in less control over the rebalancing for the node, e.g.,
> how many payments to incentivize, amounts, etc. This is compounded by
> the inherent delay of channel updates being disseminated in the
> network. So if a rebalancing node gets too many payments that try to
> take advantage of the negative fees, what should it do? It'd result in
> either losses for the node, or many forward rejections. So why not use
> the funds one would have used towards negative fees for the active way
> of rebalancing.
>
> It is preferable to have payments be routed around an exhausted channel,
> after all if there is a cycle there must be an alternative route, rather
> than trying to artificially rebalance.
>
> So overall, allowing only positive fees makes routing simpler, and still
> allows for active rebalancing. As for other applications some have
> alluded to, this constraint is only for the routing gossip. Should there
> be a good reason to allow increasing the amount forwarded by a peer,
> e.g., node n receives x from the previous hop and forwards x+e to the
> next hop, that can still be negotiated out of band or even in the onion
> payload for that node.
>
> Cheers,
> Christian
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-09 12:48:36
in reply to nevent1q…7rpc
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-09 12:48:36Event JSON
{
"id": "c9251b437a47ab2671952a1e7b5403ff8c45b831ffed743decd34e39e2edc937",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686314916,
"kind": 1,
"tags": [
[
"e",
"4aac94e2520d5d85249e479c2e245742d89199e35c82a898ea938aaf0a3c0a1b",
"",
"root"
],
[
"e",
"178c39419ee401373fcc04ac171676ebbf0638caa44f7714c001f747b579751c",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-01-17\n📝 Original message:\nIt is not the case that all instances where you might have negative fees would have loops. One instance where you want this feature is when the network becomes too weighted in one side of the graph. 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.\n\n\u003e On Jan 17, 2018, at 12:40 PM, Christian Decker \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e \n\u003e Benjamin Mord \u003cben at mord.io\u003e writes:\n\u003e\u003e It isn't obvious to me from the BOLTs if fees can be negative, and I'm\n\u003e\u003e finding uint in the go source code - which suggests not. In scenarios where\n\u003e\u003e the funding of a payment channel has been fully committed in one direction,\n\u003e\u003e why not allow negative fees to incent unwinding, in scenarios where nodes\n\u003e\u003e consider that cheaper than on-chain rebalancing?\n\u003e \n\u003e After discussing this for a while we decided not to allow negative fees\n\u003e in channel announcements (for now), because they actually do not add to\n\u003e the flexibility and require special handling for route finding.\n\u003e \n\u003e The main argument for negative fees has always been that they allow a\n\u003e channel operator to rebalance its channels. However it is neither\n\u003e required, nor is it really all that helpful. If a node wants to\n\u003e rebalance he needs to find a cycle, that it can use to rebalance. The\n\u003e simplest rebalancing is that the node itself sends a payment along that\n\u003e cycle back to itself, giving the rebalancing node full control over the\n\u003e amount to rebalance, timing and costs.\n\u003e \n\u003e The negative fees were intended to encourage other participants to use\n\u003e any cycle and rebalance for the node offering the negative fees. However\n\u003e that results in less control over the rebalancing for the node, e.g.,\n\u003e how many payments to incentivize, amounts, etc. This is compounded by\n\u003e the inherent delay of channel updates being disseminated in the\n\u003e network. So if a rebalancing node gets too many payments that try to\n\u003e take advantage of the negative fees, what should it do? It'd result in\n\u003e either losses for the node, or many forward rejections. So why not use\n\u003e the funds one would have used towards negative fees for the active way\n\u003e of rebalancing.\n\u003e \n\u003e It is preferable to have payments be routed around an exhausted channel,\n\u003e after all if there is a cycle there must be an alternative route, rather\n\u003e than trying to artificially rebalance.\n\u003e \n\u003e So overall, allowing only positive fees makes routing simpler, and still\n\u003e allows for active rebalancing. As for other applications some have\n\u003e alluded to, this constraint is only for the routing gossip. Should there\n\u003e be a good reason to allow increasing the amount forwarded by a peer,\n\u003e e.g., node n receives x from the previous hop and forwards x+e to the\n\u003e next hop, that can still be negotiated out of band or even in the onion\n\u003e payload for that node.\n\u003e \n\u003e Cheers,\n\u003e Christian\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": "14687032e7f4f7c4d36cfb5e28be78903c8dc207b70ba4b40b020ebf3e28429a241d0506eb2a10f60f52c3096876cf2609e70c34082920a701b863eab2a5443d"
}