Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-22 📝 Original message: > I think the problem of ...
📅 Original date posted:2021-02-22
📝 Original message:
> I think the problem of accidental channel closure is getting ignored by
> devs.
>
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on
> fixing accidental channel closure costs than any anti-DoS fee mechanism.
>
> Any deterrence of the channel jamming problem is economic so if the
> anti-DoS fee is tiny, then its deterrence will be tiny as well.
This struck me as an extremely salient point. One thing that has been
noticeable missing from these discussions is any sort of threat model or
attacker
profile. Given this is primarily a griefing attack, and the attacker doesn't
stand any direct gain, how high a fee is considered "adequate" deterrence
without also dramatically increasing the cost of node operation in the
average case?
If an attacker has say a budget of 20 BTC to blow as they just want to see
the world burn, then most parametrizations of attempt fees are likely
insufficient. In addition, if the HTLC attempt/hold fees rise well above
routing fees, then costs are also increased for senders in addition to
routing nodes.
Also IMO, it's important to re-state, that if channels are parametrized
properly (dust values, max/min HTLC, private channels, micropayment specific
channels, etc), then there is an inherent existing cost re the opportunity
cost of committing funds in channels and the chain fee cost of making the
series of channels in the first place.
Based on the discussion above, it appears that the decaying fee idea needs
closer examination to ensure it doesn't increase the day to day operational
cost of a routing node in order to defend against threats at the edges.
Nodes go down all the time for various reasons: need to allocate more disk,
software upgrade, infrastructure migrations, power outages, etc, etc. By
adding a steady decay cost, we introduce an idle penalty for lack of uptime
when holding an HTLC, similar to the availability slashing in PoS systems.
It would be unfortunate if an end result of such a solution is increasing
node operation costs as a whole, (which has other trickle down effects: less
nodes, higher routing fees, strain of dev-ops teams to ensure higher uptime
or loss of funds, etc), while having negligible effects on the "success"
profile of such an attack in practice.
If nodes wish to be compensated for committing capital to Lightning itself,
then markets such as Lightning Pool which rewards them for allocating the
capital (independent of use) for a period of time can help them scratch that
itch.
Returning back to the original point, it may very well be the case that the
very first solution proposed (circa 2015) to this issue: close out the
channel and send back a proof of closure, may in fact be more desirable from
the PoV of enforcing tangible costs given it requires the attacker to
forfeit on-chain fees in the case of an unsuccessful attack. Services that
require long lived HTLCs (HTLC mailboxes, etc) can flag the HTLCs as such in
the onion payload allowing nodes to preferentially forward or reject them.
Zooming out, I have a new idea in this domain that attempts to tackle things
from a different angle. Assuming that any efforts to add further off-chain
costs are insignificant in the face of an attacker with few constraints
w.r.t budget, perhaps some efforts should be focused on instead ensuring
that if there's "turbulence" in the network, it can gracefully degraded to a
slightly more restricted operating mode until the storm passes. If an
attacker spends coins/time/utxos, etc to be in position to distrust things,
but then finds that things are working as normal, such a solution may serve
as a low cost deterrence mechanism that won't tangibly increase
operation/forwarding/payment costs within the network. Working out some of
the kinks re the idea, but I hope to publish it sometime over the next few
days.
-- Laolu
On Fri, Feb 12, 2021 at 8:24 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Joost,
>
> > > Not quite up-to-speed back into this, but, I believe an issue with
> using feerates rather than fixed fees is "what happens if a channel is
> forced onchain"?
> > >
> > > Suppose after C offers the HTLC to D, the C-D channel, for any reason,
> is forced onchain, and the blockchain is bloated and the transaction
> remains floating in mempools until very close to the timeout of C-D.
> > > C is now liable for a large time the payment is held, and because the
> C-D channel was dropped onchain, presumably any parameters of the HTLC
> (including penalties D owes to C) have gotten fixed at the time the channel
> was dropped onchain.
> >
> > > The simplicity of the fixed fee is that it bounds the amount of risk
> that C has in case its outgoing channel is dropped onchain.
> >
> > The risk is bound in both cases. If you want you can cap the variable
> fee at a level that isn't considered risky, but it will then not fully
> cover the actual cost of the locked-up htlc. Also any anti-DoS fee could
> very well turn out to be insignificant to the cost of closing and reopening
> a channel with the state of the mempool these days.
>
>
> I think the problem of accidental channel closure is getting ignored by
> devs.
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on fixing
> accidental channel closure costs than any anti-DoS fee mechanism.
> Any deterrence of the channel jamming problem is economic so if the
> anti-DoS fee is tiny, then its deterrence will be tiny as well.
>
> It seems to me that adding this anti-DoS fee *on top of* an accidental
> channel closure is just adding insult to injury, when we should probably be
> considering how to ameliorate the injury.
> Otherwise forwarding nodes will themselves be deterred from operating at
> all.
>
>
> > > Is assuming increasing `hodl_fee_rate` along a payment path at odds
> with the ordering of timelocks ?
> >
> > I don't think it is.
>
> In terms of privacy, this is more dangerous.
>
> The decrementing timelock already leaks an upper bound on the distance to
> payee.
> An incrementing holdfee leaks an upper bound on the distance to payer.
> This translates to a single payment-part being more easily associated with
> the payer and payee.
>
>
> 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/20210222/be677d34/attachment.html>;
📝 Original message:
> I think the problem of accidental channel closure is getting ignored by
> devs.
>
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on
> fixing accidental channel closure costs than any anti-DoS fee mechanism.
>
> Any deterrence of the channel jamming problem is economic so if the
> anti-DoS fee is tiny, then its deterrence will be tiny as well.
This struck me as an extremely salient point. One thing that has been
noticeable missing from these discussions is any sort of threat model or
attacker
profile. Given this is primarily a griefing attack, and the attacker doesn't
stand any direct gain, how high a fee is considered "adequate" deterrence
without also dramatically increasing the cost of node operation in the
average case?
If an attacker has say a budget of 20 BTC to blow as they just want to see
the world burn, then most parametrizations of attempt fees are likely
insufficient. In addition, if the HTLC attempt/hold fees rise well above
routing fees, then costs are also increased for senders in addition to
routing nodes.
Also IMO, it's important to re-state, that if channels are parametrized
properly (dust values, max/min HTLC, private channels, micropayment specific
channels, etc), then there is an inherent existing cost re the opportunity
cost of committing funds in channels and the chain fee cost of making the
series of channels in the first place.
Based on the discussion above, it appears that the decaying fee idea needs
closer examination to ensure it doesn't increase the day to day operational
cost of a routing node in order to defend against threats at the edges.
Nodes go down all the time for various reasons: need to allocate more disk,
software upgrade, infrastructure migrations, power outages, etc, etc. By
adding a steady decay cost, we introduce an idle penalty for lack of uptime
when holding an HTLC, similar to the availability slashing in PoS systems.
It would be unfortunate if an end result of such a solution is increasing
node operation costs as a whole, (which has other trickle down effects: less
nodes, higher routing fees, strain of dev-ops teams to ensure higher uptime
or loss of funds, etc), while having negligible effects on the "success"
profile of such an attack in practice.
If nodes wish to be compensated for committing capital to Lightning itself,
then markets such as Lightning Pool which rewards them for allocating the
capital (independent of use) for a period of time can help them scratch that
itch.
Returning back to the original point, it may very well be the case that the
very first solution proposed (circa 2015) to this issue: close out the
channel and send back a proof of closure, may in fact be more desirable from
the PoV of enforcing tangible costs given it requires the attacker to
forfeit on-chain fees in the case of an unsuccessful attack. Services that
require long lived HTLCs (HTLC mailboxes, etc) can flag the HTLCs as such in
the onion payload allowing nodes to preferentially forward or reject them.
Zooming out, I have a new idea in this domain that attempts to tackle things
from a different angle. Assuming that any efforts to add further off-chain
costs are insignificant in the face of an attacker with few constraints
w.r.t budget, perhaps some efforts should be focused on instead ensuring
that if there's "turbulence" in the network, it can gracefully degraded to a
slightly more restricted operating mode until the storm passes. If an
attacker spends coins/time/utxos, etc to be in position to distrust things,
but then finds that things are working as normal, such a solution may serve
as a low cost deterrence mechanism that won't tangibly increase
operation/forwarding/payment costs within the network. Working out some of
the kinks re the idea, but I hope to publish it sometime over the next few
days.
-- Laolu
On Fri, Feb 12, 2021 at 8:24 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Joost,
>
> > > Not quite up-to-speed back into this, but, I believe an issue with
> using feerates rather than fixed fees is "what happens if a channel is
> forced onchain"?
> > >
> > > Suppose after C offers the HTLC to D, the C-D channel, for any reason,
> is forced onchain, and the blockchain is bloated and the transaction
> remains floating in mempools until very close to the timeout of C-D.
> > > C is now liable for a large time the payment is held, and because the
> C-D channel was dropped onchain, presumably any parameters of the HTLC
> (including penalties D owes to C) have gotten fixed at the time the channel
> was dropped onchain.
> >
> > > The simplicity of the fixed fee is that it bounds the amount of risk
> that C has in case its outgoing channel is dropped onchain.
> >
> > The risk is bound in both cases. If you want you can cap the variable
> fee at a level that isn't considered risky, but it will then not fully
> cover the actual cost of the locked-up htlc. Also any anti-DoS fee could
> very well turn out to be insignificant to the cost of closing and reopening
> a channel with the state of the mempool these days.
>
>
> I think the problem of accidental channel closure is getting ignored by
> devs.
> If we think any anti-DoS fee will be "insignificant" compared to the cost
> of closing and reopening a channel, maybe dev attention should be on fixing
> accidental channel closure costs than any anti-DoS fee mechanism.
> Any deterrence of the channel jamming problem is economic so if the
> anti-DoS fee is tiny, then its deterrence will be tiny as well.
>
> It seems to me that adding this anti-DoS fee *on top of* an accidental
> channel closure is just adding insult to injury, when we should probably be
> considering how to ameliorate the injury.
> Otherwise forwarding nodes will themselves be deterred from operating at
> all.
>
>
> > > Is assuming increasing `hodl_fee_rate` along a payment path at odds
> with the ordering of timelocks ?
> >
> > I don't think it is.
>
> In terms of privacy, this is more dangerous.
>
> The decrementing timelock already leaks an upper bound on the distance to
> payee.
> An incrementing holdfee leaks an upper bound on the distance to payer.
> This translates to a single payment-part being more easily associated with
> the payer and payee.
>
>
> 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/20210222/be677d34/attachment.html>;