Rebase namecoin on Bitcoin 0.6 or libbitcoin

[indolering]

About Libcoin I don't like that they forked Bitcoin codebase, used it as base but changed to LGPL license (Bitcoin is using MIT license). Thus they made it more restrictive and I always prefer to contribute least restrictive license, thus MIT over LGPL.

And, as someone who licenses all of his code as GPL or AGPL v3, well, I would say that the LGPL is a feature, not a bug. But we can save that religious war for another day ; )

Another reason why I think it would be better to use original Bitcoin is that it's very actively developed by experienced Bitcoin developers, it's tested very thoroughly (Namecoin currently doesn't really have tests and Libcoin have very little). Also Bitcoin will be first place where any security fixes will be implemented.

These are cogent points but they they can be applied in relation to namecoind vs Libcoin too: Libcoin is being actively developed by experienced developers, the core code has solid testing and it is written by the developer who found the last major security bug which caused a hard-fork. It is far more secure and better tested than what we can produce right now.

As Namecoin is based on Bitcoin's implementation it would benefit from all Bitcoin fixes and those could be very simply merged in. Also there might be some cases when Namecoin improvements could also be useful for Bitcoin and merged there. For example some parts of Bitcoin code could be refactored to be coin-independent and then easily reused between Bitcoin and Namecoin (and possibly other altcoins) so wouldn't need to manage whole copy of Bitcoin fork.

Again, the same comparison can be made between Libcoin and namecoind, this is based on Namecoin so it is easier to extend to our needs than reimplementing Namecoin from scratch. Libcoin has been refactored to be coin independent, meaning we can easily reuse parts between Bitcoin and other altcoins.

The biggest problem with the Bitcoin codebase was written by academics, not programmers. They made really strange engineering choices, like not cleanly separating the GUI from the rest of the code that really slows us down. From what I have heard from the devs, there's a lot of "magic" in the code that's hard to reason about.

Because Libcoin is more modular than Bitcoin, we don't need to worry about the Bitcoin specific implementation details. And because it's being backed by a commercial venture, they will keep the other parts of the code up to date while we just focus on making Namecoin better.

A big piece everyone here is missing is that Bitcoin has a foundation which is paying programmers to work on Bitcoin full time. We don't have that, we have what some students can churn out between assignments and a few hours a week from professional programmers. With something this complex, chopping it up into small time slices wrecks your efficiency. And, of the core development team, only a 2 or 3 people are comfortable writing in C++.

While it definitely requires huge work I think it gives way more benefits in future as after it should be quite easy to follow up. I'm not sure how much were changed for Namecoin but if it's diverged a lot from Bitcoin codebase then it might be easier to just re-implement Namecoin back on top of Bitcoin, rather than trying to rebase current code.

Yup, it's basically a reimplement on Bitcoin .9 or spend 6-12 months trying to catch up. That's the rub: we've already failed at maintaining a pure Bitcoin fork. Maybe we can think about a full reimplementation in the future, but we could have a full Libcoin port up and running in a few weeks if we could get a dedicated programmer on it.

[davispuh]

The biggest problem with the Bitcoin codebase was written by academics, not programmers. They made really strange engineering choices, like not cleanly separating the GUI from the rest of the code that really slows us down. From what I have heard from the devs, there's a lot of "magic" in the code that's hard to reason about.

That's true. Well, currently Namecoin have pretty nice QT GUI, not sure how it will be implemented with Libcoin.

Because Libcoin is more modular than Bitcoin, we don't need to worry about the Bitcoin specific implementation details. And because it's being backed by a commercial venture, they will keep the other parts of the code up to date while we just focus on making Namecoin better.

yes, but I think Bitcoin codebase's future is more secured and generally trusted (atleast for me personally) than Libcoin's

A big piece everyone here is missing is that Bitcoin has a foundation which is paying programmers to work on Bitcoin full time. We don't have that, we have what some students can churn out between assignments and a few hours a week from professional programmers. With something this complex, chopping it up into small time slices wrecks your efficiency. And, of the core development team, only a 2 or 3 people are comfortable writing in C++.

yeah and that's why using it, Namecoin would have solid implementation, just need to separate logic so that upstream updates can be very easily integrated without much work at all. Basically like it would be for free. I'm not sure why it went to such current state as it is now, I guess because no one cared enough. C++ is used for both Bitcoin and Libcoin so there's no difference and C++ is good language. Very widely used and I don't really see much drawbacks.

Yup, it's basically a reimplement on Bitcoin .9 or spend 6-12 months trying to catch up. That's the rub: we've already failed at maintaining a pure Bitcoin fork. Maybe we can think about a full reimplementation in the future, but we could have a full Libcoin port up and running in a few weeks if we could get a dedicated programmer on it.

Then can use Libcoin at first to get it running ASAP and maybe "later" use Bitcoin code?

okay, anyway this is just my personal opinion and either way just need actively updated Namecoin software because on that will depend how successful it will be.

[indolering]

That's true. Well, currently Namecoin have pretty nice QT GUI, not sure how it will be implemented with Libcoin.

I believe everyone on the dev team is okay with letting that go away for a while. I personally would like to see Armory or another high-quality wallet be extended for people who actually hold NMC for monetary reasons.

This next opinion is definitely controversial but I think that ever other use-case for Namecoin relies on having a server to automatically handle things like name updates, etc. If you can't handle a command line client then it would probably be safer for your domain if you used a registrar. It's better to pay a registrar $20 than have your domain snatched and held ransom for $100. The *vast* majority of users (myself included) should rely on such services.

yes, but I think Bitcoin codebase's future is more secured and generally trusted (atleast for me personally) than Libcoin's

Yes, but Libcoin's future is more secured than Namecoin's ATM.

yeah and that's why using it, Namecoin would have solid implementation

Well, the reason we are using Libcoin is because Kraken is paying someone to maintain it. I'm not a fan of being reliant on an exchange, but it's the lifeline we need right now :/

just need to separate logic so that upstream updates can be very easily integrated without much work at all. Basically like it would be for free.

Well, Libcoin host modularized the logic backend logic and I doubt they would have reimplemented from scratch if it could have been done another way : /

I'm not sure why it went to such current state as it is now, I guess because no one cared enough. C++ is used for both Bitcoin and Libcoin so there's no difference and C++ is good language. Very widely used and I don't really see much drawbacks.

From what I understand, there were some really bad engineering decisions which exchanged short-term features for a really crappy upgrade path. I have nothing against C++, but we just don't have enough volunteers.

However, if you are comfortable with C++, there is a ~$25K bounty for a port and (potentially) an internship with Kraken. Even if you don't want to take that whole thing on by yourself, there are several simple pull requests for the current version that just need some testing. If you can, please help!

Then can use Libcoin at first to get it running ASAP and maybe "later" use Bitcoin code?

Hopefully we can get large enough that we can spawn multiple implementations. I would like to see some of the core code go through a formal proof process someday!

okay, anyway this is just my personal opinion and either way just need actively updated Namecoin software because on that will depend how successful it will be.

Agreed, and thank you for sharing. I hope I was helpful and not too pushy : )

