Namecoin was stillborn, I had to switch off life-support

[No_2]

Thanks for sharing this info. As a non-programmer, but technical person info like this is very valuable.

If it did come down to a hard fork I only see namecoin coming out a stronger in the long run. Decentralisation of DNS is a very strong proposition.

... Having developers like yourself actually looking into the code and testing the hell out of every possibility  is what makes it secure...

+1

[libcoin]

not sure if i totally understand the implications, but does the fact that anyone can update the values means that the ownership of the domain is compromised? i would guess it's not, in the sense that once they fix the bug then the real owners of the domains can just update again to the right value (in case someone else updated their value without authorization) and no one else can change it once it's patched.

i think it's not a big deal for the owner of the domain to have to do an update after the patch rather than having to cancel all the domain registrations

Yes, the ownership of the domains is compromised - in fact they are equally owned by everyone, so if you have a domain you can steal/grab/claim any other domain at will.

Well, the update I executed means that I now own the d/bitcoin domain - and tracking back trying to fix this stuff could be quite complicated.

Also, namecoin is a math based currency - the math is fine, however, someone forgot to check it before trusting in it. So today namecoin is nothing but an alt coin - it is not a secure registry for key-value pairs, but it could become one in the future, once the rules are switched on. To claim domains backwards becomes inelegant, messy and calls for an authority which we are usually not in favor of...

[Ticked]

So all the brains and noise in crypto and open source projects over looked such a disaster?
I'm not sure whether to congratulate you or offer my condolences to the dev team and the big players.

This is rather interesting, not only for crypto, but also for all open source projects; having a project "open source" and calling the myth of "open source is more secure" doesn't make the code more secure.. Having developers like yourself actually looking into the code and testing the hell out of every possibility  is what makes it secure.

Nice work, hope a fix, patch, rebirth or whatever you want to call it will be pushed out soon as such noise is in no way good to any cryptos including but not limited to Bitcoin 

Open source is more secure exactly because it can get wider peer review. Programmers make mistakes, but with closed source issues can go un-notices for years - even on purpose while other exploit the 0day. The NSA have been doing this for example.

Exactly, I'm not saying it isn't, I'm trying to say that if a software is open source, it shouldn't be taken for granted. I'm not a dev myself, I wish I were, but I think devs in the crypto community should make some sort of organization to do nothing but test for such bugs and us the users can donate to them, or they should be paid from TX fees, ads etc... This community is getting wider and bigger, being decentralized doesn't mean we can't have a well known organization to look after the technical side of things for all crypto related software

Well, I disagree, I see it as the duty of the exchanges and wallet services to perform this kind of scrutiny / review before adding a new alt-coin to their assets. I know that this has not been the practice so far, while everything has been wild west gold digger mentality, but things are getting legit, and you should do your best to secure your customers values. Anyway, it was actually in this process I found the above bugs, and I have seen other bugs in other alt-currencies, but never any alarming ones until now.

If this were the case, we'd be putting a lot of faith into exchange devs. Historically speaking, this doesn't feel like the safest idea. Frankly, I don't see this model eliminating the aforementioned concerns. Establishing a publicly-operating organization, one disconnected from any exchanges, and without any coin devs, feels like an option that could promote more security whilst eliminating personally vested interests from influencing a specific coins reputation. If a coin could pass the organizations' tests & review, we've got a seal of approval, which could impact the frequency pump and dump coins. 

Truth be told, my technical/coding prowess is certainly underwhelming compared to many in this community, so the following is purely thoughts aloud. ...on a screen.

Operating such an organization would take a development team as coin investigation would be rigorous & thorough. This sounds expensive. How is it funded?

A. Directly by exchanges. If the organizations' Seal of Approval proved useful and gained support, this could force the exchanges to use the org's services when adding new coins, lest they run the risk of allowing other exchanges to gain a competitive edge.
B. Conglomerate. Exchanges are given the option to enroll with the organization. Upon enrollment, a % of fees generated (or flat rate [perhaps reoccurring], whatever) is contributed to a fund. This is the operating fund for the organization. New coins can submit application directly to the org for approval. At this point, the enrolled exchanges vote on investigatory review. 
C. By the community. Seems difficult as it would be donation based. This sounds like its begging for closed door deals, bribery, and kickbacks.

What to avoid?

A. Operating in private. It seems to me we'd all benefit from such a group posting their investigations so the technical community can review where any conclusions are coming from. Devs miss things, as Libcoin has pointed out. Enabling the community to review the work of the organization would lend to benefit all involved. 
B. A Future funding operation model - i.e. The organization being funded with the coins it approves. Keeping the organization unbiased is key.



This is a half formed thought.  9-5 work is calling. I could expand on these ideas if its of interest.  Cheers!

[No_2]

not sure if i totally understand the implications, but does the fact that anyone can update the values means that the ownership of the domain is compromised? i would guess it's not, in the sense that once they fix the bug then the real owners of the domains can just update again to the right value (in case someone else updated their value without authorization) and no one else can change it once it's patched.

