đź“… Original date posted:2020-11-30
đź“ť Original message:
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/39249949/attachment.html>;
JoĂŁo Valente [ARCHIVE] /
npub10v…qqpas
2023-06-09 13:01:37
in reply to nevent1q…rk6f
Author Public Key
npub10vzdn42vctun4x4590wmusslsecz8ftgfe2mqw4ejdp6megd7vnqwqqpasPublished at
2023-06-09 13:01:37Event JSON
{
"id": "b44d7a71a52516954a03549e0a191a4a50848374d7c3e23784c143fe355d005e",
"pubkey": "7b04d9d54cc2f93a9ab42bddbe421f867023a5684e55b03ab99343ade50df326",
"created_at": 1686315697,
"kind": 1,
"tags": [
[
"e",
"91e288134c1500ef65dec4a77dc2d64f7c52480a51f1922327c154c8c83162c1",
"",
"root"
],
[
"e",
"65a3120f1eceabd846a72629f56ce0ec0a3ec803cbbb6a23321cd3c820e74f18",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-11-30\n📝 Original message:\nHello Bastien!\n\nFirstly I'd like to thank you for the time you took to read the paper, it's\nbeen hard to get some quality reviews.\nYour feedback made me think and reach the following conclusions:\nLet's assume node A is sending information to its peer, node B, with the\ngoal of attracting more business (increasing the number of payments that\nare routed through it). In LDR this would mean A would want to announce to\nB that it belongs to larger volume routes than the ones it actually does.\nLet's say A and B shared channel state is (A: 1, B: 4).\nA shares a channel with C, state (A: 2, C: 3).\nB also shares a channel with C, state (B: 3, C: 6).\nA could dishonestly share with B knowing a path to C with capacity 4 BTC\nalthough it only has 2 currently available. By doing this A would\neffectively change B's routing preferences for payments to C, making B's\nrouting table go from:\n\nDestination | Next Hop | Capacity\n C A 2\n C C 3\n\n...to:\n\nDestination | Next Hop | Capacity\n C A 4\n C C 3\n\nMeaning B now thinks payments to C with volume in the [3, 4] BTC range can\nonly be routed through A and payments to C in the [0, 3] BTC range can be\nrouted to A or directly to C. What does this information change and how\ndoes it affect honest nodes?\nLarger [3, 4] BTC payments are not within the capacity provided by the path\nthat goes directly to C and would immediately fail when the payment is made\nin the LN layer using the path that goes through A. This breaks the\nincentive to, at least for payments in this volume range, share the invalid\ninformation. The cheating nodes would not be putting honest nodes out of\nbusiness nor increasing the number of payments that go through them.\nThe problem starts when the cheating node fakes directly competing for\nroutes within the capacity range provided by honest nodes and not by them\n([2, 3] BTC range for the example). Although this could not be used to\ncollect more fees because payments would eventually fail in the LN layer\nand the fees wouldn't be able to be collected, it could certainly be used\nto \"put honest nodes out of work\", stealing routing paths that would\notherwise belong to them.\nI think the solution lies in the way in which a node chooses the next best\nhop for a certain destination. I started by proposing the following\n(section 3.1.2):\n\n\u003eThe ”best next hop” for a certain payment destination is defined as being\nthe hop with the lowest fee from the group of next hops for that\ndestination where the maximum volume allowed is bigger than the payment’s\nvolume.\n\nI propose changing it to:\n\n\u003eThe ”best next hop” for a certain payment destination is defined as being\na random hop taken from the group of next hops for that destination\nwhere the maximum volume allowed is higher than the payment’s volume.\n\nWhich would diminish the incentive attacking nodes have to share fake\ngossip by not allowing them to set themselves as first in line to be chosen\nas next hop. A maximum fee that a node is willing to pay would also need to\nbe set,\nAlso, keep in mind that the capacity the maximum path capacity can lie\nabout is limited by the capacity of his biggest channel, available in the\nblockchain.\n\nPS: I adapted Figure 5 from your trampoline routing presentation, hope\nthat's ok!\n\nKind regards,\nJoão Valente\n\nOn Mon, 30 Nov 2020 at 08:36, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\n\u003e Hi Joao,\n\u003e\n\u003e Thanks for the time you spent on this, the paper is clear on the\n\u003e trade-offs (sacrificing some privacy for\n\u003e efficiency).\n\u003e\n\u003e My main negative feedback here is that you seem to assume that nodes will\n\u003e honestly cooperate.\n\u003e It feels to me that nodes can cheat and gossip biased or invalid\n\u003e information to their peers in order to\n\u003e attract more payments through their nodes (and collect more fees or put\n\u003e honest routing nodes out of\n\u003e business).\n\u003e\n\u003e Is that something you've thought about?\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e Le dim. 29 nov. 2020 à 00:46, João Valente \u003cjvalente96 at gmail.com\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Hey!\n\u003e\u003e\n\u003e\u003e I've been working on this new concept for routing in the lightning\n\u003e\u003e network. It leverages the use of the information nodes have on the\n\u003e\u003e distribution of funds in their channels to try and maximize the probability\n\u003e\u003e of success for a payment.\n\u003e\u003e Each node shares with his neighbours the information it has about the\n\u003e\u003e distribution of funds in its own neighbourhood through the form of a\n\u003e\u003e routing table. As nodes receive new tables they'll be updating their own\n\u003e\u003e locally maintained tables with the new information, periodically sharing\n\u003e\u003e them with their neighbours.\n\u003e\u003e Routing tables associate destination addresses (representing nodes in the\n\u003e\u003e network) to the next hop in the maximum capacity path to these nodes.\n\u003e\u003e If a new payment is to be made a payment probe is forwarded by the payer\n\u003e\u003e and through every node in the path, collects the path information along the\n\u003e\u003e way, and reaches the payee who returns it to the payer. The payer can then\n\u003e\u003e use this knowledge and confidently use the discovered path to route LN\n\u003e\u003e payments through.\n\u003e\u003e\n\u003e\u003e I wrote a 10 page paper about the subject and would love to get some\n\u003e\u003e feedback:\n\u003e\u003e\n\u003e\u003e https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e João Valente\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/39249949/attachment.html\u003e",
"sig": "995cb1020bffef8ba2381a23d160f6902fa9e8bb322d79c22d9ed2f844810e37f0cbeb7d5ffdc7532ebe5697a494158d1126377c94d2368a3fc215b7cfa0fad6"
}