Denial of service resistance #1440
Replies: 6 comments 1 reply
-
Since we have a blinded mint there are some interesting solutions to Sybil attacks. Obviously the most simple is for the federation or gateway to charge ecash fees, but that is a problem if the user doesn't yet have any bitcoin or ecash and needs to receive over LN. We could issue blinded "reputation tokens" for users that can prove they are not a Sybil attacker when receiving over LN for the first time:
Hashcash probably won't work, especially for mobile devices. I can trivially generate millions of equivalent hashcash tokens spending $100 in AWS compared to a mobile phone. Proof-of-bandwidth or proof-of-storage might fare slightly better. We could do that by requiring the user to download a large number of unique nonces from the federation then require them to prove they are storing a number of them. ^ for reference copied from #801 (comment) |
Beta Was this translation helpful? Give feedback.
-
The federation should not allow more than 9 tokens of a given denominations. So a user can't just attempt to verify 10k 1msat tokens. Not sure if this is the case currently. |
Beta Was this translation helpful? Give feedback.
-
@waxwing mentioned https://privacypass.github.io/ in his recent ecash talk |
Beta Was this translation helpful? Give feedback.
-
Currently we don't check this server-side, although we may want to allow more than 9 tokens per denomination for privacy reasons. DoS attacks could always spam multiple txs anyway. Better to charge fees or reputation tokens when spam is high. |
Beta Was this translation helpful? Give feedback.
-
Consolidation of #801:
|
Beta Was this translation helpful? Give feedback.
-
As pointed out by @justinmoon on a call recently our highest priority should be protecting against DoS by malicious users, malicious guardians are a separate topic. There also isn't a perfect anti-DoS solution and we'll have to adapt. These two points lead me to the conclusion that we should build DoS protection on the API level of each guardian and ideally not bake it into To achieve that goal guardians could issue single-sig e-cash that's far more efficient to generate and validate. The architecture I'm contemplating would consist of three services:
This architecture allows us to remove/add ways of acquiring these anti-DoS-tokens without touching EDIT: I think this architecture isn't novel, I remember this being discussed for Tor a while ago, maybe @oleonardolima knows what they ended up with. EDIT 2: For the light-weight, single-sig e-cash we could likely use Ruben Somsen's scheme also used in Cashu https://github.com/cashubtc/nuts/blob/main/00.md#protocol |
Beta Was this translation helpful? Give feedback.
-
We've had some discussions on the dev calls recently about denial of service attacks. Here is an issue to track these discussions.
Relevant comment from @jkitman recently: #801 (comment)
Related issues:
ReconnectPeerConnections
message cache on extended network interruption #229Beta Was this translation helpful? Give feedback.
All reactions