Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Pierre writes: >> But there's no reason to believe that the invoicer has more knowledge about >> all but the last hop. > > I disagree: there is a good chance that the receiver is a 24/7 running > merchant/website, with a full up-to-date view of the network, whereas > the payer is most likely a mobile wallet with less > accurate/partial/out of date information. > > At least this is what we are seeing on the current mainnet. Routing > table sync is hard on mobile clients, and I think that it makes sense > that receivers "help" senders, after all incentives are aligned. Good qualification; I agree. Certainly if the payer knows its information is less reliable it should prefer the provided route. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
> But there's no reason to believe that the invoicer has more knowledge about > all but the last hop. I disagree: there is a good chance that the receiver is a 24/7 running merchant/website, with a full up-to-date view of the network, whereas the payer is most likely a mobile wallet with less accurate/partial/out of date information. At least this is what we are seeing on the current mainnet. Routing table sync is hard on mobile clients, and I think that it makes sense that receivers "help" senders, after all incentives are aligned. Cheers, Pierre ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Resending due to ML bugs On a related note, it would be nice to get some clarity on appropriate usage of the r= field here. The way I had implemented it initially was that if an invoice had an r= field any publicly-discovered last-hop routes would be ignored as the r= data is most likely more up-to-date than any public route rumor information. However, if it's only used as a hint and only one or two out of potentially many channels are included in it, that may make little sense. Not really sure what the appropriate guidance should be, probably something like SHOULD prefer to use invoice-r=-provided-hints over publicly-discovered routes however MAY use other last-hops in case a substantially better route is known? Matt On 09/19/18 22:10, Rusty Russell wrote: > Hi all, > > I'm considering a change to c-lightning, where `invoice` would > automatically append an 'r' field for a channel which has sufficient > *incoming* capacity for the amount (using a weighted probability across > our peers). > > This isn't quite what 'r' was for, but it would be a useful > hint for payment routing and also potentially for establishing an > initial channel. This is an issue for the Blockstream Store which > deliberately doesn't advertize an address any more to avoid > centralization. > > Thoughts welcome! > Rusty. > ___ > 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
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Ha! I actually came up with the idea two months ago (but you beat me to it on the implementation so we're even :-) https://github.com/ACINQ/eclair-wallet/issues/101#issuecomment-408619207 Le jeu. 20 sept. 2018 à 04:12, Rusty Russell a écrit : > > Hi all, > > I'm considering a change to c-lightning, where `invoice` would > automatically append an 'r' field for a channel which has sufficient > *incoming* capacity for the amount (using a weighted probability across > our peers). > > This isn't quite what 'r' was for, but it would be a useful > hint for payment routing and also potentially for establishing an > initial channel. This is an issue for the Blockstream Store which > deliberately doesn't advertize an address any more to avoid > centralization. > > Thoughts welcome! > Rusty. > ___ > 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
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Olaoluwa Osuntokun writes: >> This is orothogonal. There's no point probing your own channel, you're >> presumably probing someone else's. > > In my scenario, you're receiving a new HTLC, from some remote party > unbeknownst to you. You have incoming and outgoing channels, and no other information. So, every HTLC? > Without something like an "unadd" you > can't do anything against an individual attempting to prob you other than > drop packets (drop as in don't even add to your commit, resulting in an HTLC > timeout) , as if you cancel back, then they know that you had enough > bandwidth to _accept_ the HTLC in the first place. I don't see how "unadd" helps? And even if it did, if we lie about what channel actually failed, it degrades the entire network; might as well remove that information from the protocol entirely. While we can come up with mitigations, I think we are going to have to live with this information leakage to keep the network functioning. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
> This is orothogonal. There's no point probing your own channel, you're > presumably probing someone else's. In my scenario, you're receiving a new HTLC, from some remote party unbeknownst to you. I was replying to cdecker's reply to johan that one wouldn't always add this new type of routing hint for all channels since it leaks available bandwidth information. Without something like an "unadd" you can't do anything against an individual attempting to prob you other than drop packets (drop as in don't even add to your commit, resulting in an HTLC timeout), as if you cancel back, then they know that you had enough bandwidth to _accept_ the HTLC in the first place. -- Laolu On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > >> That might not be so desirable, since it leaks the current channel > >> capacity to the user > > > >>From my PoV, the only way a node can protect the _instantaneous_ > available > > bandwidth in their channel is to randomly reject packets, even if they > have > > the bandwidth to actually accept and forward them. > > > > Observe that if a "prober" learns that you've _accepted_ a packet, then > > they know you have at least that amount as available bandwidth. As a > result, > > I can simply send varying sat packet sizes over to you, either with the > > wrong timelock, or an unknown payment hash. > > Yes. You have to have a false capacity floor, which must vary > periodically, to protect against this kind of probing (randomly failing > attempts as you get close to zero capaicty is also subject to probing, > AFAICT). > > > Since we don't yet have the > > "unadd" feature in the protocol, you _must_ accept the HTLC before you > can > > cancel it. This is mitigated a bit by the max_htlc value in the channel > > update (basically our version of an MTU), but I can still just send > > _multiple_ HTLC's rather than one big one to attempt to ascertain your > > available bandwidth. > > This is orothogonal. There's no point probing your own channel, you're > presumably probing someone else's. > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
This is now implemented (server side) in c-lightning/master: https://github.com/ElementsProject/lightning/pull/1982 (Note that c-lightning doesn't yet *use* the r= information: implementations should start doing that now though!) You can test against both my mainnet and testnet nodes: mainnet: id: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605 alias: BLUEIRON-v0.6.1rc2-81-g3ce53ab addresses: 128.199.202.168, 2400:6180:0:d0::5cd2:a001, vww5i3z3fvfkxylz.onion testnet: id: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769 alias: SLICKERMASTER- addresses: 165.227.30.200, 2604:a880:2:d0::2065:5001 You can autogenerate an invoice for testnet with: http://165.227.30.200:8000/cgi-bin/payreq.sh If there's insufficient incoming capacity, this *won't* produce an 'r' hint, but will issue a warning. Cheers, Rusty. Rusty Russell writes: > Hi all, > > I'm considering a change to c-lightning, where `invoice` would > automatically append an 'r' field for a channel which has sufficient > *incoming* capacity for the amount (using a weighted probability across > our peers). > > This isn't quite what 'r' was for, but it would be a useful > hint for payment routing and also potentially for establishing an > initial channel. This is an issue for the Blockstream Store which > deliberately doesn't advertize an address any more to avoid > centralization. > > Thoughts welcome! > Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Olaoluwa Osuntokun writes: >> That might not be so desirable, since it leaks the current channel >> capacity to the user > >>From my PoV, the only way a node can protect the _instantaneous_ available > bandwidth in their channel is to randomly reject packets, even if they have > the bandwidth to actually accept and forward them. > > Observe that if a "prober" learns that you've _accepted_ a packet, then > they know you have at least that amount as available bandwidth. As a result, > I can simply send varying sat packet sizes over to you, either with the > wrong timelock, or an unknown payment hash. Yes. You have to have a false capacity floor, which must vary periodically, to protect against this kind of probing (randomly failing attempts as you get close to zero capaicty is also subject to probing, AFAICT). > Since we don't yet have the > "unadd" feature in the protocol, you _must_ accept the HTLC before you can > cancel it. This is mitigated a bit by the max_htlc value in the channel > update (basically our version of an MTU), but I can still just send > _multiple_ HTLC's rather than one big one to attempt to ascertain your > available bandwidth. This is orothogonal. There's no point probing your own channel, you're presumably probing someone else's. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Any reason not to include _all_ (up to a limit) incoming channels with sufficient capacity? Cheers, Johan On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell wrote: > Hi all, > > I'm considering a change to c-lightning, where `invoice` would > automatically append an 'r' field for a channel which has sufficient > *incoming* capacity for the amount (using a weighted probability across > our peers). > > This isn't quite what 'r' was for, but it would be a useful > hint for payment routing and also potentially for establishing an > initial channel. This is an issue for the Blockstream Store which > deliberately doesn't advertize an address any more to avoid > centralization. > > Thoughts welcome! > Rusty. > ___ > 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
[Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
Hi all, I'm considering a change to c-lightning, where `invoice` would automatically append an 'r' field for a channel which has sufficient *incoming* capacity for the amount (using a weighted probability across our peers). This isn't quite what 'r' was for, but it would be a useful hint for payment routing and also potentially for establishing an initial channel. This is an issue for the Blockstream Store which deliberately doesn't advertize an address any more to avoid centralization. Thoughts welcome! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