i think it's not a big deal for the owner of the domain to have to do an update after the patch rather than having to cancel all the domain registrations

Yes, the ownership of the domains is compromised - in fact they are equally owned by everyone, so if you have a domain you can steal/grab/claim any other domain at will.

Well, the update I executed means that I now own the d/bitcoin domain - and tracking back trying to fix this stuff could be quite complicated.

Also, namecoin is a math based currency - the math is fine, however, someone forgot to check it before trusting in it. So today namecoin is nothing but an alt coin - it is not a secure registry for key-value pairs, but it could become one in the future, once the rules are switched on. To claim domains backwards becomes inelegant, messy and calls for an authority which we are usually not in favor of...

What we need is some form of proof of work system to enforce the ownership of the domains...

[Rassah]

Is this what you mentioned while in Amsterdam, when you asked the OT developers to hold off on implementing Namecoin?

[theymos]

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.

[eldentyrell]

Another reason why alternative implementations are so important.  Nice catch, libcoin.

Now you would expect some code enforcing that only an input of that name can be update to another value - but NO!

It's just a hardfork that needs to be done in order to enforce the rules, no?

Well, it will be awfully hard to administer such a hardfork - either you reorganize all the way back to block 139872,

Oh come on now, that's not difficult at all.  And calling it "reorganization" makes it sound more difficult and complicated than it really is.  The rule is simple: trust the difficultywise-longest chain that obeys the validation rules.  You found an epic bug in the check for the "obeys the validation rules" part.  Fix that bug and the system will do the right thing.

Nothing actually gets reorganized, which is why this terminology makes no sense.  You simply ignore blocks that aren't on the difficultywise-longest valid chain.

A lot of miners will lose a lot of block rewards, but they'll get over it.  Any legitimate transactions mined into the  invalid chain will be remined.

[eldentyrell]

DNS does not require its own currency.

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?

[No_2]

DNS does not require its own currency.

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?

If you are going to decentralise you'll need a proof of work / proof of stake mechanism.

The monetisation of proof of work such as a namecoin like system is one way to achieve this.

Other proof of work systems could potentially be used too, I'd be interested to see what gets proposed.

[theymos]

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?

I'm not sure that a block chain is required at all, but if it is, it's probably best to use the Bitcoin block chain. General timestamping with Bitcoin is incredibly useful, and it can't be done in other chains because the incentives aren't right. So it should be allowed (with appropriate fees), and in practice it's probably difficult to prevent it.

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> 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.

[eldentyrell]

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

What prevents double-transfer of names, then?

but if it is, it's probably best to use the Bitcoin block chain.

That is dangerous because of the developers' active hostility towards attempts to store non-transaction data in the chain.

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

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.

[phelix]

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

It seems you did not try very hard because none of the active Namecoiners heard of anything. Still, thanks for bringing it up.

We are looking into a fix that will not need a reorg. Maybe by ignoring bad name_ops until hard fork height or something.


Finally some publicity for Namecoin 

[rassalas]

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:

Code:

OP_NAME_NEW
OP_NAME_FIRSTUPDATE
OP_NAME_UPDATE

The reason for the

Code:

OP_NAME_NEW/OP_NAME_FIRSTUPDATE

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:

Code:

OP_NAME_NEW << hash << OP_2DROP

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:

Code:

OP_NAME_UPDATE << vchName << vchValue << OP_2DROP << OP_DROP

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:

Code:

./namecoind name_fakeupdate d/postmortem d/bitcoin "Namecoin died October the 15th 2013, coinslayer"

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

So while everyone is busy, selling all their namecoins on this rumour, has anyone bothered to fact check this? 
I would like to have independant verification that what he's writing is true.

[Anonymous]

Code:

$ ./namecoind name_history d/bitcoin

[
    {
        "name" : "d/bitcoin",
        "value" : "webpagedeveloper.me/namecoin",
        "txid" : "ab1207bd605af57ed0b5325ac94d19578cff3bce668ebe8dda2f42a00b001f5d",
        "address" : "NGcTVLgw6cgdavaE7C9QvWaY7gKiWbLrjP",
        "expires_in" : -127790,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "75e7f4bbccf673d755dd2b1e4a302c15f716c1f5b5d1d8f80d94d3d805ed64d1",
        "address" : "NJpHX9pHiApFtBtCMLxpEd9n4v47G2useU",
        "expires_in" : -91788,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "3376c5e0e5b69d0a104863de8432d7c13f891065e7628a72487b770c6418d397",
        "address" : "N9dLs1zHRfZr5cJNjSrvhWrrUcmNSthdmz",
        "expires_in" : -80068,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "cc9f6c9493ad9a556f19fe91539339529ed3ceb8a4abd281f49c049f274ff812",
        "address" : "N87erkfoA73u1hDBtMgAJqb1dRoN5Bf13g",
        "expires_in" : -44908,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "ad70a260c2877129b278bd8efdc8811c3f5b9246bdeb429bb2ff84c08cb53c59",
        "address" : "N2W86iuzrwwxZktpJZ3E2xBn1FaYza3Seo",
        "expires_in" : -9834,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "0bd0d194dfec880211d281fdf0efec28f36fc0a969ea2f437d56766e945fcccb",
        "address" : "MvuWVugaAAoU5CUq1ycggsQjYeeBwJ2nE6",
        "expires_in" : 25180
    },
    {
        "name" : "d/bitcoin",
        "value" : "Namecoin died October the 15th 2013, coinslayer",
        "txid" : "2f034f2499c136a2c5a922ca4be65c1292815c753bbb100a2a26d5ad532c3919",
        "address" : "NCef39aRywWU1CBnRYWhoLFyo7GqcvX7TB",
        "expires_in" : 35940
    }
]

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.

