twister username confirmation proposal

566 views
Skip to first unread message

Miguel Freitas

unread,
Jan 30, 2014, 1:40:14 PM1/30/14
to twist...@googlegroups.com
Hi people,

Ok, i've promised to some guys in twister to discuss the current idea to stop name squatting, or at least reduce it to an acceptable level.

As i've mentioned before, i don't care if somebody registers "microsoft" before the other (a little more well-known) brand owner do. He might even try to resell that name later, that's not my business either. What is plain stupid is when a single user is able to register a thousand names a day. There is absolutely no reason we should allow that.

So my current plan is to deploy an username confirmation in twister in the next few months.

Here is how it would work:

1) User registers as usual. We already have a small POW of a couple of minutes in a standard PC, but this is nothing to someone with big mining hardware. Also this is standard Bitcoin's hash, so ASIC mining makes it pretty easy to forge thousands of accounts in no time.

2) User registration would allow about two weeks of "grace period". This is good so users can start using twister right away. But within two weeks they would need to "confirm" their registration.

3) Existing users (including all name squatting) will be notified they
will need to do the confirmation as well. They will have two weeks
counting from the time the new rule is put in place.

4) Confirmation would be a really costly POW, like Scrypt-based with large memory settings, bcrypt or Dagger. My suggestion is about one or two days of computing time in a low-level PC (eg. Core 2 Duo). This is probabilistic, so it may take longer. Of course, newer hardware will be able to obtain it in less than a day.

Notes:

- Both existing and new users will have only a two-week period to produce the confirmation. Confirmation can't be pre-calculated.

- Even squatters won't have enough computer power to validate all their thousand usernames within that two week period. They will need to choose what usernames to prioritize.

- If they don't make it, the username becomes available for registration again. This time however, the registration must include the confirmation POW in order to be accepted. The difference here is that anybody will be able to take this username: the new registration+confirmation combo of expired usernames are not required to be signed by the original key owner.

- This idea still gives advantage to people with big hardware to register a lot of users. Ok, life is unfair and it's not my fault ;-) There is, however, an direct cost in leaving your computer running for a full day. There is also the indirect cost of not mining profitable Bitcoin or Litecoin with the same hardware. People will have to choose.

- A standalone multiplatform app for windows/linux will be provided to generate the POW. This way, users of mobile phones would be able to copy-paste some information into the standalone POW generator and then copy-paste back the result to their phones to complete the validation procedure.

- Service providers may offer generating this confirmation POW for money. The information shared doesn't allow them to hijack the username for themselves.

- I know Namecoin's approach tries to monetize the name registration rights. But I think a lot of people (me included) are not willing to buy bitcoin and convert them just to be able to register a name. Mining solo is probably not viable anymore, which sounds quite boring to me. So a guy who wants to speak anonymously has no other option than buying Bitcoins? Something is not right.

- I propose to introduce RPC apis to check if username is confirmed and twister UI support to notify the users even before the code is completely implemented. Also, we must allow time for people to upgrade their clients since transaction validation change could create a fork.

- The change i'm thinking is mostly backwards compatible. I just need to make a small adjust to CheckTransaction, but it can be a timed check (that only starts being enforced some time in future).

- Message to name squatters: you are wasting your time ;-)

Comments?

BTW, what hash function should we use?

regards,

Miguel

Shift rus

unread,
Jan 31, 2014, 8:32:15 AM1/31/14
to twist...@googlegroups.com
-1 but if you have a lot of hash power you can register many usernames, i think that users mast update POW+keys every 4 month

because if use your method i can once register  username and once confirm it i think that is is bad 

четверг, 30 января 2014 г., 22:40:14 UTC+4 пользователь Miguel Freitas написал:

Julien PILLON

unread,
Jan 31, 2014, 2:13:32 PM1/31/14
to twist...@googlegroups.com
Hi,
why not (just a suggestion...) use a set of captchas ? maybe with an associated POW to prevent brute-force...
With this everyone is equal, regardless the hash power.

