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 <bast...@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 <jvalent...@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@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
