Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-31 🗒️ Summary of this message: A different ...
📅 Original date posted:2023-07-31
🗒️ Summary of this message: A different approach to dealing with attacks on the network is to scale up capacity and make attackers pay for the resources they use, turning them into a profit center. This could be done through fees for message spam and holding funds. However, there are challenges in implementing fees based on the time an HTLC is held. The suggested fees are low, so hourly precision should be sufficient.
📝 Original message:
Hi AJ,
A different way of thinking about the monetary approach is in terms of
> scaling rather than deterrance: that is, try to make the cost that the
> attacker pays sufficient to scale up your node/the network so that you
> continue to have excess capacity to serve regular users.
>
> In that case, if people are suddenly routing their netflix data and
> nostr photo libraries over lightning onion packets, that's fine: you
> make them pay amazon ec2 prices plus 50% for the resources they use,
> and when they do , you deploy more servers. ie, turn your attackers and
> spammers into a profit centre.
>
> I've had an email about this sitting in my drafts for a few years now,
> but I think this could work something like:
>
> - message spam (ie, onion traffic costs): when you send a message
> to a peer, pay for its bandwidth and compute. Perhaps something
> like 20c/GB is reasonable, which is something like 1msat per onion
> packet, so perhaps 20msat per onion packet if you're forwarding it
> over 20 hops.
>
> - liquidity DoS prevention: if you're in receipt of a HTLC/PTLC and
> aren't cancelling or confirming it, you pay your peer a fee for
> holding their funds. (if you're forwarding the HTLC, then whoever you
> forwarded to pays you a slightly higher fee, while they hold your
> funds) Something like 1ppm per hour matches a 1% pa return, so if
> you're an LSP holding on to a $20 payment waiting for the recipient to
> come online and claim it, then you might be paying out $0.0004 per hour
> (1.4sat) in order for 20 intermediate hops to each be making 20%
> pa interest on their held up funds.
>
> - actual payment incentives: eg, a $20 payment paying 0.05% fees
> (phoenix's minimum) costs $0.01 (33sat). Obviously you want this
> number to be a lot higher than all the DoS prevention fees.
>
> If you get too much message spam, you fire up more amazon compute
> and take maybe 10c/GB in profit; if all your liquidity gets used up,
> congrats you've just gotten 20%+ APY on your bitcoin without third party
> risk and you can either reinvest your profits or increase your fees; and
> all of those numbers are just noise compared to actual payment traffic,
> which is 30x or 1500x more profitable.
>
Message spam is outside the scope of this solution.
As for liquidity DoS, the “holy grail” is indeed charging fees as a
function of the time the HTLC was held. As for now, we are not aware of a
reasonable way to do this. There is no universal clock, and there is no way
for me to prove that a message was sent to you, and you decided to pretend
you didn't. It can easily happen that the fee for a two-week unresolved
HTLC is higher than the fee for a quickly resolving one. Because of this,
we turn to reputation for slow jamming and use fees only for quick jamming.
See later comments on the specific suggestion outlined.
The amounts here are all very low, so I don't think you really need much
> more precision than "hourly". I think you could even do it "per block"
> and convert "1% pa" as actually "0.2 parts per million per block", since
> the only thing time is relevant for is turning liquidity DoS into an APY
> figure. Presumably that needs some tweaking to deal with the possibility
> of reorgs or stale blocks.
>
This is again the same problem with a node preferring the fees for a
two-week unresolved HTLC over a quick resolving one. See comments below for
the far downstream node.
I think the worst case for that scenario is if you have a route
>
> A1 -> A2 -> .. -> A19 -> B -> A20
>
> then B closes the {B,A20} channel and at the end of the timeout A20 claims
> the funds. At that point B will have paid liquidity fees to A1..A19 for
> the full two week period, but will have only received a fixed payout
> from A20 due to the channel close.
>
> At 10% APY, with a $1000 payment, B will have paid ~$73 to A (7.3%). If
> the close channel transaction costs, say, $5, then either you end up with
> B wanting to close the channel early in non-attack scenarios (they collect
> $73 from A20, but only pay perhaps 4c back to A1..A19, and perhaps $6 to
> open and close the channel), or you end up with A holding up the funds
> and leaching off B (B only collects, say, $20 from A20, but then A20
> claims the funds after two weeks so is either up $75 if B didn't claim
> the funds from A19, or is up $53 after B paid liquidity fees for 2 weeks).
>
> _But_ I think this is an unreasonable scenario: the only reason for B to
> forward a HTLC with a 2 week expiry is if they're early in the route,
> but the only reason to accept a large liquidity fee is if they're late
> in the route. So I think you can solve that by only forwarding a payment
> if the liquidity fee rate multiplied by the expiry is below a cap, eg:
>
> A19 -> B : wants 36ppm per block; cap/ppm = 500/36 = 13.8
> B -> A20 : expiry is in 13 blocks; wants 38ppm per block
>
> (2ppm per block ~= 10% APY)
>
> For comparison, at the start of the chain, things look like:
>
> A2 -> A3 : wants 2ppm per block; cap/ppm = 500/2 = 250
> A3 -> A4 : expiry is in 250 blocks; wants 4ppm per block
>
> In each case, the commitment tx would look like:
>
> $1000 HTLC paying Y refunding to X
> $0.50 liquidity fee bonus to X's balance (500ppm cap)
>
I think this is another take on time-based fees. In this variation, the
victim is trying to take a fee from the attacker. If the attacker is not
willing to pay the fee (and why would they?), then the victim has to force
close. There is no way for the victim to prove that it is someone
downstream holding the HTLC and not them.
> > - They’re not large enough to be enforceable, so somebody always has
> > to give the money back off chain.
>
> If the cap is 500ppm per block, then the liquidity fees for a 2000sat
> payment ($0.60) are redeemable onchain.
>
This heavily depends on the on-chain fees, and so will need to be
updated as a function of that, and adds another layer of complication.
Thanks for the interesting email,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230731/6ca8855f/attachment-0001.html>;
🗒️ Summary of this message: A different approach to dealing with attacks on the network is to scale up capacity and make attackers pay for the resources they use, turning them into a profit center. This could be done through fees for message spam and holding funds. However, there are challenges in implementing fees based on the time an HTLC is held. The suggested fees are low, so hourly precision should be sufficient.
📝 Original message:
Hi AJ,
A different way of thinking about the monetary approach is in terms of
> scaling rather than deterrance: that is, try to make the cost that the
> attacker pays sufficient to scale up your node/the network so that you
> continue to have excess capacity to serve regular users.
>
> In that case, if people are suddenly routing their netflix data and
> nostr photo libraries over lightning onion packets, that's fine: you
> make them pay amazon ec2 prices plus 50% for the resources they use,
> and when they do , you deploy more servers. ie, turn your attackers and
> spammers into a profit centre.
>
> I've had an email about this sitting in my drafts for a few years now,
> but I think this could work something like:
>
> - message spam (ie, onion traffic costs): when you send a message
> to a peer, pay for its bandwidth and compute. Perhaps something
> like 20c/GB is reasonable, which is something like 1msat per onion
> packet, so perhaps 20msat per onion packet if you're forwarding it
> over 20 hops.
>
> - liquidity DoS prevention: if you're in receipt of a HTLC/PTLC and
> aren't cancelling or confirming it, you pay your peer a fee for
> holding their funds. (if you're forwarding the HTLC, then whoever you
> forwarded to pays you a slightly higher fee, while they hold your
> funds) Something like 1ppm per hour matches a 1% pa return, so if
> you're an LSP holding on to a $20 payment waiting for the recipient to
> come online and claim it, then you might be paying out $0.0004 per hour
> (1.4sat) in order for 20 intermediate hops to each be making 20%
> pa interest on their held up funds.
>
> - actual payment incentives: eg, a $20 payment paying 0.05% fees
> (phoenix's minimum) costs $0.01 (33sat). Obviously you want this
> number to be a lot higher than all the DoS prevention fees.
>
> If you get too much message spam, you fire up more amazon compute
> and take maybe 10c/GB in profit; if all your liquidity gets used up,
> congrats you've just gotten 20%+ APY on your bitcoin without third party
> risk and you can either reinvest your profits or increase your fees; and
> all of those numbers are just noise compared to actual payment traffic,
> which is 30x or 1500x more profitable.
>
Message spam is outside the scope of this solution.
As for liquidity DoS, the “holy grail” is indeed charging fees as a
function of the time the HTLC was held. As for now, we are not aware of a
reasonable way to do this. There is no universal clock, and there is no way
for me to prove that a message was sent to you, and you decided to pretend
you didn't. It can easily happen that the fee for a two-week unresolved
HTLC is higher than the fee for a quickly resolving one. Because of this,
we turn to reputation for slow jamming and use fees only for quick jamming.
See later comments on the specific suggestion outlined.
The amounts here are all very low, so I don't think you really need much
> more precision than "hourly". I think you could even do it "per block"
> and convert "1% pa" as actually "0.2 parts per million per block", since
> the only thing time is relevant for is turning liquidity DoS into an APY
> figure. Presumably that needs some tweaking to deal with the possibility
> of reorgs or stale blocks.
>
This is again the same problem with a node preferring the fees for a
two-week unresolved HTLC over a quick resolving one. See comments below for
the far downstream node.
I think the worst case for that scenario is if you have a route
>
> A1 -> A2 -> .. -> A19 -> B -> A20
>
> then B closes the {B,A20} channel and at the end of the timeout A20 claims
> the funds. At that point B will have paid liquidity fees to A1..A19 for
> the full two week period, but will have only received a fixed payout
> from A20 due to the channel close.
>
> At 10% APY, with a $1000 payment, B will have paid ~$73 to A (7.3%). If
> the close channel transaction costs, say, $5, then either you end up with
> B wanting to close the channel early in non-attack scenarios (they collect
> $73 from A20, but only pay perhaps 4c back to A1..A19, and perhaps $6 to
> open and close the channel), or you end up with A holding up the funds
> and leaching off B (B only collects, say, $20 from A20, but then A20
> claims the funds after two weeks so is either up $75 if B didn't claim
> the funds from A19, or is up $53 after B paid liquidity fees for 2 weeks).
>
> _But_ I think this is an unreasonable scenario: the only reason for B to
> forward a HTLC with a 2 week expiry is if they're early in the route,
> but the only reason to accept a large liquidity fee is if they're late
> in the route. So I think you can solve that by only forwarding a payment
> if the liquidity fee rate multiplied by the expiry is below a cap, eg:
>
> A19 -> B : wants 36ppm per block; cap/ppm = 500/36 = 13.8
> B -> A20 : expiry is in 13 blocks; wants 38ppm per block
>
> (2ppm per block ~= 10% APY)
>
> For comparison, at the start of the chain, things look like:
>
> A2 -> A3 : wants 2ppm per block; cap/ppm = 500/2 = 250
> A3 -> A4 : expiry is in 250 blocks; wants 4ppm per block
>
> In each case, the commitment tx would look like:
>
> $1000 HTLC paying Y refunding to X
> $0.50 liquidity fee bonus to X's balance (500ppm cap)
>
I think this is another take on time-based fees. In this variation, the
victim is trying to take a fee from the attacker. If the attacker is not
willing to pay the fee (and why would they?), then the victim has to force
close. There is no way for the victim to prove that it is someone
downstream holding the HTLC and not them.
> > - They’re not large enough to be enforceable, so somebody always has
> > to give the money back off chain.
>
> If the cap is 500ppm per block, then the liquidity fees for a 2000sat
> payment ($0.60) are redeemable onchain.
>
This heavily depends on the on-chain fees, and so will need to be
updated as a function of that, and adds another layer of complication.
Thanks for the interesting email,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230731/6ca8855f/attachment-0001.html>;