On Mon, Nov 22, 2021 at 5:11 PM Stefan Richter
wrote:
> I also don't believe putting a choice of more or less seconds expectation
> in the UI makes for a great user experience. IMHO the goal should just be:
> give the user an estimate of fees necessary to succeed within a reasonable
> time.
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj wrote:
> Good morning Dave,
>
> > If LN software speculatively chooses a series of attempts with a similar
> > 95%, accounting for things like the probability of a stuck payment (made
> > worse by longer CLTV timeouts on some paths), it could present
I also don't believe putting a choice of more or less seconds expectation
in the UI makes for a great user experience. IMHO the goal should just be:
give the user an estimate of fees necessary to succeed within a reasonable
time. Maybe give them an option to optimize for fees only if they are
Good morning Dave,
> If LN software speculatively chooses a series of attempts with a similar
> 95%, accounting for things like the probability of a stuck payment (made
> worse by longer CLTV timeouts on some paths), it could present users
> with the same sort of options:
>
> ~1 second, x fee
>
On Mon, Nov 15, 2021 at 04:25:26PM +0100, Joost Jager wrote:
> Reliability is a property of a route that can
> be expressed as a probability. The probability that a route will be
> successful.
I don't think users care about the abstract concept of reliability
that's being returned by the
Yep, this is roughly the direction we've gone in LDK - an abstract interface that gives you some
information about a channel and you return "I'm willing to pay up to X msats to avoid routing over
that channel as specified".
It's obviously not perfect in the sense that it won't generate the
Good morning Joost,
> What I did in lnd is to work with so called 'payment attempt cost'. A virtual
> satoshi amount that represents the cost of a failed attempt.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003191.html
And I quote:
> Introduction
>
>
>
It seems to me there can be no such law unless P=NP. Which would also imply
Bitcoin is worthless.
Joost Jager schrieb am Mo., 15. Nov. 2021, 13:44:
> One direction that I explored is to start with a statement by the user in
> this form:
>
> "If there is a route with a success probability of
One direction that I explored is to start with a statement by the user in
this form:
"If there is a route with a success probability of 50%, then I am willing
to pay up to 1.8x the routing fee for an alternative route that has a 80%
success probability"
I like this because it isn't an abstract
Actually, if you look into our paper, the theory tells us the following:
1) A weighted sum of different cost aspects is attractive because it
remains convex if all the aspects are convex themselves. This cannot be
said of other methods like the harmonic mean, which kind of forces our hand
if we
Hi Rene,
> First I am happy that you also agree that reliability can and should be
> expressed as a probability as discussed in [0].
>
Probability based routing is not new to me. I've implemented a form of that
in lnd in march 2019: https://github.com/lightningnetwork/lnd/pull/2802,
followed by
Dear Joost,
First I am happy that you also agree that reliability can and should be
expressed as a probability as discussed in [0].
The problem that you address is that of feature engineering[1]. Which
consists of two (or even more) steps:
1.) Feature selection: That means in payment delivery
Hi Joost,
A quick way to resolve this is to normalize the payment fees to a [0,1]
scale. Two natural ways to do this are the following.
0 in both of them is some maximum set by the user (maybe with some
reasonable default), 1 could be either the cheapest path or simply 0 sat.
Once we have
13 matches
Mail list logo