also, as Shift rus, I think regular POH (proof of humanity ;-) ) could be a good idea.

Julien

Miguel Freitas

unread,
Jan 31, 2014, 2:29:10 PM1/31/14
to twist...@googlegroups.com
Julien,

It's is not easy to have a captcha in a distributed system like twister, although not completely impossible either.

But i realized captchas are only secure if the user can only try once for a single image. We are assuming the robot will commit errors decoding some characters, so even if the robot can decode some characters right this won't make. This is very different when the robot is able to brute force a the same captcha several times, since being able to guess a few characters right greatly reduces the effort of the attack.

In other words, even if you don't know the captcha characters but you have a fast way to check if your guess is correct (as would be needed for a distributed system like twister) then it becomes a trivial brute force exercise. Much less computation would be involved than those POW algorithms.

regards,

Miguel



--
You received this message because you are subscribed to the Google Groups "twister-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twister-dev...@googlegroups.com.
To post to this group, send email to twist...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Julien PILLON

unread,
Jan 31, 2014, 4:22:02 PM1/31/14
to twist...@googlegroups.com
Ok, got it...

The idea was to reduce the needed hash power in order to allow users with old or powerless hardware to confirm a little more easily.
I personally have only old GPUs and it could be painful... (I also have two asics, but anyway... ;-) )

As I said, this is just suggestion and reflexion...