[biolizard89]

About Libcoin I don't like that they forked Bitcoin codebase, used it as base but changed to LGPL license (Bitcoin is using MIT license). Thus they made it more restrictive and I always prefer to contribute least restrictive license, thus MIT over LGPL.

Another reason why I think it would be better to use original Bitcoin is that it's very actively developed by experienced Bitcoin developers, it's tested very thoroughly (Namecoin currently doesn't really have tests and Libcoin have very little). Also Bitcoin will be first place where any security fixes will be implemented. As Namecoin is based on Bitcoin's implementation it would benefit from all Bitcoin fixes and those could be very simply merged in. Also there might be some cases when Namecoin improvements could also be useful for Bitcoin and merged there. For example some parts of Bitcoin code could be refactored to be coin-independent and then easily reused between Bitcoin and Namecoin (and possibly other altcoins) so wouldn't need to manage whole copy of Bitcoin fork.

libcoin is actively maintained and funded by Kraken. My understanding is that they have been quick at merging code from Bitcoin. libcoin basically is a refactored Bitcoin that is coin-independent, with some other useful refactorizations (e.g. database improvements).

While it definitely requires huge work I think it gives way more benefits in future as after it should be quite easy to follow up. I'm not sure how much were changed for Namecoin but if it's diverged a lot from Bitcoin codebase then it might be easier to just re-implement Namecoin back on top of Bitcoin, rather than trying to rebase current code.


By the way I just rebased/merged Namecoin repository on top of Bitcoin's master one, I didn't resolved any conflicts, but it still might be useful to see what are differences. Basically result is neither Bitcoin nor Namecoin But I think it can be fixed, just have to review all places of "<<<<<<< HEAD" and using blame for both repositories decide how to implement it correctly. It will be easy to resolve some conflicts but for others probably there will be a lot of work needed. After conflicts will be resolved then would need to review all code paths and test everything. So anyway you can see it here: https://github.com/davispuh/namecoin/tr ... oin_merged


EDIT: here's csv file, list of all files with conflicts and count in each file. Like 1/3rd of conflicts are from Qt locale files.

I believe Ryan and Randy tried to rebase; they gave up because the code was too messy and unmaintainable. Thecoder estimated it could cost upwards of $30,000 USD to carefully rebase each change, regardless of whether latest Bitcoin or current Namecoin is the starting point. Even the Bitcoin devs admit that Satoshi's code is hard to maintain; libcoin's main purpose is to fix that.

I still support using libcoin.

[domob]

Just a quick reply: I also support libcoin and as most already read probably, volunteer to work on it (with a limited time budget, though). I'm quite familiar with C++, but not yet the code base. But that should be the lesser hindrance, hopefully.

And since I can't help chipping in here as well: I'm also in favour of copy-left licenses, so I agree that LGPL is a feature over MIT and not a bug.

[biolizard89]

And since I can't help chipping in here as well: I'm also in favour of copy-left licenses, so I agree that LGPL is a feature over MIT and not a bug.

Agreed.

[davispuh]

It's better to pay a registrar $20 than have your domain snatched and held ransom for $100. The *vast* majority of users (myself included) should rely on such services.

I think relying on some 3rd party to manage your domains isn't smart. Atleast I wouldn't and don't trust them. That's why I like Namecoin way better than current DNS system where I don't have control. BTW I would suggest to read this article But yes, there isn't really difference CLI or GUI, just it's more convenient. Main thing is that it should be easy to manage, which of course can be achieved with CLI depending how good it is.

Well, Libcoin host modularized the logic backend logic and I doubt they would have reimplemented from scratch if it could have been done another way : /

Yeah, I just don't understand why couldn't improve and refactor upstream Bitcoin, then everyone would benefit. Maybe could ask Gavin what he thinks about all this and what are their refactoring plans and if it would be possible to modularize it so that it could be easily reused by Namecoin and possibly other altcoins. Basically Libcoin is a fork of Bitcoin when Bitcoin is also actively maintained and thus it should be favored IMHO.

However, if you are comfortable with C++, there is a ~$25K bounty for a port and (potentially) an internship with Kraken. Even if you don't want to take that whole thing on by yourself, there are several simple pull requests for the current version that just need some testing. If you can, please help!

Unfortunately, I already have way too much things to do and I really don't have time. I wish there would be more than 24 hours in a day. So much to do, so little time...



But they took Bitcoin as base, I don't understand why couldn't just leave it as MIT. I guess some people are way too careful with their contributions MIT can be changed to almost any other license without any problems very easily, but once code uses LGPL/GPL and similar it's impossible to change it and that's how it will be for all future.

[biolizard89]

It's better to pay a registrar $20 than have your domain snatched and held ransom for $100. The *vast* majority of users (myself included) should rely on such services.

I think relying on some 3rd party to manage your domains isn't smart. Atleast I wouldn't and don't trust them. That's why I like Namecoin way better than current DNS system where I don't have control. BTW I would suggest to read this article But yes, there isn't really difference CLI or GUI, just it's more convenient. Main thing is that it should be easy to manage, which of course can be achieved with CLI depending how good it is.

I agree; trusting a registrar is an unwise idea, for the same reason that trusting MyBitcoin/Bitcoinica/Instawallet/Inputs.io is an unwise idea. (Those are just the ones off the top of my head.) Even if the registrar is well-intentioned, they may be compromised by a cracker, or served a court order, or threatened with jail time, in which case you're screwed.

If indolering's issue with local clients is that they don't auto-renew, that's fixable. I haven't heard any other complaints about local clients.

[phelix]

Just a quick thought: AFAIK there is no GUI with libcoin. What about modifying and using the Electrum client?

[indolering]

If indolering's issue with local clients is that they don't auto-renew, that's fixable. I haven't heard any other complaints about local clients.

My issue with local clients is that there is no recourse for non-technical users who screw up and are unable to renew their domain, due to lost keys, forgetting to renew, trashing their computer, etc. Registrars provide a valuable service for the 99% of people who don't need to worry about the government coming after their domain.

Just a quick thought: AFAIK there is no GUI with libcoin. What about modifying and using the Electrum client?

Jeremy knows more about this than I, however, I think we should spawn a new thread : )