João Valente [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-11-28 to 2020-12-01
💬 Posted a total of 4 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:01:41

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Hello ZmnSCPxj!
You are completely right in saying that LDR presents a bigger barrier in
the sense that It needs to be running on literally every node in a payment
path for it to work whereas 'feeadjuster' can help the sender even if only
one node in the payment path is running it. That is definitely a big LDR
disadvantage.
About the specs... My approach was thinking about LDR as an independent
protocol with an independent protocol specification which would be
implemented by software that run alongside a spec-compliant lightning node,
which is why I was saying that there is no need for a lightning-spec change.
I started trying to define this new specification it on an extended version
of the paper, it's available here:
https://drive.google.com/file/d/1tSd5jKny_jLL6M1OuRkIc3NLaNFMBdJ_/view?usp=sharing
Also started (early beginnings!) to write the LDR-spec compliant software,
targeting lnd and bitcoind: https://github.com/jsmvalente/ldRouting
Kind regards,
João Valente
On Tue, 1 Dec 2020 at 16:34, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Joao,
>
> > Hello ZmnSCPxj,
> >
> > Thank you for taking the time to read the paper and sending over some
> feedback, can't stress enough how important that is.
> > I took a look at the `feeadjuster` plugin for C-Lightning and although
> it goes in the same direction as LDR in the sense that it allows for better
> routes by signalling channel balance availability. It does it through a
> dynamic fee adjustment though, where LDR is more explicit and goes one step
> further, directly sharing channel balance information. I'm not sure how
> these two solutions would compare in practice though but I imagine that
> sharing more information would give LDR a performance edge.
> > Oh, and there's no need for a spec change. It could work as a separated
> LN overlay network.
>
> I believe it would --- either you write the code for this overlay network
> for all extant node software (though I suppose targeting lnd will get you
> 90% of the network anyway...), or you standardize so all implementations
> are going to target implementing the overlay network.
>
> On the other hand, using fees as the signaling just reuses an existing
> signaling layer, and affects payers in the expected ways --- all existing
> implementations already try to minimize fees, so signaling a low fee when
> you have high capacity on a channel already does the "right thing" on the
> network today.
>
> In short, by using fees as a signaling layer you can get something like
> this partly working for most payers today even if only a small number of
> nodes run `feeadjuster` or CLBOSS, whereas with LDR you need most payers to
> upgrade to using the new overlay network in order to get similar benefit, I
> think, in which case you should really push to standardize it in the specs.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/9806b83b/attachment.html>

2023-06-09 13:01:40

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Hello ZmnSCPxj,
Thank you for taking the time to read the paper and sending over some
feedback, can't stress enough how important that is.
I took a look at the `feeadjuster` plugin for C-Lightning and although it
goes in the same direction as LDR in the sense that it allows for better
routes by signalling channel balance availability. It does it through a
dynamic fee adjustment though, where LDR is more explicit and goes one step
further, directly sharing channel balance information. I'm not sure how
these two solutions would compare in practice though but I imagine that
sharing more information would give LDR a performance edge.
Oh, and there's no need for a spec change. It could work as a separated LN
overlay network.
Completely agree on the false signalling idea, a node would not gain any
more routing traffic by signalling a better fee or, in LDR's case, bigger
capacity routes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/ca816693/attachment.html>

2023-06-09 13:01:37

- reply

📅 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>

2023-06-09 13:01:37

- reply

📅 Original date posted:2020-11-28
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201128/bb51a60f/attachment.html>