name_new and name_firstupdate - race against squatters

Post Reply
Posts: 6
Joined: Sun Mar 15, 2015 3:29 pm

name_new and name_firstupdate - race against squatters

Post by ASZ »


I have a question for the Namecoin developers team (if anyone else knows the answer => feel free to post, though I would ask one of the developers to confirm):

The description of the name registration process is rather vague in the official namecoin wiki ( ... it_Domains). Some of the information in vinceds post needs some explaining too imho (

A name_new operation of the name "d/example" (used for examplary purposes. I know it has already been registered) broadcasts the encrypted version of the name for security reasons.

The next step is to perform a name_firstupdate operation. Now that's where the questioning starts:
Why do I have to wait for 12 Blocks? Vinced writes the following:
There is a mandatory 12 block wait that gives you enough time to broadcast your name with first_update, reducing the chance that someone will get in a first_update ahead of you.
In order to better understand the process flow, I would like to ask for clarification of the outcome of the following Scenario:

1) Block 0: Bob performs name_new for the name "d/bob"
2) Block 6: Alice decides to acquire the name "d/bob" too and performs a name_new operation too.
3) Block 12: Since the Namecoin wiki says to wait for 12 Blocks, Bob has not yet performed a name_firstupdate. By this time, his first transaction has at least 12 confirmations. Unfortunately, Bob forgets about Namecoin and does NOT perform name_firstupdate on time.
4) Block 18: Now 12 Blocks have passed since Alice called the name_new operation, i.e. her first transaction has been confirmed 12 times. Alice now calls name_firstupdate. WHAT HAPPENS?
5) Block 20 : Bob remembers about his Namecoin name and performs a name_firstupdate too. WHAT HAPPENS?

Who will "win" the race and receive the name?

Now, there have been explanations in various papers on what happens if multiple nodes happen to broadcast a name registration for the same block => decided by "luck". But does this still apply to the situation, when one of the users forgets to perform a name_firstupdate on

Thanks in Advance,


Posts: 12
Joined: Fri Apr 17, 2015 5:40 pm
os: linux

Re: name_new and name_firstupdate - race against squatters

Post by kresp0 »

Good question.

Not a developer, but I think that Alice should win.

Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am

Re: name_new and name_firstupdate - race against squatters

Post by domob »

It depends on which of the name_firstupdate transactions gets confirmed first by a miner. In your scenario, this is not 100% defined - but it will most probably be Alice because she sent the registration earlier. (It is probably already confirmed by the time Bob sends his name_firstupdate. But even if that's not the case, nodes that know already about Alice' transaction will, by default behaviour, refuse to relay Bob's registration, IIRC.)

Note that your scenario is somewhat a "worst case" one and one that will not happen "against squatters". That's the whole point of name_new - unless Alice decides on her own purely by chance at almost the same time as Bob that she wants the name, she can't broadcast her name_new already at block 6. Usually, she would only know about the name once Bob sends his name_firstupdate already. At that point, it is (most probably) too late for Alice unless Bob gets really unlucky and does not get a confirmation within 12 blocks.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
Use your Namecoin identity as OpenID:

Post Reply