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