What gave me the idea of the captchas is that Freenet (https://freenetproject.org/) uses it in order to identify the "anonymous identities". It introduces the concept of "trusters", and an account with too few trusters is unable to use the network. I dont know if it can be applyed to Twister, but I think this is interresting...

Miguel Freitas

unread,
Jan 31, 2014, 4:55:41 PM1/31/14
to twist...@googlegroups.com
Julien,

I think ideally we should use a hash function that is GPU/ASIC resistant. It seems i'm not alone in such thinking:


While the arguments hold, this specific proposal is not short of criticism by itself:


We have time to choose. Perhaps if ethereum does this competition idea a lot of projects might benefit from the results.

regards,

Miguel




--

Asher Pembroke

unread,
Jan 31, 2014, 4:57:44 PM1/31/14
to twist...@googlegroups.com
What is plain stupid is when a single user is able to register a thousand names a day. There is absolutely no reason we should allow that.

I'm a little confused - is this a technological problem or a social problem?

If it's social, then the free market should take care of it. For example, twitter could release an API that maps their user accounts to twister IDs: That way, the twister client would display @Microsoft (twitter verified) and behind the scenes deal with the twister-ID @Microsoft12oijaslkdj, which Microsoft linked it to. This would remove the market incentive to squat twister addresses.

If it's a technological problem, how about using the direct message system to slow down registration? For instance, a new user would have to send and receive a message from @twister in order to be verified, making it network-limited rather than hardware limited. I think anything we can do to keep the barrier to entry as low as possible is better.

Miguel Freitas

unread,
Jan 31, 2014, 5:23:33 PM1/31/14
to twist...@googlegroups.com
On Fri, Jan 31, 2014 at 7:57 PM, Asher Pembroke <apem...@gmail.com> wrote:
What is plain stupid is when a single user is able to register a thousand names a day. There is absolutely no reason we should allow that.

I'm a little confused - is this a technological problem or a social problem?

hehe, good question!

i think it is more of a technological problem (or limitation of the current architecture). one that can be abused due to social incentive.


If it's social, then the free market should take care of it. For example, twitter could release an API that maps their user accounts to twister IDs: That way, the twister client would display @Microsoft (twitter verified) and behind the scenes deal with the twister-ID @Microsoft12oijaslkdj, which Microsoft linked it to. This would remove the market incentive to squat twister addresses.

indeed. the less valuable the username is, the less incentive for squatters.

however with your solution we still need to rely on this central authority which verifies the accounts to map them to real entities. if we were to depend on a central authority for that, i wouldn't have even started the name registration at all: any user is free to post their bitmessage address to their Twitter account profile, right?

btw, why do you trust Twitter to tell you who Microsoft is? Is it acceptable that a central authority like that is able to selectively point you to a different mapping, so that a windows upgrade you receive (signed by Microsoft12oijaslkdj's key) could be actually a tool to spy on you?

 

If it's a technological problem, how about using the direct message system to slow down registration? For instance, a new user would have to send and receive a message from @twister in order to be verified, making it network-limited rather than hardware limited. I think anything we can do to keep the barrier to entry as low as possible is better.


what prevents the same user from sending a thousand of simultaneous requests to @twister in order to get all those verified at the same time? we can't tell that all the requests came from the same guy. delaying all registrations in bloc doesn't solve the problem.

regards,

Miguel

Asher Pembroke

unread,
Jan 31, 2014, 6:13:21 PM1/31/14
to twist...@googlegroups.com
Hey, thanks for the response!


however with your solution we still need to rely on this central authority which verifies the accounts to map them to real entities. if we were to depend on a central authority for that, i wouldn't have even started the name registration at all: any user is free to post their bitmessage address to their Twitter account profile, right?

Yeah, I don't mean to suggest that we need to rely on a particular authority - people should choose whatever plugins they want for authenticating users, whether it's twitter, bitmessage, google profiles or nothing at all. If the value of a name is in it's real-world identity, then that's something a squatter can't provide.
 
btw, why do you trust Twitter to tell you who Microsoft is? Is it acceptable that a central authority like that is able to selectively point you to a different mapping, so that a windows upgrade you receive (signed by Microsoft12oijaslkdj's key) could be actually a tool to spy on you?

I think that if Twitter still exists in 5 years, it will be because people trust them as an authority on identity. That should be their business model, and if they suck at it they deserve to fail. Twister removes all other relevancy they had ;)


what prevents the same user from sending a thousand of simultaneous requests to @twister in order to get all those verified at the same time? we can't tell that all the requests came from the same guy. delaying all registrations in bloc doesn't solve the problem.

Yeah, maybe a bad idea... but wait! Maybe it could be combined with n-of-m transactions? I was thinking that we need some way for someone to regain control over their id in case their private key gets compromised - it would be nice if I could select say 5 twister accounts, 4 of which can vote to move my address to a new public key. If this were a requirement for setting up a valid account, it might also slow down registration...?

Asher Pembroke

unread,
Jan 31, 2014, 6:52:48 PM1/31/14
to twist...@googlegroups.com
Just had a better idea from what I proposed: what if the new user needs to be validated by another user, but the two accounts have to be separated by a certain number of blocks. So a new user with no friends can still validate himself, but he would be forced to register the two accounts at different times.

Miguel Freitas

unread,
Jan 31, 2014, 7:50:48 PM1/31/14
to twist...@googlegroups.com
Asher,

On Fri, Jan 31, 2014 at 9:52 PM, Asher Pembroke <apem...@gmail.com> wrote:
Just had a better idea from what I proposed: what if the new user needs to be validated by another user, but the two accounts have to be separated by a certain number of blocks. So a new user with no friends can still validate himself, but he would be forced to register the two accounts at different times.


So now the squatter would first create a batch of 1000 users, wait a number of blocks, create the second batch of 1000 users (validated by the first batch), no? 1000 users validated. repeat for every other day.

regards,

Miguel

Asher Pembroke

unread,
Jan 31, 2014, 8:06:52 PM1/31/14
to twist...@googlegroups.com
Good point. I give up. Until next time, anyway :)

Miguel Freitas

unread,
Jan 31, 2014, 8:34:48 PM1/31/14
to twist...@googlegroups.com
On Fri, Jan 31, 2014 at 11:06 PM, Asher Pembroke <apem...@gmail.com> wrote:
Good point. I give up. Until next time, anyway :)


No, that was good food for thought ;-)

regards,

Miguel

ForFreeSpeech

