On 8/25/21 05:50, Anthony Towns wrote:
On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote:
I feel like we're having two very, very different conversations here. On one
hand, you're arguing that the base fee is of marginal use, and that maybe we
can figure out how to average it out s
On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote:
> I feel like we're having two very, very different conversations here. On one
> hand, you're arguing that the base fee is of marginal use, and that maybe we
> can figure out how to average it out such that we can avoid needing it.
I'm
I feel like we're having two very, very different conversations here. On one hand, you're arguing that the base fee is
of marginal use, and that maybe we can figure out how to average it out such that we can avoid needing it. On the other
hand, I'm arguing that, yes, maybe you can, but ideally yo
On Mon, Aug 16, 2021 at 12:48:36AM -0400, Matt Corallo wrote:
> > The base+proportional fees paid only on success roughly match the *value*
> > of forwarding an HTLC, they don't match the costs particularly well
> > at all.
> Sure, indeed, there's some additional costs which are not covered by fail
Good morning Stefan,
> > A reason why I suggest this is that the cost function in actual
> > implementation is *already* IMO overloaded.
> >
> > In particular, actual implementations will have some kind of conversion
> > between cltv-delta and fees-at-node.
>
> That's an interesting aspect. Wou
Good morning Zmn!
ZmnSCPxj schrieb am Mo., 16. Aug. 2021, 10:27:
>
> A reason why I suggest this is that the cost function in actual
> implementation is *already* IMO overloaded.
>
> In particular, actual implementations will have some kind of conversion
> between cltv-delta and fees-at-node.
>
Matt wrote:
> I'm frankly still very confused why we're having these conversations now
1000% this!!
This entire conversation strikes me as extremely premature and backwards
tbh. Someone experimenting with a new approach shouldn't prompt us to
immediately modify the protocol to better "fit" the a
Good morning Stefan,
> >I propose that the algorithm be modified >as such, that is, it *ignore* the
> >fee scheme.
>
> We actually started out thinking like this in the event we couldn't find a
> proper way to handle fees, and the real world experiments we've done so far
> have only involved p
Hi Zmn et al.,
>I propose that the algorithm be modified >as such, that is, it *ignore*
the fee scheme.
We actually started out thinking like this in the event we couldn't find a
proper way to handle fees, and the real world experiments we've done so far
have only involved probability costs, no
Good morning matt and aj,
Let me cut in here.
>From my reading of the actual paper --- which could be a massive
>misunderstanding, as I can barely understand half the notation, I am more a
>dabbler in software engineering than a mathist --- it seems to me that it
>would be possible to replace
Dropped a number of replies to which the reply would otherwise be "see above".
On 8/16/21 00:00, Anthony Towns wrote:
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
On 8/15/21 22:02, Anthony Towns wrote:
In
one particular class of applicable routing algorithms you could use for
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
> On 8/15/21 22:02, Anthony Towns wrote:
> > > In
> > > one particular class of applicable routing algorithms you could use for
> > > lightning routing having a base fee makes the algorithm intractably slow,
> > I don't think of that as
On 8/15/21 22:02, Anthony Towns wrote:
In
one particular class of applicable routing algorithms you could use for
lightning routing having a base fee makes the algorithm intractably slow,
I don't think of that as the problem, but rather as the base fee having
a multiplicative effect as you s
On Sun, Aug 15, 2021 at 07:19:01AM -0500, lisa neigut wrote:
> My suggestion would be that, as a compromise, we set a network wide minimum
> fee
> at the protocol level of 1msat.
Is that different in any meaningful way to just saying "fees get rounded
up to the nearest msat" ? If the fee is 999.9
Thanks, AJ, for kicking off the thread.
I'm frankly still very confused why we're having these conversations now. In one particular class of applicable routing
algorithms you could use for lightning routing having a base fee makes the algorithm intractably slow, but:
a) to my knowledge, no one
Good morning Zmn!
That is indeed precisely what we do. We usually quantize the min-cost flow
into minimum shares of, say, 10kSat to 100kSat. This makes the algorithm
run faster and loses very little precision. It also gives a simple way of
dealing with (reasonable) min-htlc-size values.
Cheers,
Good morning lisa, aj, et al.,
> The result is that micropayments have a different payment regime than
> “non-micropayments”, (which may still incentive almost irrational behavior)
> but at least there’s no *loss* felt by node operators for handling/supporting
> low value payments. 10k micropa
The field of economics has done much work over the past few decades
demonstrating that “Free” is problematic in practice because humans will go
out of their way to externalize costs elsewhere (e.g. time, in the case of
lightning), given the promise of freedom. In other words, actors often act
irrat
Good morning aj, et al.
> Hey *,
>
> There's been discussions on twitter and elsewhere advocating for
> setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
> this to summarise my understanding in a place that's able to easily be
> referenced later.
>
> Setting the base fee to zero
Hey *,
There's been discussions on twitter and elsewhere advocating for
setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
this to summarise my understanding in a place that's able to easily be
referenced later.
Setting the base fee to zero has a couple of benefits:
- it means
20 matches
Mail list logo
