Reimplement Namecoin on Devcoin?

[ryanc]

Devcoin is merge-mined, which I think is one of the more complicated parts to get working. Someone's updated it based on Bitcoin core 0.8.5 here:

https://github.com/sidhujag/devcoin

Thoughts? Anyone want to work on it? I don't have time until August :-/

[domob]

Sounds like an interesting idea. The major things that need to be ported then are the name operations (obviously). But that is potentially not too much work. At least, it looks this way since I've seen the changes in Huntercoin.

Is their merge-mining compatible to Namecoin's? (Sorry if this is a dumb question, I don't know much about the internals of merge-mining for now.)

[phelix]

hmm...

[domob]

After thinking some more: It all depends on the relative efforts of implementing merge mining and name operations. I suspect that the latter is much more work than the former. In this case, it doesn't really help to start with something that already has merge mining (but no name operations). Instead, we should re-implement both directly on top of Bitcoin trunk. It may not actually be that much of work. (But still a sizable chunk.)

[ryanc]

The name operations themselves are pretty simple, the hardest part would be managing them in a database.

The merged mining implementation should be compatible though there might be some constants that need to be changed.

[snailbrain]

wouldn't this be the same as just doing the rebase (reimplement) on bitcoin - it was something like 400-500 commits made namecoin from bitcoin (at v3.x or whatever)..

mikhail sort of quoted (in $) that it would be the same cost to add all the commits onto namecoin to update to the the latest bitcoin code (1000s of commits), as to working backwards (400 commits), due to the difference in code.

i confused myself - should have read the thread

[domob]

wouldn't this be the same as just doing the rebase (reimplement) on bitcoin - it was something like 400-500 commits made namecoin from bitcoin (at v3.x or whatever)..

mikhail sort of quoted (in $) that it would be the same cost to add all the commits onto namecoin to update to the the latest bitcoin code (1000s of commits), as to working backwards (400 commits), due to the difference in code.

i confused myself - should have read the thread

I think that it would mostly come around to the same result. I think we should do a re-implementation on Bitcoin 0.9 instead if we want to, unless someone can give convincing numbers that the existance of merge-mining would actually save a lot of work.

[John Kenney]

I'm confused. What about libcoin? What's the problem?

[domob]

I'm confused. What about libcoin? What's the problem?

We're still targetting libcoin, and I'm working on it more or less actively. It already supports name_show as well as currency transactions. However, libcoin is somewhat "unstable" from time to time (right now it doesn't sync for me, for instance, and it sometimes doesn't even compile). I think we should have an alternative for the short and mid term, and offer libcoin just as a "beta thing" (but encourage people to test it).

While we are at it, who's actually tried to run libcoin except me? How are your experiences?

[John Kenney]

Isn't there a risk of a fork if there are two separate official implementations? Wont it be dividing (your) efforts? If there's something seriously stalling libcoin & it'll be a lot easier to bring namecoin up to bitcoin 0.9 or devcoin than get libcoin stable & supporting all namecoin features then it might make sense. Libcoin's code looks better organised than bitcoin, I prefer the separation between libcoin & any front ends too. I think I'd prefer libcoin working well over an updated version based on bitcoin (or another bitcoin fork).

I was planning to try libcoin when I get the testnet faucet set up again, since it'll be on a cheap low ram atom server (and I hope libcoin is less ram hungry) & that wont need to do any name operations, but I haven't done it yet. Does libcoin support the current testnet?