unread,
Feb 1, 2014, 12:33:55 AM2/1/14
to twist...@googlegroups.com
The idea is not bad,but point 3. The reason is "No bill of attainder or ex post facto law shall be passed."
 http://en.wikipedia.org/wiki/Ex_post_facto_law  This is a common rule to make a rule.  I would register a @Microsoft_Global rather than buy it
,because the seller still keep  private key after selling username.

Julian Steinwachs

unread,
Feb 1, 2014, 4:00:37 AM2/1/14
to twist...@googlegroups.com
+1 for memory hard POW.

How much pain is it to switch POW algorithms in the protocol? Will the blockchain need to be reset?

Greetings
Tschaul

Miguel Freitas

unread,
Feb 1, 2014, 4:03:41 AM2/1/14
to twist...@googlegroups.com
On Sat, Feb 1, 2014 at 3:33 AM, ForFreeSpeech <liam...@gmail.com> wrote:
The idea is not bad,but point 3. The reason is "No bill of attainder or ex post facto law shall be passed."
 http://en.wikipedia.org/wiki/Ex_post_facto_law  This is a common rule to make a rule.  I would register a @Microsoft_Global rather than buy it
,because the seller still keep  private key after selling username.


Not really. You replace the key you bought for a new one, then the seller can't use it anymore.

regards,

Miguel

Miguel Freitas

unread,
Feb 1, 2014, 4:07:44 AM2/1/14
to twist...@googlegroups.com
On Sat, Feb 1, 2014 at 7:00 AM, Julian Steinwachs <julian.s...@fau.de> wrote:
+1 for memory hard POW.


Very interesting POW proposal:

 
How much pain is it to switch POW algorithms in the protocol? Will the blockchain need to be reset?


It is far for being trivial, but i think a well planned deployment is possible without too much hassle.

regards,

Miguel

Klaus Alexander Seistrup

unread,
Feb 2, 2014, 12:50:44 PM2/2/14
to twist...@googlegroups.com
While I don't approve of mass registering of usernames, the way we are experiencing it, I don't like the idea of having to do a massive POW after the original registration.

I have registered a handful of usernames.  One is for the daily use, the others are for various “services” (@soltempore is one, I do not wish to disclose the others, but think of them as RSS/Atom→Twister) that will be posted to from scripts.  My Twister node is running on old hardware that is running other services besides Twister.  I do not wish to use 100% CPU for a day to “confirm” each of those usernames.  Or what if I have to go on vacation when this second registration takes place?  Will I come home and find my username is gone?  No, I simply find that “solution” unacceptable.