[favdesu]

Code:

$ ./namecoind name_history d/bitcoin

[
    {
        "name" : "d/bitcoin",
        "value" : "webpagedeveloper.me/namecoin",
        "txid" : "ab1207bd605af57ed0b5325ac94d19578cff3bce668ebe8dda2f42a00b001f5d",
        "address" : "NGcTVLgw6cgdavaE7C9QvWaY7gKiWbLrjP",
        "expires_in" : -127790,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "75e7f4bbccf673d755dd2b1e4a302c15f716c1f5b5d1d8f80d94d3d805ed64d1",
        "address" : "NJpHX9pHiApFtBtCMLxpEd9n4v47G2useU",
        "expires_in" : -91788,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "3376c5e0e5b69d0a104863de8432d7c13f891065e7628a72487b770c6418d397",
        "address" : "N9dLs1zHRfZr5cJNjSrvhWrrUcmNSthdmz",
        "expires_in" : -80068,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "cc9f6c9493ad9a556f19fe91539339529ed3ceb8a4abd281f49c049f274ff812",
        "address" : "N87erkfoA73u1hDBtMgAJqb1dRoN5Bf13g",
        "expires_in" : -44908,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "ad70a260c2877129b278bd8efdc8811c3f5b9246bdeb429bb2ff84c08cb53c59",
        "address" : "N2W86iuzrwwxZktpJZ3E2xBn1FaYza3Seo",
        "expires_in" : -9834,
        "expired" : 1
    },
    {
        "name" : "d/bitcoin",
        "value" : "{\"info\":{\"registrar\":\"http://register.dot-bit.org\"},\"email\": \"register@dot-bit.org\",\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}}}",
        "txid" : "0bd0d194dfec880211d281fdf0efec28f36fc0a969ea2f437d56766e945fcccb",
        "address" : "MvuWVugaAAoU5CUq1ycggsQjYeeBwJ2nE6",
        "expires_in" : 25180
    },
    {
        "name" : "d/bitcoin",
        "value" : "Namecoin died October the 15th 2013, coinslayer",
        "txid" : "2f034f2499c136a2c5a922ca4be65c1292815c753bbb100a2a26d5ad532c3919",
        "address" : "NCef39aRywWU1CBnRYWhoLFyo7GqcvX7TB",
        "expires_in" : 35940
    }
]

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.

If that's true then... RIP in pieces NMC

[markm]

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?

Are there any usernames from this forum that weren't squatted, for example?

Though maybe the whole point of this "bug" was precisely to get to see what names were wanted then grab them?

Starting over doesn't seem likely to be helpful since squatters scripts will collide all over each other in the first few moments after the fix grabbing every name than anyone ever wanted...

-MarkM-

[Peter Todd]

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

What prevents double-transfer of names, then?

The Namecoin v2.0 rules.

You have to understand that what Bitcoin provides for a "Namecoin v2.0" system that works on top of the Bitcoin blockchain is a (proof of) data publication and ordering service, nothing more. It's the agreed upon rules that would take that data and determine what it actually means in terms of who owns what domains.

but if it is, it's probably best to use the Bitcoin block chain.

That is dangerous because of the developers' active hostility towards attempts to store non-transaction data in the chain.

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

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.

Gregory Maxwell's P2SH^2 system is very clever, but it still doesn't prevent publication of data in the Bitcoin blockchain, only the Bitcoin UTXO set. There's absolutely nothing we can do to prevent people from publishing data in the blockchain other than miners using blacklists, and even that measure can be circumvented if what you are doing is timestamping; I wrote up a good Namecoin v2.0 proposal on #bitcoin-wizards a while back that I called "zookeyv" that is genuinely impossible to block short of having all Bitcoin users sign their transactions with real-world identities that a majority of miners verify.

I agree with theymos on this: the next namecoin should be implemented on top of the bitcoin blockchain.


FWIW I wrote an improved version of the "blockchain data uploading" script that was put in the Bitcoin blockchain a few months ago to get a better understanding of the counter-measures possible; I'm increasingly thinking it'd be worthwhile to publish that code in the same spirit of publishing security exploits. Better we understand these issues now than find out the hard way later.

[Anonymous]

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

[phelix]

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?

Actually there was a long price ramp at the beginning and names started out very expensive.

[Rassah]

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.