📅 Original date posted:2020-12-01
📝 Original message:
Good morning Joao and Bastien,
I believe the `feeadjuster` plugin for C-Lightning, created by Darosior, already does what you want to do, without a specs change.
* We already know that nodes prefer low-fee routes over high-fee routes.
* `feeadjuster` adjusts our channel feerate according to balance:
* It makes fees low if we own most of the funds in the channel.
* It makes fees high if we own almost none of the funds in the channel.
* Thus, `feeadjuster` signals "use this channel!" if it has high capacity in that direction, and signals "do not use this channel!" if it has low capacity in that direction.
I believe this is sufficient to achieve your goal, without requiring substantial changes to existing algorithms and implementations.
(CLBOSS, also a C-Lightning plugin, implements similar logic as one of the many things it does, with some differing details but with substantially the same fee-adjustment curve)
I believe concerns on false signaling are unfounded, at least with the limited channel fee signalling that `feeadjuster`/CLBOSS use.
I can signal a low feerate, but if I do not have sufficient capacity anyway when the inevitable flood of payments wanting to take advantage of the lower fees arrives, then I gain no advantage anyway.
Rather, some amount of honesty would be better for me.
Regards,
ZmnSCPxj
> Hello Bastien!
>
> Firstly I'd like to thank you for the time you took to read the paper, it's been hard to get some quality reviews.
> Your feedback made me think and reach the following conclusions:
> Let's assume node A is sending information to its peer, node B, with the goal of attracting more business (increasing the number of payments that are routed through it). In LDR this would mean A would want to announce to B that it belongs to larger volume routes than the ones it actually does.
> Let's say A and B shared channel state is (A: 1, B: 4).
> A shares a channel with C, state (A: 2, C: 3).
> B also shares a channel with C, state (B: 3, C: 6).
> A could dishonestly share with B knowing a path to C with capacity 4 BTC although it only has 2 currently available. By doing this A would effectively change B's routing preferences for payments to C, making B's routing table go from:
>
> Destination | Next Hop | Capacity
> C A 2
> C C 3
>
> ...to:
>
> Destination | Next Hop | Capacity
> C A 4
> C C 3
>
> Meaning B now thinks payments to C with volume in the [3, 4] BTC range can only be routed through A and payments to C in the [0, 3] BTC range can be routed to A or directly to C. What does this information change and how does it affect honest nodes?
> Larger [3, 4] BTC payments are not within the capacity provided by the path that goes directly to C and would immediately fail when the payment is made in the LN layer using the path that goes through A. This breaks the incentive to, at least for payments in this volume range, share the invalid information. The cheating nodes would not be putting honest nodes out of business nor increasing the number of payments that go through them.
> The problem starts when the cheating node fakes directly competing for routes within the capacity range provided by honest nodes and not by them ([2, 3] BTC range for the example). Although this could not be used to collect more fees because payments would eventually fail in the LN layer and the fees wouldn't be able to be collected, it could certainly be used to "put honest nodes out of work", stealing routing paths that would otherwise belong to them.
> I think the solution lies in the way in which a node chooses the next best hop for a certain destination. I started by proposing the following (section 3.1.2):
>
> >The ”best next hop” for a certain payment destination is defined as being the hop with the lowest fee from the group of next hops for that destination where the maximum volume allowed is bigger than the payment’s volume.
>
> I propose changing it to:
>
> >The ”best next hop” for a certain payment destination is defined as being a random hop taken from the group of next hops for that destination where the maximum volume allowed is higher than the payment’s volume.
>
> Which would diminish the incentive attacking nodes have to share fake gossip by not allowing them to set themselves as first in line to be chosen as next hop. A maximum fee that a node is willing to pay would also need to be set,
> Also, keep in mind that the capacity the maximum path capacity can lie about is limited by the capacity of his biggest channel, available in the blockchain.
>
> PS: I adapted Figure 5 from your trampoline routing presentation, hope that's ok!
>
> Kind regards,
> João Valente
>
> On Mon, 30 Nov 2020 at 08:36, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
> > Hi Joao,
> >
> > Thanks for the time you spent on this, the paper is clear on the trade-offs (sacrificing some privacy for
> > efficiency).
> >
> > My main negative feedback here is that you seem to assume that nodes will honestly cooperate.
> > It feels to me that nodes can cheat and gossip biased or invalid information to their peers in order to
> > attract more payments through their nodes (and collect more fees or put honest routing nodes out of
> > business).
> >
> > Is that something you've thought about?
> >
> > Cheers,
> > Bastien
> >
> > Le dim. 29 nov. 2020 à 00:46, João Valente <jvalente96 at gmail.com> a écrit :
> >
> > > Hey!
> > >
> > > I've been working on this new concept for routing in the lightning network. It leverages the use of the information nodes have on the distribution of funds in their channels to try and maximize the probability of success for a payment.
> > > Each node shares with his neighbours the information it has about the distribution of funds in its own neighbourhood through the form of a routing table. As nodes receive new tables they'll be updating their own locally maintained tables with the new information, periodically sharing them with their neighbours.
> > > Routing tables associate destination addresses (representing nodes in the network) to the next hop in the maximum capacity path to these nodes.
> > > If a new payment is to be made a payment probe is forwarded by the payer and through every node in the path, collects the path information along the way, and reaches the payee who returns it to the payer. The payer can then use this knowledge and confidently use the discovered path to route LN payments through.
> > >
> > > I wrote a 10 page paper about the subject and would love to get some feedback:
> > > https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing
> > >
> > > Cheers,
> > > João Valente
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:01:40
in reply to nevent1q…k3mn
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:01:40Event JSON
{
"id": "2d87c6510dc0af0a1d7d082257720a200157e0ab7e8677935ec91f7b470a57ab",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315700,
"kind": 1,
"tags": [
[
"e",
"b0d4c247329b9bf1f51a8af12cb088f4cf9922c90eee1302c5c5f86cc5d5feae",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-12-01\n📝 Original message:\nGood morning Joao and Bastien,\n\nI believe the `feeadjuster` plugin for C-Lightning, created by Darosior, already does what you want to do, without a specs change.\n\n* We already know that nodes prefer low-fee routes over high-fee routes.\n* `feeadjuster` adjusts our channel feerate according to balance:\n * It makes fees low if we own most of the funds in the channel.\n * It makes fees high if we own almost none of the funds in the channel.\n* Thus, `feeadjuster` signals \"use this channel!\" if it has high capacity in that direction, and signals \"do not use this channel!\" if it has low capacity in that direction.\n\nI believe this is sufficient to achieve your goal, without requiring substantial changes to existing algorithms and implementations.\n\n(CLBOSS, also a C-Lightning plugin, implements similar logic as one of the many things it does, with some differing details but with substantially the same fee-adjustment curve)\n\nI believe concerns on false signaling are unfounded, at least with the limited channel fee signalling that `feeadjuster`/CLBOSS use.\nI can signal a low feerate, but if I do not have sufficient capacity anyway when the inevitable flood of payments wanting to take advantage of the lower fees arrives, then I gain no advantage anyway.\nRather, some amount of honesty would be better for me.\n\nRegards,\nZmnSCPxj\n\n\n\n\u003e Hello Bastien!\n\u003e\n\u003e Firstly I'd like to thank you for the time you took to read the paper, it's been hard to get some quality reviews.\n\u003e Your feedback made me think and reach the following conclusions:\n\u003e Let's assume node A is sending information to its peer, node B, with the goal of attracting more business (increasing the number of payments that are routed through it). In LDR this would mean A would want to announce to B that it belongs to larger volume routes than the ones it actually does.\n\u003e Let's say A and B shared channel state is (A: 1, B: 4).\n\u003e A shares a channel with C, state (A: 2, C: 3).\n\u003e B also shares a channel with C, state (B: 3, C: 6).\n\u003e A could dishonestly share with B knowing a path to C with capacity 4 BTC although it only has 2 currently available. By doing this A would effectively change B's routing preferences for payments to C, making B's routing table go from:\n\u003e\n\u003e Destination | Next Hop | Capacity\n\u003e C A 2\n\u003e C C 3\n\u003e\n\u003e ...to:\n\u003e\n\u003e Destination | Next Hop | Capacity\n\u003e C A 4\n\u003e C C 3\n\u003e\n\u003e Meaning B now thinks payments to C with volume in the [3, 4] BTC range can only be routed through A and payments to C in the [0, 3] BTC range can be routed to A or directly to C. What does this information change and how does it affect honest nodes?\n\u003e Larger [3, 4] BTC payments are not within the capacity provided by the path that goes directly to C and would immediately fail when the payment is made in the LN layer using the path that goes through A. This breaks the incentive to, at least for payments in this volume range, share the invalid information. The cheating nodes would not be putting honest nodes out of business nor increasing the number of payments that go through them.\n\u003e The problem starts when the cheating node fakes directly competing for routes within the capacity range provided by honest nodes and not by them ([2, 3] BTC range for the example). Although this could not be used to collect more fees because payments would eventually fail in the LN layer and the fees wouldn't be able to be collected, it could certainly be used to \"put honest nodes out of work\", stealing routing paths that would otherwise belong to them.\n\u003e I think the solution lies in the way in which a node chooses the next best hop for a certain destination. I started by proposing the following (section 3.1.2):\n\u003e\n\u003e \u003eThe ”best next hop” for a certain payment destination is defined as being the hop with the lowest fee from the group of next hops for that destination where the maximum volume allowed is bigger than the payment’s volume.\n\u003e\n\u003e I propose changing it to:\n\u003e\n\u003e \u003eThe ”best next hop” for a certain payment destination is defined as being a random hop taken from the group of next hops for that destination where the maximum volume allowed is higher than the payment’s volume.\n\u003e\n\u003e Which would diminish the incentive attacking nodes have to share fake gossip by not allowing them to set themselves as first in line to be chosen as next hop. A maximum fee that a node is willing to pay would also need to be set,\n\u003e Also, keep in mind that the capacity the maximum path capacity can lie about is limited by the capacity of his biggest channel, available in the blockchain. \n\u003e\n\u003e PS: I adapted Figure 5 from your trampoline routing presentation, hope that's ok!\n\u003e\n\u003e Kind regards,\n\u003e João Valente\n\u003e\n\u003e On Mon, 30 Nov 2020 at 08:36, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\n\u003e \u003e Hi Joao,\n\u003e \u003e\n\u003e \u003e Thanks for the time you spent on this, the paper is clear on the trade-offs (sacrificing some privacy for\n\u003e \u003e efficiency).\n\u003e \u003e\n\u003e \u003e My main negative feedback here is that you seem to assume that nodes will honestly cooperate.\n\u003e \u003e It feels to me that nodes can cheat and gossip biased or invalid information to their peers in order to\n\u003e \u003e attract more payments through their nodes (and collect more fees or put honest routing nodes out of\n\u003e \u003e business).\n\u003e \u003e\n\u003e \u003e Is that something you've thought about?\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e Bastien\n\u003e \u003e\n\u003e \u003e Le dim. 29 nov. 2020 à 00:46, João Valente \u003cjvalente96 at gmail.com\u003e a écrit :\n\u003e \u003e\n\u003e \u003e \u003e Hey!\n\u003e \u003e \u003e\n\u003e \u003e \u003e I've been working on this new concept for routing in the lightning network. It leverages the use of the information nodes have on the distribution of funds in their channels to try and maximize the probability of success for a payment.\n\u003e \u003e \u003e Each node shares with his neighbours the information it has about the distribution of funds in its own neighbourhood through the form of a routing table. As nodes receive new tables they'll be updating their own locally maintained tables with the new information, periodically sharing them with their neighbours.\n\u003e \u003e \u003e Routing tables associate destination addresses (representing nodes in the network) to the next hop in the maximum capacity path to these nodes.\n\u003e \u003e \u003e If a new payment is to be made a payment probe is forwarded by the payer and through every node in the path, collects the path information along the way, and reaches the payee who returns it to the payer. The payer can then use this knowledge and confidently use the discovered path to route LN payments through.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I wrote a 10 page paper about the subject and would love to get some feedback:\n\u003e \u003e \u003e https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing\n\u003e \u003e \u003e\n\u003e \u003e \u003e Cheers,\n\u003e \u003e \u003e João Valente\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "f635e9cb31d14a18603a9f4e25b2857de98e539e280d8663bb8558630a88369623fefedf63dee289a796542f2e076169f3575b9e82d3a1f3a4a957199706c8ea"
}