Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-26 📝 Original message: On Mon, Sep 26, 2022 at ...
📅 Original date posted:2022-09-26
📝 Original message:
On Mon, Sep 26, 2022 at 01:26:57AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to traffic volume;
> > > but this seems like it should mostly have a proportional response,
> > > with a small decrease in htlc_max_msat resulting in a small decrease in
> > > payment volume, and conversely. Much better for stability/optimisation!
> > This may depend on what gets popular for sender algorithms.
> > Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.
I don't think that's really the case.
One option is that you quantize based on the individual payment -- you
want to send $100, great, your software splits it into 50x $2 payments,
and routes them. But that doesn't have an all or nothing effect: if you
reject anything over $1.99, then instead of routing 1/50th of payments
up to $100, you're routing 1/50th of payments up to $99.50.
The other approach is to quantize by some fixed value no matter what the
payment is (maybe for better privacy?). I don't think that's a good idea
in the first place -- it trades off maybe a small win for your privacy
for using up everyone else's HTLC slots -- but if it is, it'll need to be
quite a small value so as not to force you to round up the overall payment
too much, and to allow small payments in the first place. But in that case
most channels will have their html_max_msat well above that value anyway.
> Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
The intuition is really the other way around: if you want a stable,
decentralised network, then you need the driving decision on routing to
be something other than just "who's cheaper by 0.0001%" -- otherwise
everyone just chooses the same route at all times (which becomes
centralised towards the single provider who can best monetise forwarding
via something other than fees), and probably that route quickly becomes
unusable due to being drained (which isn't stable).
(But of course, I hadn't had any ideas on what such a thing could be,
otherwise I'd have suggested something like this earlier!)
So, to extend the intuition further: that means that if using
htlc_max_msat as a valve/throttle can fill that role, then that's a reason
to not do weird things like force every HTLC to be 2**n msats or similar.
If there is a conflict, far better to have a lightning network that's
decentralised, stable, and doesn't require node operators to spy on
transactions to pay for their servers.
It's not quite as bad as you suggest though -- the payment sizes
don't need to have a flat distribution, they only need to have a
smooth/continuous distribution.
> * Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.
Imagine the price of coffee is $5, and you find three potential paths
to pay for that coffee:
Z -> A -> X
Z -> B -> C -> X
Z -> B -> D -> X
(I think you choose both the fee and max_msat for Z->A and Z->B hops,
so we'll assume they're 0%/infinite, respectively)
Suppose the fee on AX is 0.01%, and the total fee for BCX is 0.02%
and the total fee for BDX is 0.1%.
If AX's max_msat is $5, they'll get the entire transaction. If it's
$4.99, you might instead optimise fees by doing AMP: send $4.99 through
AX and $0.01 through BCX, for a total fee rate of 0.01002%.
If everyone quantizes at 10c (500sat?) instead of 1c (50sat?) or lower
then that just means instead of getting maybe a 0.2% reduction in payment
flow, AX gets a 2% reduction in payment flow.
Likewise, if AX's max_msat is $1, BCX's max_msat is $3, and BDX's max_msat
is $20, then you split your payment up as $1/$3/$1 and pay a fee of
0.034%. Meanwhile AX's payment flow has been reduced by perhaps 80%
(if everyone's buying $5 coffees), and BCX's by perhaps 25% (from $4 to
$3), allowing them to maintain balanced channels.
> So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.
No: without some sort of external throttle, fees have a tendency to be all
or nothing. If there's no metric other than fees, why would I ever choose
to pay 0.02% (let alone 0.1%!) in fees? And if a new path comes along
offering a fee rate of 0.00999% fees, why would I continue paying 0.01%?
Even if everyone does start quantizing their payments -- and does so with
an almost 6 order of magnitude jump from 1msat to 500sats -- you're only
implying traffic bumps of perhaps 2% when tweaking parameters that are
near important thresholds, rather than 100%.
> Feerates on the other hand are always going to be something that senders optimize for, [...]
Sure, but that can't be the end of the story, since it has a clear winner
that everyone immediately agrees upon, and there's no point anyone else
participating in trying to route lightning transactions.
There's plenty of other possible throttling mechanisms: at the very least,
senders can *not* optimise for fees, and instead randomly select routes
within a budget; or you can maintain external "reliability" scores for
nodes and factor those in along with fee rates.
What's novel and interesting about this approach (IMO) is it's one that
the channel operator can use directly (so the person who's meant to know
the private channel state is making the decision that depends on the
private channel state), and that they don't have a particular incentive
to lie about (with random choice, maybe you want to pretend you have many
nodes/channels so you get selected more often; if reliability is factored
in, maybe you're tempted to pretend to be more reliable than you are).
Cheers,
aj
📝 Original message:
On Mon, Sep 26, 2022 at 01:26:57AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to traffic volume;
> > > but this seems like it should mostly have a proportional response,
> > > with a small decrease in htlc_max_msat resulting in a small decrease in
> > > payment volume, and conversely. Much better for stability/optimisation!
> > This may depend on what gets popular for sender algorithms.
> > Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.
I don't think that's really the case.
One option is that you quantize based on the individual payment -- you
want to send $100, great, your software splits it into 50x $2 payments,
and routes them. But that doesn't have an all or nothing effect: if you
reject anything over $1.99, then instead of routing 1/50th of payments
up to $100, you're routing 1/50th of payments up to $99.50.
The other approach is to quantize by some fixed value no matter what the
payment is (maybe for better privacy?). I don't think that's a good idea
in the first place -- it trades off maybe a small win for your privacy
for using up everyone else's HTLC slots -- but if it is, it'll need to be
quite a small value so as not to force you to round up the overall payment
too much, and to allow small payments in the first place. But in that case
most channels will have their html_max_msat well above that value anyway.
> Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
The intuition is really the other way around: if you want a stable,
decentralised network, then you need the driving decision on routing to
be something other than just "who's cheaper by 0.0001%" -- otherwise
everyone just chooses the same route at all times (which becomes
centralised towards the single provider who can best monetise forwarding
via something other than fees), and probably that route quickly becomes
unusable due to being drained (which isn't stable).
(But of course, I hadn't had any ideas on what such a thing could be,
otherwise I'd have suggested something like this earlier!)
So, to extend the intuition further: that means that if using
htlc_max_msat as a valve/throttle can fill that role, then that's a reason
to not do weird things like force every HTLC to be 2**n msats or similar.
If there is a conflict, far better to have a lightning network that's
decentralised, stable, and doesn't require node operators to spy on
transactions to pay for their servers.
It's not quite as bad as you suggest though -- the payment sizes
don't need to have a flat distribution, they only need to have a
smooth/continuous distribution.
> * Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.
Imagine the price of coffee is $5, and you find three potential paths
to pay for that coffee:
Z -> A -> X
Z -> B -> C -> X
Z -> B -> D -> X
(I think you choose both the fee and max_msat for Z->A and Z->B hops,
so we'll assume they're 0%/infinite, respectively)
Suppose the fee on AX is 0.01%, and the total fee for BCX is 0.02%
and the total fee for BDX is 0.1%.
If AX's max_msat is $5, they'll get the entire transaction. If it's
$4.99, you might instead optimise fees by doing AMP: send $4.99 through
AX and $0.01 through BCX, for a total fee rate of 0.01002%.
If everyone quantizes at 10c (500sat?) instead of 1c (50sat?) or lower
then that just means instead of getting maybe a 0.2% reduction in payment
flow, AX gets a 2% reduction in payment flow.
Likewise, if AX's max_msat is $1, BCX's max_msat is $3, and BDX's max_msat
is $20, then you split your payment up as $1/$3/$1 and pay a fee of
0.034%. Meanwhile AX's payment flow has been reduced by perhaps 80%
(if everyone's buying $5 coffees), and BCX's by perhaps 25% (from $4 to
$3), allowing them to maintain balanced channels.
> So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.
No: without some sort of external throttle, fees have a tendency to be all
or nothing. If there's no metric other than fees, why would I ever choose
to pay 0.02% (let alone 0.1%!) in fees? And if a new path comes along
offering a fee rate of 0.00999% fees, why would I continue paying 0.01%?
Even if everyone does start quantizing their payments -- and does so with
an almost 6 order of magnitude jump from 1msat to 500sats -- you're only
implying traffic bumps of perhaps 2% when tweaking parameters that are
near important thresholds, rather than 100%.
> Feerates on the other hand are always going to be something that senders optimize for, [...]
Sure, but that can't be the end of the story, since it has a clear winner
that everyone immediately agrees upon, and there's no point anyone else
participating in trying to route lightning transactions.
There's plenty of other possible throttling mechanisms: at the very least,
senders can *not* optimise for fees, and instead randomly select routes
within a budget; or you can maintain external "reliability" scores for
nodes and factor those in along with fee rates.
What's novel and interesting about this approach (IMO) is it's one that
the channel operator can use directly (so the person who's meant to know
the private channel state is making the decision that depends on the
private channel state), and that they don't have a particular incentive
to lie about (with random choice, maybe you want to pretend you have many
nodes/channels so you get selected more often; if reliability is factored
in, maybe you're tempted to pretend to be more reliable than you are).
Cheers,
aj