rich1.0npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2https://nostr.ae/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2njumphttps://nostr.aeđź“… Original date posted:2021-08-15
đź“ť Original message:
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
irrationally to get a free deal.
As protocol designers, it would be remiss to ignore this (repeatedly
demonstrated) truth.
To avoid this, we’ve been suggesting setting a min_htlc_value requirement.
The problem with zbf + a min_htlc size requirement is that it makes tiny
payments impossible over lightning, which was one of the original design
goals of the system, and is an important feature to keep/support as
lightning grows into poorer economic bases and the bitcoin market price
continues to rise.
My suggestion would be that, as a compromise, we set a network wide minimum
fee at the protocol level of 1msat. Naively, this seems it should be easy
to add to calculations using single-dimension optimization (or trivial
enough to ignore entirely), it removes the “free lunch” irrationality
honeypot zbf opens, and it provides a way forward for the continued use of
micropayments.
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 micropayments is worth 10sats.
It’s also simple to implement and seems rather obvious in retrospect.
The only confounding future change that I can see us making would be the
introduction of negative fees, which are useful as a way to induce payments
to rebalance channels passively. This seems like something we can revisit
once a proposal for negative fees is being seriously considered, however.
On Sun, Aug 15, 2021 at 05:59 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 has a couple of benefits:
> >
> > - it means you only have one value to optimise when trying to collect
> > the most fees, and one-dimensional optimisation problems are
> > obviously easier to write code for than two-dimensional optimisation
> > problems
>
> Indeed, this is a good point regarding this.
>
>
> > - when finding a route, if all the fees on all the channels are
> > proportional only, you'll never have to worry about paying more fees
> > just as a result of splitting a payment; that makes routing easier
> > (see [1])
>
> If we neglect roundoff errors.
>
> On the other hand, roundoff errors involved are <1msat per split, so it
> probably will not matter to most people.
>
> > So what's the cost? The cost is that there's no longer a fixed
> minimum
> > fee -- so if you try sending a 1sat payment you'll pay 0.1% of the
> fee
> > to send a 1000sat payment, and there may be fixed costs that you have
> > in routing payments that you'd like to be compensated for (eg, the
> > computational work to update channel state, the bandwith to forward
> the
> > tx, or the opportunity cost for not being able to accept another
> htlc if
> > you've hit your max htlcs per channel limit).
> >
> > But there's no need to explicitly separate those costs the way we do
> > now; instead of charging 1sat base fee and 0.02% proportional fee,
> > you can instead just set the 0.02% proportional fee and have a
> minimum
> > payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%
> > of that is 1sat. Nobody will be asking you to route without offering
> a
> > fee of at least 1sat, but all the optimisation steps are easier.
>
> Should this minimum a node will be willing to forward be part of gossip,
> and how does this affect routing algorithms?
>
> > You could go a step further, and have the node side accept smaller
> > payments despite the htlc minimum setting: eg, accept a 3000 sat
> payment
> > provided it pays the same fee that a 5000 sat payment would have.
> That is,
> > treat the setting as minimum_fee=1sat, rather than
> minimum_amount=5000sat;
> > so the advertised value is just calculated from the real settings,
> > and that nodes that want to send very small values despite having to
> > pay high rates can just invert the calculation.
>
> I like this idea, as I think it matches more what the incentives are.
> But it requires a change in gossip and in routing algorithms, and more
> importantly it requires routing algorithms to support two different fee
> schemes (base + proportional vs min + proportional).
>
> On the other hand, this still is a two-dimensional optimization algorithm,
> with `minimum_fee` and `proportional_fee_millionths` as the two dimensions.
> So maybe just have a single proportional-fee mechanism...
>
> >
> > I think something like this approach also makes sense when your
> channel
> > becomes overloaded; eg if you have x HTLC slots available, and y
> channel
> > capacity available, setting a minimum payment size of something like
> > y/2/x**2 allows you to accept small payments (good for the network)
> > when you're channel is not busy, but reserves the last slots for
> larger
> > payments so that you don't end up missing out on profits because you
> > ran out of capacity due to low value spam.
> >
> > Two other aspects related to this:
> >
> > At present, I think all the fixed costs are also incurred even when
> > a htlc fails, so until we have some way of charging failing txs for
> > incurring those costs, it seems a bit backwards to penalise
> successful
> > txs who at least pay a proportional fee for the same thing. Until
> we've
> > got a way of handling that, having zero base fee seems at least fair.
>
> Yes, the dreaded mechanism against payment lockup, which as far as I
> understand has a lot of thought already sunk into it without any
> widely-accepted solution, sigh.
>
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210815/cb1c33c6/attachment.html>