Multiple updates of the same name in a single block

[domob]

I somehow have the vague impression that it is not valid to update / "touch" the same name multiple times in a single block. However, I can not find the corresponding check in the code right now. Does anyone know about this? Maybe I'm just confused and this rule doesn't exist at all.

[phelix]

I somehow have the vague impression that it is not valid to update / "touch" the same name multiple times in a single block. However, I can not find the corresponding check in the code right now. Does anyone know about this? Maybe I'm just confused and this rule doesn't exist at all.

It is not be possible to use the same input twice

Or do you mean something else?

[domob]

Of course. It is also not possible for two people to "firstupdate" the same name - but what I'm unsure about is whether you can update one name twice in a single block (with chained transactions). Of course, the client doesn't allow it due to the "there are pending operations on this name" thing. But at the moment it looks like this is only a front-end check and no block validation rule ... or if it is, I'm missing the check.

Not a big deal and no security problem, but I just wanted to check because I really thought it was there.

[biolizard89]

Of course. It is also not possible for two people to "firstupdate" the same name - but what I'm unsure about is whether you can update one name twice in a single block (with chained transactions). Of course, the client doesn't allow it due to the "there are pending operations on this name" thing. But at the moment it looks like this is only a front-end check and no block validation rule ... or if it is, I'm missing the check.

Not a big deal and no security problem, but I just wanted to check because I really thought it was there.

I don't see any reason to block such usage anyway; it would prevent 10 minutes of downtime if someone accidentally issued a name operation that messed up their domain. I never understood why the client blocks it by default; there's no security risk from double-spending your own name, so waiting for a confirmation seems redundant.

[signup292]

.

[cassini]

Not a big deal and no security problem,

Looks like you've just discovered a method for creating a blockchain fork!
Bitcoin has already seen a similar situation in the past: the March 2012 chain fork. 0.7.x miners and 0.8.x miners handled one of the blocks differently. In that case it was triggered by a db software problem in combination with the large block size. However, it could have easily been a malformed transaction or similar if the mining pools' software versions react in different ways.
Imagine one of the big NMC mining pools runs a BDB and another pool runs a LevelDB namecoin client. Then someone issues several name_update transactions on a name during one block (using a tweaked namecoind).
One of the DB variants may not be happy with this block for some reason (e.g. different sorting algorithm), and we are in for a major blockchain disaster.

[domob]

Not a big deal and no security problem,

Looks like you've just discovered a method for creating a blockchain fork!
Bitcoin has already seen a similar situation in the past: the March 2012 chain fork. 0.7.x miners and 0.8.x miners handled one of the blocks differently. In that case it was triggered by a db software problem in combination with the large block size. However, it could have easily been a malformed transaction or similar if the mining pools' software versions react in different ways.
Imagine one of the big NMC mining pools runs a BDB and another pool runs a LevelDB namecoin client. Then someone issues several name_update transactions on a name during one block (using a tweaked namecoind).
One of the DB variants may not be happy with this block for some reason (e.g. different sorting algorithm), and we are in for a major blockchain disaster.

I don't think this is a big problem. It is already now possible to spend the same "coin" multiple times, and the DB doesn't have a problem with it. I see no reason why it could be different if the same name is updated multiple times. (However, of course the March 2013 problem could occur also in Namecoin if we had a LevelDB miner. But that's not related to the question here. BTW, for Huntercoin, the BDB lock limit was already reached in the past and we increased it together with another fork.)

So it seems that there's indeed no such hard condition, thanks for the clarification!