📅 Original date posted:2020-10-19
📝 Original message:
Good morning list,
I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.
I've kept it very high-level for now; we can add nitty-gritty technical
details as we slowly
converge towards acceptable solutions. I have probably missed subtleties
from previous proposals;
feel free to contribute to correct my mistakes. I have omitted for examples
the details of Rusty's
previous proposal since he mentioned a new, better one that will be
described soon.
While doing this exercise, I couldn't find a reason why the `reverse
upfront payment` proposal
would be broken (notice that I described it using a flat amount after a
grace period, not an amount
based on the time HTLCs are held). Can someone point me to the most obvious
attacks on it?
It feels to me that its only issue is that it still allows spamming for
durations smaller than the
grace period; my gut feeling is that if we add a smaller forward direction
upfront payment to
complement it it could be a working solution.
Pasting it here for completeness:
### Reverse upfront payment
This proposal builds on the previous one, but reverses the flow. Nodes pay
a fee for *receiving*
HTLCs instead of *sending* them.
```text
A -----> B -----> C -----> D
B pays A to receive the HTLC.
Then C pays B to receive the forwarded HTLC.
Then D pays C to receive the forwarded HTLC.
```
There must be a grace period during which no fees are paid; otherwise the
`uncontrolled spam` attack
allows the attacker to force all nodes in the route to pay fees while he's
not paying anything.
The fee cannot be the same at each hop, otherwise it's free for the
attacker when he is at both
ends of the payment route.
This fee must increase as the HTLC travels downstream: this ensures that
nodes that hold HTLCs
longer are penalized more than nodes that fail them fast, and if a node has
to hold an HTLC for a
long time because it's stuck downstream, they will receive more fees than
what they have to pay.
The grace period cannot be the same at each hop either, otherwise the
attacker can force Bob to be
the only one to pay fees. Similarly to how we have `cltv_expiry_delta`,
nodes must have a
`grace_period_delta` and the `grace_period` must be bigger upstream than
downstream.
Drawbacks:
* The attacker can still lock HTLCs for the duration of the `grace_period`
and repeat the attack
continuously
Open questions:
* Does the fee need to be based on the time the HTLC is held?
* What happens when a channel closes and HTLC-timeout has to be redeemed
on-chain?
* Can we implement this without exposing the route length to intermediate
nodes?
Cheers,
Bastien
[1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
Le dim. 18 oct. 2020 à 09:25, Joost Jager <joost.jager at gmail.com> a écrit :
> > We've looked at all kinds of trustless payment schemes to keep users
>>
>> > honest, but it appears that none of them is satisfactory. Maybe it is
>> even
>> > theoretically impossible to create a scheme that is trustless and has
>> all
>> > the properties that we're looking for. (A proof of that would also be
>>
>> > useful information to have.)
>>
>> I don't think anyone has drawn yet a formal proof of this, but roughly a
>> routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
>> to answer the following question "Is this payment coming from Alice and
>> going to Caroll will compensate for my resources consumption ?". With the
>> current LN system, the compensation is conditional on payment settlement
>> success and both Alice and Caroll are distrusted yet discretionary on
>> failure/success. Thus the underscored question is undecidable for a routing
>> peer making relay decisions only on packet observation.
>>
>> One way to mitigate this, is to introduce statistical observation of
>> sender/receiver, namely a reputation system. It can be achieved through a
>> scoring system, web-of-trust, or whatever other solution with the same
>> properties.
>> But still it must be underscored that statistical observations are only
>> probabilistic and don't provide resource consumption security to Bob, the
>> routing peer, in a deterministic way. A well-scored peer may start to
>> suddenly misbehave.
>>
>> In that sense, the efficiency evaluation of a reputation-based solution
>> to deter DoS must be evaluated based based on the loss of the reputation
>> bearer related to the potential damage which can be inflicted. It's just
>> reputation sounds harder to compute accurately than a pure payment-based
>> DoS protection system.
>>
>
> I can totally see the issues and complexity of a reputation-based system.
> With 'trustless payment scheme' I meant indeed a trustless pure
> payment-based DoS protection system and the question whether such a system
> can be proven to not exist. A sender would pay an up-front amount to cover
> the maximum cost, but with the guarantee that nodes can only take a fair
> part of the deposit (based on actual lock time). Perhaps the taproot
> upgrade offers new possibilities with adaptor signatures to atomically swap
> part of the up-front payment with htlc-received-in-time-signatures from
> nodes downstream (random wild idea).
>
>
>> > What I can see working is a system where peers charge each other a hold
>> fee
>> > for forwarded HTLCs based on the actual lock time (not the maximum lock
>>
>> > time) and the htlc value. This is just for the cost of holding and
>> separate
>> > from the routing fee that is earned when the payment settles
>>
>> Yes I guess any solution will work as long as it enforces an asymmetry
>> between the liquidity requester and a honest routing peer. This asymmetry
>> can be defined as guaranteeing that the routing peer's incoming/outgoing
>> balance is always increasing, independently of payment success. Obviously
>> this increase should be materialized by a payment, while minding it might
>> be discounted based on requester reputation ("pay-with-your-reputation").
>> This reputation evaluation can be fully delegated to the routing node
>> policy, without network-wise guidance.
>>
>> That said, where I'm skeptical on any reputation-heavy system is on the
>> long-term implications.
>>
>> Either, due to the wants of a subset of actors deliberately willingly to
>> trade satoshis against discounted payment flow by buying well-scored
>> pubkeys, we see the emergence of a reputation market. Thus enabling
>> reputation to be fungible to satoshis, but with now a weird "reputation"
>> token to care about.
>>
>> Or, reputation is too hard to make liquid (e.g hard to disentangle
>> pubkeys from channel ownership or export your score across routing peers)
>> and thus you now have reputation scarcity which is introducing a bias from
>> a "purer" market, where agents are only routing based on advertised fees.
>> IMO, we should strive for the more liquid Lightning market we can, as it
>> avoids bias towards past actors and thus may contain centralization
>> inertia. I'm curious about your opinion on this last point.
>>
>
> I am in favor of more liquidity and less centralization, but as far as I
> know the reality is that we don't have a good solution yet to achieve this
> without being vulnerable to DoS attacks. If those attacks would happen on a
> large scale today, what would we do?
>
> Also peers can implement these trusted upfront payments without protocol
> changes. Just stop forwarding when the prepaid forwarding budget is used up
> and require a top-up. It may have been implemented already in parts of the
> network, I don't think there is a way to know. I've experimented a bit with
> the fee model myself (
> https://twitter.com/joostjgr/status/1317546071984427009). Node operators
> don't need to wait for permission.
>
> To me it seems that the longer it takes to come up with a good anti-DoS
> system for Lightning, the further the outside world will have developed
> their trust-based systems and established that potential bias towards
> centralization.
>
> That might be another reason to prioritize this issue. Not just because we
> want the network to be safe, but also to be able to implement the preferred
> solution while the opportunity window is still open.
>
> - Joost
> _______________________________________________
> 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/20201019/93818bf0/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:01:13
in reply to nevent1q…ndsa
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:01:13Event JSON
{
"id": "a36601ed3549a225925901c57ec7f613f371a83312b56fa2a9bd7977b83acc09",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315673,
"kind": 1,
"tags": [
[
"e",
"2e5ffd65d86c5774dbb4381933898049e781bd6e8719e31c24e98ee704e67d6e",
"",
"root"
],
[
"e",
"28a782ab8ddac6378aef319becdeccfa624f4045c93f3e2e1e4275b9b7424800",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2020-10-19\n📝 Original message:\nGood morning list,\n\nI've started summarizing proposals, attacks and threat models on github [1].\nI'm hoping it will help readers get up-to-speed and avoid falling in the\nsame pitfalls we already\nfell into with previous proposals.\n\nI've kept it very high-level for now; we can add nitty-gritty technical\ndetails as we slowly\nconverge towards acceptable solutions. I have probably missed subtleties\nfrom previous proposals;\nfeel free to contribute to correct my mistakes. I have omitted for examples\nthe details of Rusty's\nprevious proposal since he mentioned a new, better one that will be\ndescribed soon.\n\nWhile doing this exercise, I couldn't find a reason why the `reverse\nupfront payment` proposal\nwould be broken (notice that I described it using a flat amount after a\ngrace period, not an amount\nbased on the time HTLCs are held). Can someone point me to the most obvious\nattacks on it?\n\nIt feels to me that its only issue is that it still allows spamming for\ndurations smaller than the\ngrace period; my gut feeling is that if we add a smaller forward direction\nupfront payment to\ncomplement it it could be a working solution.\n\nPasting it here for completeness:\n\n### Reverse upfront payment\n\nThis proposal builds on the previous one, but reverses the flow. Nodes pay\na fee for *receiving*\nHTLCs instead of *sending* them.\n\n```text\nA -----\u003e B -----\u003e C -----\u003e D\n\nB pays A to receive the HTLC.\nThen C pays B to receive the forwarded HTLC.\nThen D pays C to receive the forwarded HTLC.\n```\n\nThere must be a grace period during which no fees are paid; otherwise the\n`uncontrolled spam` attack\nallows the attacker to force all nodes in the route to pay fees while he's\nnot paying anything.\n\nThe fee cannot be the same at each hop, otherwise it's free for the\nattacker when he is at both\nends of the payment route.\n\nThis fee must increase as the HTLC travels downstream: this ensures that\nnodes that hold HTLCs\nlonger are penalized more than nodes that fail them fast, and if a node has\nto hold an HTLC for a\nlong time because it's stuck downstream, they will receive more fees than\nwhat they have to pay.\n\nThe grace period cannot be the same at each hop either, otherwise the\nattacker can force Bob to be\nthe only one to pay fees. Similarly to how we have `cltv_expiry_delta`,\nnodes must have a\n`grace_period_delta` and the `grace_period` must be bigger upstream than\ndownstream.\n\nDrawbacks:\n\n* The attacker can still lock HTLCs for the duration of the `grace_period`\nand repeat the attack\ncontinuously\n\nOpen questions:\n\n* Does the fee need to be based on the time the HTLC is held?\n* What happens when a channel closes and HTLC-timeout has to be redeemed\non-chain?\n* Can we implement this without exposing the route length to intermediate\nnodes?\n\nCheers,\nBastien\n\n[1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md\n\nLe dim. 18 oct. 2020 à 09:25, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e \u003e We've looked at all kinds of trustless payment schemes to keep users\n\u003e\u003e\n\u003e\u003e \u003e honest, but it appears that none of them is satisfactory. Maybe it is\n\u003e\u003e even\n\u003e\u003e \u003e theoretically impossible to create a scheme that is trustless and has\n\u003e\u003e all\n\u003e\u003e \u003e the properties that we're looking for. (A proof of that would also be\n\u003e\u003e\n\u003e\u003e \u003e useful information to have.)\n\u003e\u003e\n\u003e\u003e I don't think anyone has drawn yet a formal proof of this, but roughly a\n\u003e\u003e routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking\n\u003e\u003e to answer the following question \"Is this payment coming from Alice and\n\u003e\u003e going to Caroll will compensate for my resources consumption ?\". With the\n\u003e\u003e current LN system, the compensation is conditional on payment settlement\n\u003e\u003e success and both Alice and Caroll are distrusted yet discretionary on\n\u003e\u003e failure/success. Thus the underscored question is undecidable for a routing\n\u003e\u003e peer making relay decisions only on packet observation.\n\u003e\u003e\n\u003e\u003e One way to mitigate this, is to introduce statistical observation of\n\u003e\u003e sender/receiver, namely a reputation system. It can be achieved through a\n\u003e\u003e scoring system, web-of-trust, or whatever other solution with the same\n\u003e\u003e properties.\n\u003e\u003e But still it must be underscored that statistical observations are only\n\u003e\u003e probabilistic and don't provide resource consumption security to Bob, the\n\u003e\u003e routing peer, in a deterministic way. A well-scored peer may start to\n\u003e\u003e suddenly misbehave.\n\u003e\u003e\n\u003e\u003e In that sense, the efficiency evaluation of a reputation-based solution\n\u003e\u003e to deter DoS must be evaluated based based on the loss of the reputation\n\u003e\u003e bearer related to the potential damage which can be inflicted. It's just\n\u003e\u003e reputation sounds harder to compute accurately than a pure payment-based\n\u003e\u003e DoS protection system.\n\u003e\u003e\n\u003e\n\u003e I can totally see the issues and complexity of a reputation-based system.\n\u003e With 'trustless payment scheme' I meant indeed a trustless pure\n\u003e payment-based DoS protection system and the question whether such a system\n\u003e can be proven to not exist. A sender would pay an up-front amount to cover\n\u003e the maximum cost, but with the guarantee that nodes can only take a fair\n\u003e part of the deposit (based on actual lock time). Perhaps the taproot\n\u003e upgrade offers new possibilities with adaptor signatures to atomically swap\n\u003e part of the up-front payment with htlc-received-in-time-signatures from\n\u003e nodes downstream (random wild idea).\n\u003e\n\u003e\n\u003e\u003e \u003e What I can see working is a system where peers charge each other a hold\n\u003e\u003e fee\n\u003e\u003e \u003e for forwarded HTLCs based on the actual lock time (not the maximum lock\n\u003e\u003e\n\u003e\u003e \u003e time) and the htlc value. This is just for the cost of holding and\n\u003e\u003e separate\n\u003e\u003e \u003e from the routing fee that is earned when the payment settles\n\u003e\u003e\n\u003e\u003e Yes I guess any solution will work as long as it enforces an asymmetry\n\u003e\u003e between the liquidity requester and a honest routing peer. This asymmetry\n\u003e\u003e can be defined as guaranteeing that the routing peer's incoming/outgoing\n\u003e\u003e balance is always increasing, independently of payment success. Obviously\n\u003e\u003e this increase should be materialized by a payment, while minding it might\n\u003e\u003e be discounted based on requester reputation (\"pay-with-your-reputation\").\n\u003e\u003e This reputation evaluation can be fully delegated to the routing node\n\u003e\u003e policy, without network-wise guidance.\n\u003e\u003e\n\u003e\u003e That said, where I'm skeptical on any reputation-heavy system is on the\n\u003e\u003e long-term implications.\n\u003e\u003e\n\u003e\u003e Either, due to the wants of a subset of actors deliberately willingly to\n\u003e\u003e trade satoshis against discounted payment flow by buying well-scored\n\u003e\u003e pubkeys, we see the emergence of a reputation market. Thus enabling\n\u003e\u003e reputation to be fungible to satoshis, but with now a weird \"reputation\"\n\u003e\u003e token to care about.\n\u003e\u003e\n\u003e\u003e Or, reputation is too hard to make liquid (e.g hard to disentangle\n\u003e\u003e pubkeys from channel ownership or export your score across routing peers)\n\u003e\u003e and thus you now have reputation scarcity which is introducing a bias from\n\u003e\u003e a \"purer\" market, where agents are only routing based on advertised fees.\n\u003e\u003e IMO, we should strive for the more liquid Lightning market we can, as it\n\u003e\u003e avoids bias towards past actors and thus may contain centralization\n\u003e\u003e inertia. I'm curious about your opinion on this last point.\n\u003e\u003e\n\u003e\n\u003e I am in favor of more liquidity and less centralization, but as far as I\n\u003e know the reality is that we don't have a good solution yet to achieve this\n\u003e without being vulnerable to DoS attacks. If those attacks would happen on a\n\u003e large scale today, what would we do?\n\u003e\n\u003e Also peers can implement these trusted upfront payments without protocol\n\u003e changes. Just stop forwarding when the prepaid forwarding budget is used up\n\u003e and require a top-up. It may have been implemented already in parts of the\n\u003e network, I don't think there is a way to know. I've experimented a bit with\n\u003e the fee model myself (\n\u003e https://twitter.com/joostjgr/status/1317546071984427009). Node operators\n\u003e don't need to wait for permission.\n\u003e\n\u003e To me it seems that the longer it takes to come up with a good anti-DoS\n\u003e system for Lightning, the further the outside world will have developed\n\u003e their trust-based systems and established that potential bias towards\n\u003e centralization.\n\u003e\n\u003e That might be another reason to prioritize this issue. Not just because we\n\u003e want the network to be safe, but also to be able to implement the preferred\n\u003e solution while the opportunity window is still open.\n\u003e\n\u003e - Joost\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201019/93818bf0/attachment.html\u003e",
"sig": "6a0f197ef6f12ca41f2b2b983f3b3d0c92218730f85ced4fa2b6909b443918bd4d3260191b1768915f2efdaad6f9bafd9c32c696bfb332c5af712edb0dab6a6b"
}