(And I'm sorry to add that I do not currently have a suggestion for an acceptable solution to the problem.)

Karl Yeager

unread,
Feb 6, 2014, 3:20:31 PM2/6/14
to twist...@googlegroups.com

Very new but concerned about the Post registration process.  Can the algorithms be configured in a way that they would adjust according to processor base of the applying user?  For example both the Dual-Quad Xeon and Atom would finish processing at the same time.  Let us say the process is set for a 4 hour run time  This would be long enough to be inconvenient for mass registration but not too long for base users to register two or three IDs for personal, business or other use.

kungfoo

unread,
Feb 7, 2014, 11:11:14 AM2/7/14
to twist...@googlegroups.com
Since the username maps to the name entered into your profile and your private key maps to your username, why do we need a username registered at all?  Surely I can generate a private/public key pair to represent myself, just like bitcoin; and my identity is verified by signing my messages with my private key.

胡金宝

unread,
Feb 7, 2014, 9:28:50 PM2/7/14
to twist...@googlegroups.com
If i got a vote i would say, setting barrier for registering is good thing ,but it's better not affect existing users. First ,that may increase unnecessary complexity of design. Second there maybe only 3 or 5 squatters but 300 or 500 users who registered some tens of usernames by hand,they are happy to get good names. They got them because they come to support twister at early stage ,they deserve that.So, hope you think about thoses people.


在 2014年1月31日星期五UTC+8上午2时40分14秒,Miguel Freitas写道:

Paweł Kosiński

unread,
Feb 8, 2014, 10:28:27 AM2/8/14
to twist...@googlegroups.com
Possible and easy to exploit. People can simply claim that they are using 20
MHz CPUs and registering nicknames fast anyway. Unless you have a way to check
through network, in an anonymous way, that people are really using the hardware
they are claiming to use.

Raphael Lydia Bertoche

unread,
Feb 10, 2014, 11:45:38 AM2/10/14
to twist...@googlegroups.com
On 7 February 2014 14:11, kungfoo <amt...@gmail.com> wrote:
why do we need a username registered at all?

This in fact is an important feature of twister. With public keys instead of usernames, there would'nt be a uniquely identified name. Even if you know your friends by public key, that wouldn't stop someone from impersonating you to people that somehow never got your key. He would just enter exactly the same name as you with another public key.
I don't think social network users want to be known by some key - that is hard to speak, read or remember - and force each follower to check or copy-paste a key before adding them to his feed.

But that's not why people are concerned about name squatting. The major reason is about needlessly increasing twister's block, adding even network payload.

Raphael
(21) 9162 5605
(21) 3527 2253

Raphael Lydia Bertoche

unread,
Feb 10, 2014, 12:08:12 PM2/10/14
to twister-dev
The problem is, there is no way to tell those usernames from name squatted. They're just hanging unused names.

But there won't be really a timeout for that usernames, as you can always reregister them and run this POW, unless someone else that hates you a lot does it.

Raphael
(21) 9162 5605
(21) 3527 2253


--
You received this message because you are subscribed to a topic in the Google Groups "twister-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/twister-dev/dMc82UrD40I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to twister-dev...@googlegroups.com.

kungfoo

unread,
Feb 11, 2014, 9:44:42 AM2/11/14
to twist...@googlegroups.com, rber...@cpti.cetuc.puc-rio.br


On Monday, 10 February 2014 16:45:38 UTC, Raphael Lydia Bertoche wrote:
This in fact is an important feature of twister. With public keys instead of usernames, there would'nt be a uniquely identified name.

Yes there would, it would be a private key, which is just another string of chars like the username...
 
Even if you know your friends by public key, that wouldn't stop someone from impersonating you to people that somehow never got your key. He would just enter exactly the same name as you with another public key.

Replace the word key with username and you have the same problem.  If I don't know someone's registered key/username how can I verify their identity?

I don't think social network users want to be known by some key - that is hard to speak, read or remember - and force each follower to check or copy-paste a key before adding them to his feed.

The reason for twister is privacy and encryption, so having some kind of socially meaningful username is possibly contrary to this aim.


But that's not why people are concerned about name squatting. The major reason is about needlessly increasing twister's block, adding even network payload.

 
And removing the need for socially meaningful usernames solves that problem in an easy, simple way.

kungfoo

unread,
Feb 12, 2014, 6:41:55 AM2/12/14
to twist...@googlegroups.com, rber...@cpti.cetuc.puc-rio.br

On Tuesday, 11 February 2014 14:44:42 UTC, kungfoo wrote:
 
Yes there would, it would be a private key, which is just another string of chars like the username...
 
 
That should read 'public key', not 'private key'... 

Miguel Freitas

unread,
Feb 13, 2014, 5:45:09 AM2/13/14
to twist...@googlegroups.com
Karl, Kungfoo, Raphael and all,

I have just returned from vacations and it will take me a while to got
through all emails in my inbox... I just wanted to say that yes, it is
fine to have the confirmation process set for, let's say, 4 hours
instead of a day. And i don't want to punish anyone who registered
(for example) two, three or ten usernames. The idea of having this
discussing is to gather feedback and if the idea is to be implemented
it is important to properly adjust the parameters.

I had a good talk to Cuckoo's author John Tromp and I'm willing to
give it a try. It is a very cleverly designed POW which tries to be
based on main memory latency (instead of local processor cache). Of
course that doesn't make a Atom netbook to be equal to a high-end Core
I7, but it might make their different somewhat smaller.

No hurry, we have time. I'm considering we could release a
confirmation "generator" before it is implemented as a requirement in
twister so we may try how it performs on different platforms.

regards,

Miguel

Сёма Мрачный

unread,
Apr 23, 2014, 8:05:09 AM4/23/14
to twist...@googlegroups.com

Hi people,
hi.
 
Ok, i've promised to some guys in twister to discuss the current idea to stop name squatting, or at least reduce it to an acceptable level.
which level will acceptable for you? and for another persons?

2) User registration would allow about two weeks of "grace period". This is good so users can start using twister right away. But within two weeks they would need to "confirm" their registration.
otherwise registration discards. it means some cancellation procedure for already existing names — does it means that Twister not so much safe for use if this procedure exists?

