Topic: Namecoin was stillborn, I had to switch off life-support - page 5. (Read 46129 times)

Is there even a dev team?

I hope that someone uses this opportunity to create a decentralized DNS network that's actually good. Namecoin always had a lot of flaws which probably would have prevented any real success. In particular, DNS does not require its own currency.

Another way to see the blockchain wrt bitcoin.bit is http://explorer.dot-bit.org/n/1

One issue I could see with implementing NMC on top of BTC is future scalability. Specifically, when BTC blockchain gets huge, it would mean that the datacenters that store bitcoin blockchain information would have to also double as DNS providers. I think a NMC blockchain would be much much smaller in size compared to bitcoin, since transactions on namecoin are much less frequest, even if they may hold more data. So keeping the two separate would allow for many more smaller, independent DNS providers, instead of limiting it to just the few bitcoin providers we'll likely end up with in the future.

Well supposedly namecoin was never much use to start with because names were so cheap that basically everyone's name was already taken almost before anyone had heard of the thing?

What prevents double-transfer of names, then?

Unfortunately it's very easy to prevent and has already been discussed on bitcoin-dev.  It can be implemented the same way P2SH was added: a miners-only upgrade that is forced on the minority once the majority adopts it.

You might wake up one day to find that the currency you'd been using to store key/value pairs is no longer accepting updates.

So what we see here is apparently the history of the bitcoin.bit domain registration. If you look at the last entry.. that looks like a confirmation that  libcoin has found an exploit. If I knew C++ I'd try to reproduce this, but I don't.

This is the postmortems and obituary over namecoin. In fact it never really existed, but by block: 139872 it became clear. However, if you haven' t noticed yet read on...

Namecoin has always been my favorite alt-coin - it had a clear purpose, different from Bitcoin, offering a nice way to keep a de-central registry of key-value pairs. About a month ago I had a closer look at namecoin, to integrate it into libcoin. Libcoin is a complete other story, it is a library supporting bitcoin as well as several of the alt coins, enabling easy construction of anything from light weight wallets to full server wallet solutions for exchanges and merchant sites. However, back to namecoin...

I have integrated several alt coins, and I know the machinery pretty well by now. The engine of any bitcoin based crypto currency is the ConnectBlock / ConnectInputs methods in main.cpp. They keep the rules of when to accept a block and when to reject a block, and it is there you make patches to enable anything from alternative hashing algorithms (litecoin) to merged mining (namecoin and others) as well as add new features and rules. Namecoin keep a reasonable separation through the definitions of hooks, implementing the actual rules in a separate file, namecoin.cpp.

So the real interesting stuff in namecoin is happening in namecoin.cpp in the ConnectInputs method. This one is called from ConnectInputs in main.cpp and hence have the ability to change and add rules.

All namecoin rules are kept hidden from the bitcoin script rule engine through OP_DROP opcodes, i.e. some special opcodes and data is entered, followed by a matching chain of OP_DROP commands, so the normal script rule engine will simply ignore anything namecoin'ish. The special op codes of namecoin are:
The reason for the setup is to avoid domain opportunists listening for new domain reservations and issuing competing reservations to later sell the domain back. So first you issue a:
Where the hash is composed of a random number and the domain, hashed. You are not allowed to issue a first-update, finally registering the domain, before after 12 blocks, ensuring no block reorganizations can enable a domain opportunists to steal your domain. In the name_new/name_firstupdate RPC calls this rule is nicely enforced, however, when you look in the ConnectInputs method you find rules enforcing a fee, rules enforcing the 12 blocks, but NO RULES ENFORCING THE HASH! [namecoin.cpp line 1874-1907] ]. So any name_new can be used as input for ANY name. This means that the domain reservation is not enforced at all leaving namecoin completely open for domain opportunists.

Clearly the patient is bleeding and in urgent need for help, but brace yourselves, this is not affecting already registered domains so it is fixable by a proper patch, and a recommendation to not reserve any new domains before the patch is in effect. Relieved that there was a cure I continued with the standard examination, to check if the rest was ok.

The key lines in namecoin.cpp are probably 1930 to 1949, this is the very core of namecoin. This is the enforcing of a name_update - a name update is the script:
So, take an already registered name and update that with a new value. Now you would expect some code enforcing that only an input of that name can be update to another value - but NO! Again there is no enforcing of the core ruleset. So you can in fact update the value of any name in namecoin by any other input name. And after that you own it, or well, as much as you can actually own a name who anyone can update.

The final test was to try it out - (sorry) - I might had overlooked something, so, I changed the name_update algorithm to enable such takeovers, and did a:

Try name_history on d/bitcoin and see for yourselves - there is no enforced integrity of the key value pairs in namecoin. So namecoin looses its entire purpose. The problem is that there is no fix to this - it is similar to being able to randomly take ownership of other peoples money, all the value is gone. I tried, initially, a silent fix contacting namecoin developers and key users more than a month ago, but I never got any answers back. Perhaps, the best future for namecoin now is a rebirth with a new genesis, or just a cancel of all the name reservations starting from some future block ?

I should also note that up until block 139872, no one have exploited the bugs. The libcoin code actually enforced the above rules, and I was able to download and verify the entire chain, now I have added a flag, ignore_rules, to get pass block 139872.

Coinslayer

I tried, initially, a silent fix contacting namecoin developers and key users more than a month ago, but I never got any answers back.

I'm not sure that a block chain is required at all

it should be allowed (with appropriate fees), and in practice it's probably difficult to prevent it.

No, but it does require a serialization mechanism whose developers aren't actively hostile to it being used for information storage.

In other words, you can't use the bitcoin blockchain for this.

So if it isn't its own currency (and therefore pays no block reward) and you can't substitute the BTC blockchain, why should miners waste computing power on it?

That's already possible.  OP_CHECKSIG.  can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.