Replies: 7 comments 9 replies
-
|
I can see why some federations might want to limit the user accounts in general, but using account tracking as a way to limit abusable APIs seem like a shortcut that extremely damages the privacy preserving properties of ecash. |
Beta Was this translation helpful? Give feedback.
-
I'd say that it's much less damaging than not using Tor. It's also orthogonal to all other anti-abuse mechanism. We might need it anyway, even if just for invite-only Federations. |
Beta Was this translation helpful? Give feedback.
-
That's not entirely clear to me. On most internet connections you IP changes regularly, which means your transactions today will likely not be correlated with the ones from tomorrow. If you were to present the same user account key both times, both transactions are easily correlated and e-cash won't help at all (it's whole purpose is breaking the link between transactions). Also, @oleonardolima is working on adding Tor support. |
Beta Was this translation helpful? Give feedback.
-
|
As commented on #1440 (comment), introducing the payment of fees seems to be a solution for 99% of the problems. The idea is very simple: just follow bitcoin model and introduce a "mempool" where transactions are sorted and processed according to the fee contained in the transaction. But what about people that don't have any cash? This a problem that could be solved in multiple creative ways. The trivial solution is just to consider a zero fee transaction something valid but that will only be processed if the federation is idle (i.e mempool is empty of transactions paying fees). This also allow us to migrate the consensus in a backwards compatible way: older clients that don't understand fees will be paying zero fees and will have their transaction delayed if the federation is very busy, encouraging them to uprade to a newer client version. Another complementary solution to above is just to sell invite codes in some to-be-specified protocol. So any client joining the federation will necessarily have some ecash. |
Beta Was this translation helpful? Give feedback.
-
This helps only with transactions, have same problems as Bitcoin's mempool (see never-ending whining about transactions being too expensive and long confirmation times), usability is meh, and also introduces profit for Federation which might make their regulatory status more difficult. |
Beta Was this translation helpful? Give feedback.
-
Fees can be paid to any operation on the federation
This is good because it keeps the federation working while the free market adjusts and people move from overloaded federations to idle ones.
I think it can be fine
Many federation will be for-profit and if the federation want to be DDoS then the fees can be disabled :) |
Beta Was this translation helpful? Give feedback.
-
|
I have a strong preference towards fees (when possible) to solve it instead of something account based or degraded service-like. If something like that were to be introduced, instead of account based, issuing a bulk of blind signed authorization tokens and distributing them one way or another could help. Some reasonable number that normal users won't hit. Or give a variety of them for different purposes. Such as a few 'audit tokens' when you receive a big amount, or a bunch of 'lightning-locked token requests' when you join a federation. And these tokens can be increased as fees are paid to the federation. A rough idea that I don't necessary endorse but I'm in the process of adding blinded authorization tokens myself and would suggest something not privacy-damaging being added to federations by way of accounts. |
Beta Was this translation helpful? Give feedback.
-
The biggest problem with fees was that it introduces... well... profit, turning Federation into semi-business. In cases where this is possible it solves a lot of problems, sure. |
Beta Was this translation helpful? Give feedback.
-
it's inevitable, really, imo |
Beta Was this translation helpful? Give feedback.
-
|
What if the fees are burned? It may be an option for the federation to stay as a nonprofit. |
Beta Was this translation helpful? Give feedback.
-
|
So there's basically three options then?
|
Beta Was this translation helpful? Give feedback.
-
|
This seems like vague and inaccurate descriptions. General anti-abuse techniques proposed so far that I remember:
Each has it's own pros and cons. BTW. I believe there might be more spins to the account/rate-limits like e.g. ring signatures that would improve the privacy loss. So far:
was I was able to come up with. |
Beta Was this translation helpful? Give feedback.
-
|
Related discussion #1440 |
Beta Was this translation helpful? Give feedback.
-
|
I posted some thoughts on DoS protection in the original discussion. Accounts kill privacy, so are far from an ideal solution imo. #1440 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@elsirion This only takes care of consensus. It doesn't help with non-consensus endpoints, backups, detecting if client joined federation before and invite-only Federations. "User accounts" specifically does not deal with consensus rate limiting. So these two are complementary. Submitting consensus items could not require rate limiting per-account, use "usage tokens" instead, thus stay as private as before, so peers can't possibly use them to link payments. But other APIs (in particular backups) could use these and we can evaluated privacy aspects per-call. E.g. requiring account signature for fetching block history or uploading backup does not really compromise privacy. Seems to me that people see "account" and seems to think that all privacy has disappeared, while it's not the case and the whole thing is more nuanced. Maybe I should have used more sneaky name for the whole thing. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not opposed to an account-based approach for these data storage APIs, but it's not the most pressing issue imo: if we globally rate-limit e.g. backups to not take more than x GB of space and the storage is full the happy path will still work for users and only recovery from backup will be impacted, which isn't something that causes a lot of pain => not an attractive target for attacks. Protecting tx processing seems way more important and there accounts just don't work. |
Beta Was this translation helpful? Give feedback.
-
Multiple problems I've been thinking about, but in particular #4289 recently, are making me think that Federations need pseudonymous user accounts.
It's just really hard to protect Federation from the abuse if all users are indistinguishable, unaccountable and can be created at will.
As things are currently, without Tor, the normal users can kind-of identifiable by their IP addresses anyway, and it doesn't seem to bother anyone all that much.
After all ecash notes are unlikeable anyway. Also - given that users can use OOB transfers, not every transaction even needs to go through the mint anyway, and amounts paid can be faked be reissuing extra notes / split the remint, etc.
Guardians would gain an ability to control the amount of users and also ability to keep Federation private (for friends and family). Account keys could be leaked/shared, but that use would count towards the quota for a given account, so damage would be limited.
Rate limiting can be done individually per-peer, so it doesn't touch the consensus. Malicious peer could not enforce rate limits, but that can be detected and malicious peer can be held accountable.
Federations (peers) could keep a quotas for "unregistered" users if they desire. Client would only need to present the registered account signature if the Federation is hitting the limits for unregistered accounts (is possibly being abused or invite-only by choice). If a Federation is abused quota would limit the damage while allowing registered users to continue to use Federation.
The users could submit txes to one random peer, and honest peers would not keep the any association of submitted transactions. So unless peers collude and it would be hard to link all the actions of one account together.
Accounts could be registered with each guardian individually to avoid touching the consensus at all (better privacy for everyone). For each guardian a client could appear as a different ID altogether for better privacy.
An invitation to a Federation would contain one time use invitation codes for each peer.
By tracking accounts Federation could reliably tell user if they ever joined given Federation before, so recoveries would be reliable. Similar with backups - thanks to limiting number of users these would become somewhat reliable and predictable.
Beta Was this translation helpful? Give feedback.
All reactions