Namecoin Forum

tl;dr: If you install namecore on top of the old client's data directory then you'll run into severe problems.

I don't think this is necessarily the case. I'm currently running v0.3.80 namecoin/namecoinq-release branch and namecoin/namecore branch against the same data directory, not simultaneously, but without problems.

moa wrote:

tl;dr: If you install namecore on top of the old client's data directory then you'll run into severe problems.

I don't think this is necessarily the case. I'm currently running v0.3.80 namecoin/namecoinq-release branch and namecoin/namecore branch against the same data directory, not simultaneously, but without problems.

My understanding was that the newer Bitcoin Core releases would automatically upgrade the block database, but keep the old version present. So I'm not sure what severe problems Cassini is referring to. I could be totally wrong though.

moa wrote:I'm currently running v0.3.80 namecoin/namecoinq-release branch and namecoin/namecore branch against the same data directory, not simultaneously, but without problems.

Now that's interesting. I had tried exactly this and it didn't work for me (can't remember what the error message was). I've tried only once, though, and maybe abandoned this strategy too early. I then let namecore start synchronizing in a new empty directory, and the directory contents of a 0.3.80 looked just too different to those of a namecore datadir.

biolizard89 wrote:the block database, but keep the old version present.

This could explain it. I've got to do some more experiments on that.

I just noticed I could use the old wallet fine but the blockchain data threw an error.

> name_history d/nx
> -namehistory is not enabled (code -1)

The automatic reindexing via the GUI failed and seems to have broken my database... oops

Assertion failed!
[...]
File: main.cpp, Line 3004
Expression: pindexPrev

It seems by default name_history is not enabled to save resources (is that a lot?). Maybe we should discuss implications of this...

phelix wrote:> name_history d/nx
> -namehistory is not enabled (code -1)

The automatic reindexing via the GUI failed and seems to have broken my database... oops

Assertion failed!
[...]
File: main.cpp, Line 3004
Expression: pindexPrev

It seems by default name_history is not enabled to save resources (is that a lot?). Maybe we should discuss implications of this...

I assume name_history being disabled is because Bitcoin Core only indexes the UTXO set, not the full blockchain. This is a pretty big difference in Bitcoin's case -- I think over 20-fold in resource usage, but I don't recall exact numbers.

I've made the name history optional. Not sure why reindexing via the UI failed, but usually you should be able to restart your daemon with "-reindex -namehistory" to build the name history. Put "namehistory=1" in the config file.

Note that this is not directly related to -txindex. It is the same principle, but neither does rely on the other. The name history database is fully built by me and not based on (or dependend on) -txindex.

If you think that enabling the name history by default is the better setting, we can do that. But I think that the history is actually more an "advanced" feature that most users are not interested in. That's why I disabled it.

domob wrote:I've made the name history optional. Not sure why reindexing via the UI failed, but usually you should be able to restart your daemon with "-reindex -namehistory" to build the name history. Put "namehistory=1" in the config file.

Note that this is not directly related to -txindex. It is the same principle, but neither does rely on the other. The name history database is fully built by me and not based on (or dependend on) -txindex.

If you think that enabling the name history by default is the better setting, we can do that. But I think that the history is actually more an "advanced" feature that most users are not interested in. That's why I disabled it.

Thanks for the clarification. I think the name history index should be disabled by default, for the same reason that the tx history index is disabled by default (scalability). However, I wouldn't mind having a GUI option available to enable it. (I guess that might be more of a Bitcoin issue, since Bitcoin Core doesn't have such an option for the tx history index.)

domob wrote:you should be able to restart your daemon with "-reindex -namehistory" to build the name history. Put "namehistory=1" in the config file.

I did a few experiments with -namehistory recently (without -reindex). This namehistory rescan takes several hours. Afterwards name_history works as expected.
AFAIK -reindex is only required if the data directory is in an inconsistent state (e.g. missing transactions in listtransactions), or if you want to use the -txindex arg, see https://en.bitcoin.it/wiki/Running_Bitcoin

domob wrote:Put "namehistory=1" in the config file.

Does this mean if there is neither a namehistory arg on the command line nor in the config file, the client automatically throws away all the history data?

biolizard89 wrote:I think the name history index should be disabled by default, for the same reason that the tx history index is disabled by default (scalability).

+1 (except if -namehistory increases the storage footprint by only a few kilobytes. Need to test this again.)

cassini wrote:

domob wrote:Put "namehistory=1" in the config file.

Does this mean if there is neither a namehistory arg on the command line nor in the config file, the client automatically throws away all the history data?

No, I think it refuses to start without explicitly giving "-reindex" whenever you change the value (does not matter which way). That's what "-txindex" does as well.

cassini wrote:

biolizard89 wrote:I think the name history index should be disabled by default, for the same reason that the tx history index is disabled by default (scalability).

+1 (except if -namehistory increases the storage footprint by only a few kilobytes. Need to test this again.)

I think it might be a minor saving, but this could well change in the future. It makes sense to have the setting, and IMHO disable it by default, nevertheless.