Possible attack vector - mass username registration

This could perhaps be a dastardly plan: Automate the process of registering new usernames on the network and register all available names up to say 10 characters (or perhaps all dictionary words, one or in combination up to a certain character length for ’simplicity’). Pretty user unfriendly for everyone else at that point right?!

Plus the person/entity which did that would be able to hold the network to ransom just like people currently do by parking domain names.

Possible (although not perhaps desirable) answer is charging for registering a username with Safecoin. Another answer perhaps is to only allow users who also own vaults above a certain rank the permission to register a username (if indeed that is how users/vaults are linked if that makes sense). That would be an inherent cost of contributing to the network to stop this sort of mass name registration.

Knowing you guys this has already been addressed in some ways but just thought I’d mention it in case not :slight_smile:


A way to prevent this attack is by a “spam filter” in the sentinel module, or maybe in routing.
For example, don’t allow more than X “free operations”(without safecoin cost) per minute.

I saw the same problem when I read the “Self authentication” paper, on the point “A. Creation of an Account” a user can Put credentials without restrictions. Then I thought it’ll be necessary in the future, a kind of “garbage filter”


As for login credentials, it’s uniqueness from the point of view of the network is dependent on Username, PIN and Password combined. You and I can both use the login username “Seneca” just fine, as long as our PIN and/or Password are different we will get different passports (which contain our actual network identities). The network doesn’t even receive our username (nor PIN or password), they stay local.

As I understand it, the public name registration mechanism is a separate system from logging in. Some sort of system preventing mass registration is definitely needed there. There was a thread about it a long time ago, including solutions, I’ll see if I can find it.


But you could still open a very large number of accounts and get round the spam filter restrictions that way it would seem with this fix.

In short: Additional characters (up to 6 it seems) can be used to discern two duplicate ID’s. It’s not perfect but probably the best solution in a fully decentralized system.

1 Like

So there can be duplicate ID’s on the network because of the vastness of xor space they’re mapped on, and an additional ‘up to 6 character’ string can be used to distinguish between duplicate ID’s. Is that what this is or am I missing something?

1 Like

The username, password, pin combination added with salt will give a totally different id to the network. For this to work you would have to guess everyone’s username password and pin in multiple variations

Yes, you’re right. I mean that you can Put a lot of garbage into the net creating requests of “Create account” with random credentials.

The username / pin / password stay in local for a short time. Only for hash them and get the “access packet” from the net.

1 Like

And of course if you could do that you could just take people’s data directly

1 Like

I see, that’s true. I suppose your close group could just reject multiple account creation requests, so you’d have to reconnect with either a different IP address or to a different close group. At the same time, I’m not even sure the network discerns PUTs for account creation from PUTs for any other data.

Actually, I think it doesn’t. If so, account creation costs SafeCoin like any other PUT, which solves this problem, but then it has to be possible to farm and earn SafeCoin without creating an account. Well, that should be possible as well I think, though preserving farmed SafeCoins without creating an account when you shut the vault down would require local storage of at least one private key.

There are many ways to clean this up, it is similar to being able to create millions of bitcoin private keys (from security standpoint) and try to match a keypair of existing user and or creating millions of registered blocks on the blockchain at a cost of a tx fee per ‘account’. For us though we can clean these up in many ways, ultimately though we archive them as they become ‘dead’ and pull from archive if they log in.


Why not have a requirement that a new ID be linked, within a certain amount of time say 24 hours, to either a vault which gives at least X amount of storage OR a certain amount of safecoin OR a certain amount of Data stored (which the party had to pay for)


This is valid and a consideration. If logged out the worst effect is a user has to re create an account. There are several ways to achieve clean up.


Yeah, it could even be done on logout. Because really if you haven’t connected a vault, transferred safecoin into an associated address, or PUT data under this ID, what purpose does it serve? And if it goes away, then you haven’t lost anything except the ability to spam the network.

Edit: Particularly because you can have multiple identical public IDs.

I’m thinking the simplest way to do this would be to somehow include the associated Vault ID, safecoin address+balance, or PUT datamap into the ID hash. If an ID doesn’t have at least one of these, it will not have a valid hash, and therefore on logout, will simply go away.


So could this confuse a new user do you think? They are like oh I’ve heard about this I’ll check it out. They download the client but don’t contribute anything cause they just want to browse and aren’t committed to it yet. Then when they come back they put in their credentials and are told they have been taken or lost? I think this idea is essential don’t get me wrong but if something like this is implemented I think the confusion it could cause to a network newbie should be averted with a “just looking to browse? Check out our Firefox extension!” Or something of the like. Am I wrong here?


Well that’s why it’s so convenient that you can have multiple public IDs with the same exact name. There is just an extension the system adds to tell them apart.

I see your point I think but all I’m saying is people are lazy (won’t want to sign up again or come up with a new password for instance) so will this drive them away? I could see someone saying well then they shouldn’t bother since they’re so lazy but if they end up contributing a node then the network just got more secure and maybe they’ll tell a buddy so. I get the technical point but a network newbie will just be annoyed. If it seems I’m missing something please feel free to elaborate

Why would they need a new password?

If the ID file is deleted, then they can use the same ID (because there can be more than one of that ID), and they can use the same PIN and password.

Because there IS no file with that ID, PIN and Password.

Its a little different because we associate a permanent record, when you create an ID on a server. But the whole point of this is that these things are nothing more than files on the network. That is why, spamming, creating millions would allow you to harm the network. But in turn if that file is deleted, thats it. Its like you never logged on.

With a proper UI interface, a genuine newbie who doesn’t know what is going on can just easily create the same login.


note that you do not need to (self-)authenticate to browse public data; the keys are publicly available


In the past, we talked about different account modes on this thread below.

It might be easier to simplify a little more. Instead of having account (creation + activation), maybe we just have account (creation).

No Login Required (Public GET functionality)

  • Unlimited browsing/download of public data.
  • Cannot PUT data onto the Network.

Create Account (Public and Private GET functionality w/ PUT)

  • Acquire Safecoin wallet address.
  • Can PUT data onto the Network.

I think it’s already set up this way? I just wanted to make sure we are on the same page. When a new user runs the client, they are in “public browse mode” by default, otherwise they login to their account to enable PUT functionality. This could reduce a large amount of account creations from people who just want to try the Network.

The original reason for (creation + activation) was to prevent users abusing free storage. But we are no longer doing free storage, so it is not needed, right?