Rebase namecoin on Bitcoin 0.6 or libbitcoin

[khal]

Namecoin source code is based on a old release of bitcoin (0.3.24) which is not maintained anymore (no security fixes).

So, time has come to update namecoin.
We have 2 choices :

1. rebase namecoin with latest bitcoin version (0.6.x)
- we need to know each specific protocol changes and the time or block number when they are activated to adapt it to namecoin (ex: bip 16 and 30)
- we need to update namecoin code to use new bitcoin "calls" (a simple merge may not work :p)
- we need to follow future releases/patches to stay uptodate and adapt specific namecoin code if needed

2. create a namecoin client from libbitcoin
- libbitcoin is a c++ library
- with a python binding (not working with latest libbitcoin release because of api change)
- we can separate blockchain management from wallet management
- namecoin can have a GUI with wallet management (like Electrum)
- we need to add namecoin rules to libbitcoin and namecoin commands to the GUI/rpc

Discussion is open :p

[edit]Not to forgot : mining and merged mining

[phelix]

to rebase sounds like a good idea... but also a lot of work

I'd vote for libbitcoin and putting as many non performance relevant parts into python as possible.

but: will libbitcoin continue to be maintained? currently it looks like genjix is doing all the work and it is not yet widely used.

i will just ask him about it.

[Luceo]

I like the libbitcoin idea for a few reasons:

- Firstly, it offers some security through obscurity, as would-be attackers won't just be porting the announced Bitcoin vulnerabilities to Namecoin, and would have to dedicate sizeable time and effort to attacking Namecoin.
- Secondly, Python code will be a lot easier to work with than C++ for the majority of developers. It's faster to write and most of the client is not performance-sensitive.
- Thirdly, it would enable a much easier implementation of a full cross-platform control GUI.

My only fear with libbitcoin is what happens if its developers stop maintaining it? AFAIK it has a very small core (one developer?) and if they failed to keep addressing vulnerabilities, we would have to choose between adopting maintenance of the libbitcoin code ourselves (stretching our own efforts very thinly) or completely rebasing *again* on bitcoin-stable.

[biolizard89]

I like the idea of libbitcoin since it would make it easier to write specialized apps that handle Namecoin. Although the limited number of developers could be a concern.

[MaxSan]

I think if genjx is continuing to update libbitcoin then thats the parth to go, if not, rebase with bitcoin.

[khal]

I'd stick to the standard bitcoin client
I'm not confident libbitcoin will stay around

I guess we all share the same concern about libbitcoin.

Standard bitcoin client has the default to be an all in one software instead of being cut in 2 parts :
- a bitcoin node and blockchain management
- a wallet and tx management (cli and GUI, like now; I'm not speaking about a lightweight client here because a connection is required with YOUR node, even if it becomes easier to do something in that way with a small cli/GUI, like Electrum does it)

I guess the Bitcoin software will need to be split, and all chains will share the same problem one day, namecoin included. I think libbitcoin is a good candidate for that and if we choose it, others may do, increasing libbitcoin activity.

[Luceo]

Maybe we can get in touch with genjx and see what his plans are for libbitcoin?

I think that it's a very viable option if it's likely to keep getting support.

[khal]

genjix is sometimes available on #electrum, at least and at genjix at riseup.net.

I speak a bit with him before he ping timeout, so I didn't get a lot of informations (and point him to this topic).

Modifications to add new tx (allow namecoin tx) and blocks (allow namecoin tx and merged mining) rules shouldn't be a problem.
But, mining is not included in libbitcoin.

What is required for mining is :
- full blockchain history (ok)
- a list of pending tx to include in a block (ok)
- a getwork (and getworkaux) rpc command that provide data for miner softwares (must be added in the software that will use libbitcoin) (see "namecoind help getwork" and "namecoind help getworkaux")
- a createBlock function (maybe be already available in libbitcoin)

I didn't speak about the future support of libbitcoin. Feel free to try yourself :p

[Bitinvestor]

I'm learning Python so libbitcoin would be nice but I'm worried that it is too new and still under development. It would be a bit like building a house on sand. I would prefer to rebase namecoin with the latest bitcoin version (it's probably less work too!) and give libbitcoin another year or so to mature.

[moa]

Just throwing this out there : possibilities for another way forward?

- combination of libbitcoin and rebase with enough (not fully) of current bitcoind core to keep a foot in the door if libbitcoin stagnates?

- develop and maintain a new library "libnamecoin"? .. based on libbitcoin but extended for namecoin and maintained for that reason, in collaboration with genjix on libbitcoin ... (libcoin?) to get some bilateral benefits.

Keeping up with major bitcoind changes is important for the obvious security reasons (if they got a problem namecoin has a problem ... and vice-versa actually) ... BUT ... while namecoin is beholden to bitcoin dev. work it will always make it problematic to branch out and implement fully some of the interesting possibilities namecoin offers over and above bitcoin. The current bitcoin wallet work and bitcoin-qt is getting too deeply into the core bitcoind dev stuff for my liking, they are risking pouring concrete into the whole structure and locking it down forever.

E.g: namecoin still uses .namecoiin/bitcoin.conf file .... perhaps a first order of business is to implement a check/read of .namecoin/namecoin.conf that takes precedence ... and we can deprecate that "bitcoin.conf" anomaly? (have to cut the apron strings at some point )

Aside: Anyone heard from vinced or is completely gone now?