Genesis block not in blkindex

[domob]

While working on the UTXO patch, I noticed that Namecoin doesn't store the genesis block's coinbase transaction (41c62dbd9068c89a449525e3cd5ac61b20ece28c3c38b3f35b2161f0e6d3cb0d) in the transaction index in blkindex.dat. This presumably prevents the coins from this transaction to be ever spent (not that they would be like to be spent). (You can observe this behaviour by querying getrawtransaction or the block explorer for this txid.)

Mikhail fixed this in Huntercoin by adding

Code: Select all

CTxDB txdb;
if (!block.ConnectBlock(txdb, pindexGenesisBlock))
  return error("LoadBlockIndex() : genesis block not accepted");

to the end of LoadBlockIndex() in main.cpp. I've not checked the Bitcoin source, since the DB has been rewritten there anyway.

Do we want to fix this, or keep the genesis block transaction out of the transaction index? Fixing it would surely be cleaner and could be done relatively simply (by the lines above). I would also include some logic into the patch to add the transaction to an existing blkindex.dat file, so that not everyone needs to redownload the blockchain.

The only risk associated is that of a hardfork if these coins should ever be spent, which seems very unlikely (unless ECDSA is broken). Also, the patch should make sure no problem occurs even then - and if we don't fix it, the risk remains that some future update does fix the odd behaviour accidentally and thus creates a hardfork without us planning it.

[virtual_master]

Good question.
I would say we should choose the highest utility for the lowest risk solution.
If Vinced implemented the genesis block as unspendable then maybe he doesn't want to spend it or maybe it has even some reason.
Are by Bitcoin the genesis block coins spendable ?
------------
My opinion is that we shouldn't make hardfork in vane, only if it is really necessary.
Some possibilities as I see:
- Put a commentary in the code(no hardfork is necessary for this) where the replacement would come.
Something like: 'NOT to be changed - genesisblock coins unspendable', then an accidentally fork is avoided.
- If they are serious arguments to change it than maybe we should make more changes at once, like fixing the 0.5K limit to the intended 1K limit and change the name expiration period depending of the name length.

[domob]

Of course, I do not know what Vinced thought about it or whether or not the same was present in Bitcoin 0.3 and was changed since then. (We could look this up in the code history, but I'm too lazy right now.) But honestly, to me it looks like an oversight / bug. From my understanding, blkindex.dat "should" contain an index to look up every transaction existing, and thus it is simply wrong that it misses this transaction (which exists in the blockchain but not the index). If it would be intentional to make the genesis block unspendable, it should have been implemented in a much clearer way and not via leaving out this one transaction from the index. (I. e., an explicit check in ConnectInputs that the input is not from the genesis block.)

I think we should include the transaction into the index in any case. My personal opinion is to also make the coins spendable, since this seems "correct", would not require additional ad-hoc rules and even if clients do not upgrade, it would only cause a fork if the coins would actually be spent by Vinced. I think the risk is minimal that this happens before nodes in the network upgrade.

If the community really wants to avoid also this tiny risk of a hard fork, I can explicitly add a check that ensures that the genesis block output is unspendable even when it is in the index. Please let me know which way we should go, and I will create a patch.

[virtual_master]

Hmmm.
Not spending the coins of the genesisblock could have very well sense especially when the creator is unknown and wants to keep the possibility to come back and identify himself with the genesisblock signature. Not exposing the private key makes it secure even in 20 years against cryptanalytic attacks when quantum computers would come out.
Of course after signing with the private key he could also spend the coins. Self-discipline would work also but having them unspendable is an additional security layer to not accidentally expose the key.
I think to protect Vinced's identity if he wants to come back to the community is more important than the 50 NMC for the genesisblock.
Protecting the crypto-identity of the Namecoin creator would be also important to protect the network against unwanted influence.
A cleaner unspendable protection for the genesisblock coins as you suggested would be more desirable from this point of view.

[domob]

Hmmm.
Not spending the coins of the genesisblock could have very well sense especially when the creator is unknown and wants to keep the possibility to come back and identify himself with the genesisblock signature. Not exposing the private key makes it secure even in 20 years against cryptanalytic attacks when quantum computers would come out.
Of course after signing with the private key he could also spend the coins. Self-discipline would work also but having them unspendable is an additional security layer to not accidentally expose the key.
I think to protect Vinced's identity if he wants to come back to the community is more important than the 50 NMC for the genesisblock.
Protecting the crypto-identity of the Namecoin creator would be also important to protect the network against unwanted influence.
A cleaner unspendable protection for the genesisblock coins as you suggested would be more desirable from this point of view.

I understand your concerns here and fully agree, but they are not applicable. As far as I can tell from the code, the transaction sends already to the public key directly and not to its hash. Hence, with a quantum computer / break of ECDSA, the key can already be cracked. Also, even if we make the coins spendable, it is still Vinced's decision to spend them or not - but I think it makes sense from the point of view of a clearly defined protocol to reduce the number of required ad-hoc rules as much as possible.

[phelix]

What would be the advantage?

IMHO this mostly adds a couple lines of codes and checks... at no practical benefit.

[domob]

What would be the advantage?

IMHO this mostly adds a couple lines of codes and checks... at no practical benefit.

I stumbled upon this while working on constructing the UTXO. If this transaction is not in the blkindex and we keep it that way, I need additional lines in the UTXO construction to specifically skip the genesis block. The same goes (potentially) for everything else that wants to look through all transactions in the future. It definitely has the potential to confuse everyone trying to use the tx index if it doesn't include every transaction.

I think it is much better to add the (very few!) lines of code to include the transaction as it should be and will probably be expected by everyone reading into the code, instead of adding lines to the UTXO creation and every other place where it will be necessary to work around this glitch.

[phelix]

What would be the advantage?

IMHO this mostly adds a couple lines of codes and checks... at no practical benefit.

I stumbled upon this while working on constructing the UTXO. If this transaction is not in the blkindex and we keep it that way, I need additional lines in the UTXO construction to specifically skip the genesis block. The same goes (potentially) for everything else that wants to look through all transactions in the future. It definitely has the potential to confuse everyone trying to use the tx index if it doesn't include every transaction.

I think it is much better to add the (very few!) lines of code to include the transaction as it should be and will probably be expected by everyone reading into the code, instead of adding lines to the UTXO creation and every other place where it will be necessary to work around this glitch.

You have a much more profound view on this than I do.

[virtual_master]

it is still Vinced's decision to spend them or not

That's true and Vinced took his decision not to spend it by making it unspendable.
If he doesn't want to spend it you cannot make him happy giving him 50 NMC with force.
So this argument is not valid for me.

I think it makes sense from the point of view of a clearly defined protocol to reduce the number of required ad-hoc rules as much as possible.

We are not speaking about a random block but about the genesis block which has a special status and deserves the exception if it has a sense.
The argument to have a more clear form is valid but as you suggested before the genesis block coins could be made unspendable in a more clear coded form and this would have the advantage not doing a hardfork.
So as i see they are more arguments to make the coins unspendable clear coded then to make them spendable clear coded.
This is my humble opinion.

[domob]

To summarise, my opinion is that we should add the transaction to the index in any case. Apart from that, I do not really care whether or not we include an additional check in CTransaction::ConnectInputs to reject spending of the genesis block coins. If it was only my choice, I would probably not include it. But if others prefer to keep them unspendable, I can add that, too. (It will only be 2-3 lines of code or so, not really a big problem.)

Can we agree on this? I'll provide a patch if yes.