Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-15 📝 Original message: On 8/15/21 22:02, Anthony ...
📅 Original date posted:2021-08-15
📝 Original message:
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 split payments.
Yes, matching the real-world costs of forwarding an HTLC.
> If every channel has the same (base,proportional) fee pair, and send a
> payment along a single path, you're paying n*(base+k*proportional). If
> you split the payment, and send half of it one way, and half the other
> way, you're paying n*(2*base+k*proportional). If you split the payment
> four ways, you're paying n*(4*base+k*proportional). Where's the value
> to the network in penalising payment splitting?
Yes. You have to pay the cost of a node. If we're really worried about this, we should be talking about upfront fees
and/or refunds on HTLC fulfillment, not removing the fees entirely.
> Being denominated in sats, the base fee also changes in value as the
> bitcoin price changes -- c-lightning dropped the base fee to 1sat (from
> 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x
> since then, and it seems unlikely the fixed costs of a successful HTLC
> payment have likewise increased 4x. Proportional fees deal with this
> factor automatically, of course.
This isn't a protocol issue, implementations can automate this without issue.
>> There's real cost to distorting the fee structures on the network away from
>> the costs of node operators,
>
> That's precisely what the base fee is already doing. Yes, we need some
> other way of charging fees to prevent using up too many slots or having
> transactions not fail in a timely manner, but the base fee does not
> do that.
Huh? For values much smaller than a node's liquidity, the cost for nodes is (mostly) a function of HTLCs, not the value.
The cost to nodes is largely (a) the forever-storage that exists, roughly, per HTLC ever on a channel, (b) the HTLC
slots which are highly limited for technical reasons per channel, (c) the disk/cpu/network/etc operations per HTLC on an
channel, (d) the liquidity required per node. I'd argue (c) is basically zero in any realistic context, (a) is pretty
low, but could be non-zero in some cases, so you really just have (b) and (d). For many HTLCs forwarded today, the
liquidity on a channel isn't much, so I'd argue for many HTLCs forwarded today per-payment costs mirror the cost to a
node much, much, much, much better than some proportional fees?
I'm really not sure where you're coming from here.
>> Imagine we find some great way to address HTLC slot flooding/DoS attacks (or
>> just chose to do it in a not-great way) by charging for HTLC slot usage, now
>> we can't fix a critical DoS issue because the routing algorithms we deployed
>> can't handle the new costing.
>
> I don't think that's true. The two things we don't charge for that can
> be abused by probing spam are HTLC slot usage and channel balance usage;
> both are problems only in proportion to the amount of time they're held
> open, and the latter is also only a problem proportional to the value
> being reserved. [0]
>
> Additionally, I don't think HTLC slot usage needs to be kept as a
> limitation after we switch to eltoo;
The HTLC slot limit is to keep transactions broadcastable. I don't see why this would change, you still get an output
for each HTLC on the latest commitment in eltoo, AFAIU.
> and in the meantime, I think it can
> be better managed via adjusting the min_htlc_amount -- at least for the
> scenario where problems are being caused by legitimate payment attempts,
> which is also the only place base fee can help.
Sure, we could also shift towards upfront fees or similar solutions, though, and that was my point - if we start
dropping absolute fee amounts now in order to make some given routing algorithm work, we box ourselves in here, and
quite needlessly given no one has (yet) done the legwork to show that we even *need* to box ourselves in.
> [0] (Well, ln-penalty's requirement to permanently store HTLC information
> in order to apply the penalty is in some sense a constant
> cost, however the impact is also proportional to value, and for
> sufficiently low value HTLCs can be ignored entirely if the HTLC
> isn't included in the channel commitment)
>
>> Instead, we should investigate how we can
>> apply the ideas here with the more complicated fee structures we have.
>
> Fee structures should be *simple* not complicated.
>
> I mean, it's kind of great that we started off complicated -- if it
> turns out base fee isn't necessary, it's easy to just set it to zero;
> if we didn't have it, but needed it, it would be much more annoying to
> add it in later.
Fee structures should also match reality, and allow node operators sufficient flexibility to capture their costs. I
think we have a design that does so quite well - its pretty simple, there's only two knobs, but the two knobs capture
exactly the two broad categories of costs a node operator has.
>> Color me an optimist, but I'm quite confident with sufficient elbow grease
>> and heuristics we can get 95% of the way there. We can and should revisit
>> these conversations if such exploration is done and we find that its not
>> possible, but until then this all feels incredibly premature.
>
> Depends; I don't think it makes sense to try to ban nodes that don't have
> a base fee of zero or anything, but random people on twitter advocating
> that node operators should set it to zero and just worry about optimising
> via the proportional fee and the min htlc amount seems fine.
Sure, the great thing about today is because the protocol exposes decent knobs operators can tune their fee structures
any way they want, providing competition and multiple paths to nodes with potentially very divergent fees depending on
the type of payment. Absent liquidity limits, this should provide better service for all types of payments - routing
them to nodes that will support those types of payments!
> For an experimental plugin that aggressively splits payments up, I think
> either ignoring channels with >0 base fee entirely, or deciding that
> you're happy to spend a total of X sats on base fees, and then ignoring
> channels whose base fee is greater than X/paths/path-length sats is fine.
Sure, experimental plugins can do whatever they want!
> But long term, I also think that the base fee is an entirely unhelpful
> complication that will eventually just be hardcoded to zero by everyone,
> and eventually channels that propose non-zero base fees won't even be
> gossiped. I don't expect that to happen any time soon though.
I very strongly disagree, as discussed, and am left highly dubious that it is a practical complication in any case.
Published at
2023-06-09 12:40:57Event JSON
{
"id": "bc79c98c753a17ed2215995fedc3b4b6d10a794911a78851183fc14f03d52ad9",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686314457,
"kind": 1,
"tags": [
[
"e",
"9d3801d66d3239d18d7b986ecb31f0f1d7b54c421aae753d10192ad5353e49a0",
"",
"root"
],
[
"e",
"7005b4232436d50eebf27cfe7f8ed14c174e59c9700d22dbce34d2e146cecc49",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2021-08-15\n📝 Original message:\nOn 8/15/21 22:02, Anthony Towns wrote:\n\u003e\u003e In\n\u003e\u003e one particular class of applicable routing algorithms you could use for\n\u003e\u003e lightning routing having a base fee makes the algorithm intractably slow,\n\u003e \n\u003e I don't think of that as the problem, but rather as the base fee having\n\u003e a multiplicative effect as you split payments.\n\nYes, matching the real-world costs of forwarding an HTLC.\n\n\u003e If every channel has the same (base,proportional) fee pair, and send a\n\u003e payment along a single path, you're paying n*(base+k*proportional). If\n\u003e you split the payment, and send half of it one way, and half the other\n\u003e way, you're paying n*(2*base+k*proportional). If you split the payment\n\u003e four ways, you're paying n*(4*base+k*proportional). Where's the value\n\u003e to the network in penalising payment splitting?\n\nYes. You have to pay the cost of a node. If we're really worried about this, we should be talking about upfront fees \nand/or refunds on HTLC fulfillment, not removing the fees entirely.\n\n\u003e Being denominated in sats, the base fee also changes in value as the\n\u003e bitcoin price changes -- c-lightning dropped the base fee to 1sat (from\n\u003e 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x\n\u003e since then, and it seems unlikely the fixed costs of a successful HTLC\n\u003e payment have likewise increased 4x. Proportional fees deal with this\n\u003e factor automatically, of course.\n\nThis isn't a protocol issue, implementations can automate this without issue.\n\n\u003e\u003e There's real cost to distorting the fee structures on the network away from\n\u003e\u003e the costs of node operators,\n\u003e \n\u003e That's precisely what the base fee is already doing. Yes, we need some\n\u003e other way of charging fees to prevent using up too many slots or having\n\u003e transactions not fail in a timely manner, but the base fee does not\n\u003e do that.\n\nHuh? For values much smaller than a node's liquidity, the cost for nodes is (mostly) a function of HTLCs, not the value. \nThe cost to nodes is largely (a) the forever-storage that exists, roughly, per HTLC ever on a channel, (b) the HTLC \nslots which are highly limited for technical reasons per channel, (c) the disk/cpu/network/etc operations per HTLC on an \nchannel, (d) the liquidity required per node. I'd argue (c) is basically zero in any realistic context, (a) is pretty \nlow, but could be non-zero in some cases, so you really just have (b) and (d). For many HTLCs forwarded today, the \nliquidity on a channel isn't much, so I'd argue for many HTLCs forwarded today per-payment costs mirror the cost to a \nnode much, much, much, much better than some proportional fees?\n\nI'm really not sure where you're coming from here.\n\n\u003e\u003e Imagine we find some great way to address HTLC slot flooding/DoS attacks (or\n\u003e\u003e just chose to do it in a not-great way) by charging for HTLC slot usage, now\n\u003e\u003e we can't fix a critical DoS issue because the routing algorithms we deployed\n\u003e\u003e can't handle the new costing.\n\u003e \n\u003e I don't think that's true. The two things we don't charge for that can\n\u003e be abused by probing spam are HTLC slot usage and channel balance usage;\n\u003e both are problems only in proportion to the amount of time they're held\n\u003e open, and the latter is also only a problem proportional to the value\n\u003e being reserved. [0]\n\u003e \n\u003e Additionally, I don't think HTLC slot usage needs to be kept as a\n\u003e limitation after we switch to eltoo;\n\nThe HTLC slot limit is to keep transactions broadcastable. I don't see why this would change, you still get an output \nfor each HTLC on the latest commitment in eltoo, AFAIU.\n\n\u003e and in the meantime, I think it can\n\u003e be better managed via adjusting the min_htlc_amount -- at least for the\n\u003e scenario where problems are being caused by legitimate payment attempts,\n\u003e which is also the only place base fee can help.\n\nSure, we could also shift towards upfront fees or similar solutions, though, and that was my point - if we start \ndropping absolute fee amounts now in order to make some given routing algorithm work, we box ourselves in here, and \nquite needlessly given no one has (yet) done the legwork to show that we even *need* to box ourselves in.\n\n\u003e [0] (Well, ln-penalty's requirement to permanently store HTLC information\n\u003e in order to apply the penalty is in some sense a constant\n\u003e cost, however the impact is also proportional to value, and for\n\u003e sufficiently low value HTLCs can be ignored entirely if the HTLC\n\u003e isn't included in the channel commitment)\n\u003e \n\u003e\u003e Instead, we should investigate how we can\n\u003e\u003e apply the ideas here with the more complicated fee structures we have.\n\u003e \n\u003e Fee structures should be *simple* not complicated.\n\u003e \n\u003e I mean, it's kind of great that we started off complicated -- if it\n\u003e turns out base fee isn't necessary, it's easy to just set it to zero;\n\u003e if we didn't have it, but needed it, it would be much more annoying to\n\u003e add it in later.\n\nFee structures should also match reality, and allow node operators sufficient flexibility to capture their costs. I \nthink we have a design that does so quite well - its pretty simple, there's only two knobs, but the two knobs capture \nexactly the two broad categories of costs a node operator has.\n\n\u003e\u003e Color me an optimist, but I'm quite confident with sufficient elbow grease\n\u003e\u003e and heuristics we can get 95% of the way there. We can and should revisit\n\u003e\u003e these conversations if such exploration is done and we find that its not\n\u003e\u003e possible, but until then this all feels incredibly premature.\n\u003e \n\u003e Depends; I don't think it makes sense to try to ban nodes that don't have\n\u003e a base fee of zero or anything, but random people on twitter advocating\n\u003e that node operators should set it to zero and just worry about optimising\n\u003e via the proportional fee and the min htlc amount seems fine.\n\nSure, the great thing about today is because the protocol exposes decent knobs operators can tune their fee structures \nany way they want, providing competition and multiple paths to nodes with potentially very divergent fees depending on \nthe type of payment. Absent liquidity limits, this should provide better service for all types of payments - routing \nthem to nodes that will support those types of payments!\n\n\u003e For an experimental plugin that aggressively splits payments up, I think\n\u003e either ignoring channels with \u003e0 base fee entirely, or deciding that\n\u003e you're happy to spend a total of X sats on base fees, and then ignoring\n\u003e channels whose base fee is greater than X/paths/path-length sats is fine.\n\nSure, experimental plugins can do whatever they want!\n\n\u003e But long term, I also think that the base fee is an entirely unhelpful\n\u003e complication that will eventually just be hardcoded to zero by everyone,\n\u003e and eventually channels that propose non-zero base fees won't even be\n\u003e gossiped. I don't expect that to happen any time soon though.\n\nI very strongly disagree, as discussed, and am left highly dubious that it is a practical complication in any case.",
"sig": "9226a2b125c25482af055773d53cc04b27fb7f087d2f21a06ad5b9c6811441d89c5fc0203792ffa941da47749ba6e7d72fd192bf6918a4963271c310a636126c"
}