I agree the r-fields are useful to populate for public channels in many
situations, but care must be taken to not _always_ try them first without
accounting for potentially high fees on those channels.
- Johan
On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell wrote:
> Pierre writes:
> >> But there'
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 mo
> 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
acc
Good morning Matt,
In my implementation that might get into c-lightning (i.e. my pull request,
which I should probably update some time before universe heat death) the r=
fields are preferred, but if unable to find routes to the nodes indicated in
the r= fields, we always fall back to our known
Matt Corallo writes:
> 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 mor
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
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
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 informati
> 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 hi
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:
m
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 a
> 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.
Ob
I was thinking you could just make many requests to get the same
information, but if you always choose the same channel as long as its
capacity meets the requirement, then not much is learnt :)
On Thu, Sep 20, 2018 at 9:26 AM Christian Decker
wrote:
> That might not be so desirable, since it l
That might not be so desirable, since it leaks the current channel
capacity to the user. Depending on how fine grained the amount in the
invoice is and how the user can control it, he could do a binary search
over capacities and very reliably tell how much capacity you have and
track it over time.
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 w
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 use
16 matches
Mail list logo