4) Confirmation would be a really costly POW, like Scrypt-based with large memory settings, bcrypt or Dagger. My suggestion is about one or two days of computing time in a low-level PC (eg. Core 2 Duo).
I don't have even that Core 2 Duo. industry standards grows too faster for me and I think not only for me. but some guys have ASICs meanwhile.

- This idea still gives advantage to people with big hardware to register a lot of users. Ok, life is unfair and it's not my fault ;-)
then what is it all?

- A standalone multiplatform app for windows/linux will be provided to generate the POW. This way, users of mobile phones would be able to copy-paste some information into the standalone POW generator and then copy-paste back the result to their phones to complete the validation procedure.
it will not to contribute to the popularity.

Erkan Yilmaz

unread,
Jun 2, 2014, 6:16:09 AM6/2/14
to twist...@googlegroups.com
to the twister community,

how about reviving this discussion ?

just put feedback about username grabbing to: 

@erkan_yilmaz


On Thursday, January 30, 2014 7:40:14 PM UTC+1, Miguel Freitas wrote:
Hi people,

Ok, i've promised to some guys in twister to discuss the current idea to stop name squatting, or at least reduce it to an acceptable level.

As i've mentioned before, i don't care if somebody registers "microsoft" before the other (a little more well-known) brand owner do. He might even try to resell that name later, that's not my business either. What is plain stupid is when a single user is able to register a thousand names a day. There is absolutely no reason we should allow that.

So my current plan is to deploy an username confirmation in twister in the next few months.

Here is how it would work:

1) User registers as usual. We already have a small POW of a couple of minutes in a standard PC, but this is nothing to someone with big mining hardware. Also this is standard Bitcoin's hash, so ASIC mining makes it pretty easy to forge thousands of accounts in no time.

2) User registration would allow about two weeks of "grace period". This is good so users can start using twister right away. But within two weeks they would need to "confirm" their registration.

3) Existing users (including all name squatting) will be notified they
will need to do the confirmation as well. They will have two weeks
counting from the time the new rule is put in place.

4) Confirmation would be a really costly POW, like Scrypt-based with large memory settings, bcrypt or Dagger. My suggestion is about one or two days of computing time in a low-level PC (eg. Core 2 Duo). This is probabilistic, so it may take longer. Of course, newer hardware will be able to obtain it in less than a day.

Notes:

- Both existing and new users will have only a two-week period to produce the confirmation. Confirmation can't be pre-calculated.

- Even squatters won't have enough computer power to validate all their thousand usernames within that two week period. They will need to choose what usernames to prioritize.

- If they don't make it, the username becomes available for registration again. This time however, the registration must include the confirmation POW in order to be accepted. The difference here is that anybody will be able to take this username: the new registration+confirmation combo of expired usernames are not required to be signed by the original key owner.

- This idea still gives advantage to people with big hardware to register a lot of users. Ok, life is unfair and it's not my fault ;-) There is, however, an direct cost in leaving your computer running for a full day. There is also the indirect cost of not mining profitable Bitcoin or Litecoin with the same hardware. People will have to choose.

- A standalone multiplatform app for windows/linux will be provided to generate the POW. This way, users of mobile phones would be able to copy-paste some information into the standalone POW generator and then copy-paste back the result to their phones to complete the validation procedure.

Reply all
Reply to author
Forward
0 new messages