Topic: Namecoin was stillborn, I had to switch off life-support - page 3. (Read 46129 times)
So it is dead or can it be salvaged? Sorry, not technical here.
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.
You found a bug that can be patched. Kudos. If there were an active development team, you would have alerted them privately first I presume rather than stir a panic. I do hope some developers will take this warning to heart and fix the problem, even if a bounty is necessary. Because like the OP, Namecoin is also the favorite alt-coin of many others. 
People, lol! You all just ignore my messages but your ideas clearly point to dianna-project.org
Take a hint and stop spamming your thing on this topic? Go bump your own topic, and hope others join in.
I'm not sure that a block chain is required at all
What prevents double-transfer of names, then?
The Namecoin v2.0 rules.
If by "namecoin v2.0" you mean luke-jr's proposal, that does require a blockchain.
No, I mean a hypothetical protocol that doesn't use a separate blockchain.
Quote
the next namecoin should be implemented on top of the bitcoin blockchain.
Well, good luck convincing people to use it. I'm not very interested in spending money or computing power on an entry in a key-value store that could suddenly become frozen due to small outputs suddenly becoming unspendable or some other change to the bitcoin block validation consensus.
Bitcoin works because everybody has a common interest in it being usable as money. If you're trying to use it for something else you will always be at risk of the majority (who don't care about your weird use) tweaking the rules in a way that breaks it.
You just don't get it: it's impossible to stamp out all the ways of timestamping data in the blockchain, and timestamping w/ bitcoin sacrifices is sufficient to build a useful and secure distributed DNS system. Even a majority of miners can't use blacklists to stop timestamping and bitcoin sacrifices because you can devise protocols with very useful properties where the transactions involved are revealed after they have been confirmed; they've have to whitelist all acceptable transactions, which is close cousin to very strong censorship.
Such a system can't replicate the scamcoin-like aspect of namecoin where you see speculators hoping the price goes up of course, but notice how namecoin has never caught on...
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.
That's one area where Namecoin was very weak. Its blockchain may have started out smaller, but its scalability is no better than Bitcoin's, and it'll eventually have the same problems (like all Bitcoin-based altcoins). But if your decentralized DNS doesn't include a currency, then old data about domain ownership can be more easily forgotten. For example, if you require that registrants renew their domains weekly, then resolvers only need the last few weeks of full blockchain data (plus headers to verify the chain). There may also be better ways of doing this that don't require frequent renewal. (You can also do this sort of renewal thing with BTC in order to reduce download requirements, but it'd be really unpopular.)
Running a resolver on a well-designed DNS system will always be pretty cheap unless Bitcoin's network requirements become huge.
Could DNS be implemented as smart property on top of something like Mastercoin?
Probably, but I'm not a huge fan of smart property or Mastercoin.
That's one area where Namecoin was very weak. Its blockchain may have started out smaller, but its scalability is no better than Bitcoin's, and it'll eventually have the same problems (like all Bitcoin-based altcoins). But if your decentralized DNS doesn't include a currency, then old data about domain ownership can be more easily forgotten. For example, if you require that registrants renew their domains weekly, then resolvers only need the last few weeks of full blockchain data (plus headers to verify the chain). There may also be better ways of doing this that don't require frequent renewal. (You can also do this sort of renewal thing with BTC in order to reduce download requirements, but it'd be really unpopular.)
Well, Namecoin name registrations are rather short term (3 or 6 months?), so I wonder if that can't be implemented in some way, the same way Bitcoin will do pruning.
I'm not sure that a block chain is required at all
What prevents double-transfer of names, then?
The Namecoin v2.0 rules.
If by "namecoin v2.0" you mean luke-jr's proposal, that does require a blockchain.
Quote
the next namecoin should be implemented on top of the bitcoin blockchain.
Well, good luck convincing people to use it. I'm not very interested in spending money or computing power on an entry in a key-value store that could suddenly become frozen due to small outputs suddenly becoming unspendable or some other change to the bitcoin block validation consensus.
Bitcoin works because everybody has a common interest in it being usable as money. If you're trying to use it for something else you will always be at risk of the majority (who don't care about your weird use) tweaking the rules in a way that breaks 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.
In other words, you can't use the bitcoin blockchain for this.
They'll be overruled by an economy majority eventually.
Except that they aren't the majority! You see, that's the issue. As long as the majority of the use of the BTC blockchain is as money, not as a key/value store, people using it as a key/value store are vulnerable to sudden changes that aren't in their interest.
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.No, actually there was a short price ramp. That was the problem.
Because namecoin entries aren't fungible the viability of the system is much more sensitive to the inflation schedule. BTC are fungible so if the initially-hardwired inflation schedule isn't "perfect" it simply amounts to a larger or smaller financial windfall for early adopters.
Essentially, if we give up on names being meaningful (but still keep them short, pronounceable and memorable) then they can be used alone securely as identities - no PKI needed. The idea is that there are a relatively small number of transactions in the Bitcoin blockchain (< 2^25 currently), so you don't need very many bits to encode a transaction's location in the blockchain uniquely.
FWIW I had pretty much the same idea about a half year ago.
https://bitcointalksearch.org/topic/m.1471978
Although I thought about using words rather than phonemes: four words are enough.
E.g. somebody can register a name like "cranky corporate classic company".
Essentially, if we give up on names being meaningful (but still keep them short, pronounceable and memorable) then they can be used alone securely as identities - no PKI needed. The idea is that there are a relatively small number of transactions in the Bitcoin blockchain (< 2^25 currently), so you don't need very many bits to encode a transaction's location in the blockchain uniquely.
FWIW I had pretty much the same idea about a half year ago.
https://bitcointalksearch.org/topic/m.1471978
Although I thought about using words rather than phonemes: four words are enough.
E.g. somebody can register a name like "cranky corporate classic company".
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.
That's one area where Namecoin was very weak. Its blockchain may have started out smaller, but its scalability is no better than Bitcoin's, and it'll eventually have the same problems (like all Bitcoin-based altcoins). But if your decentralized DNS doesn't include a currency, then old data about domain ownership can be more easily forgotten. For example, if you require that registrants renew their domains weekly, then resolvers only need the last few weeks of full blockchain data (plus headers to verify the chain). There may also be better ways of doing this that don't require frequent renewal. (You can also do this sort of renewal thing with BTC in order to reduce download requirements, but it'd be really unpopular.)
Running a resolver on a well-designed DNS system will always be pretty cheap unless Bitcoin's network requirements become huge.
Could DNS be implemented as smart property on top of something like Mastercoin?
Probably, but I'm not a huge fan of smart property or Mastercoin.
decentralized DNS should in now way rely on the blockchain.. PERIOD.. It's madness to continue to build things into the blockchain that have in no way what so ever a relationship to bitcoin. Anyone who says otherwise please show me with FACTS where a decentralized DNS would be better suited crammed into an already bloated block chain instead of its own entity that uses bitcoins in some way... It's extremely lazy in my opinion and there are far better ways to do it.
My my, thats unfortunate. Had this been fixed before being exploited it would have been a trivial soft forking adjustment. Even a simple temporary softforking adjustment to deny all transactions while it would have fixed would have prevented basically all the harm.
I might as well pile on too while we're all at it 
Just some thoughts I've been having about this problem I wanted to share.
Using namecoin strings alone as identities is clearly crazy - they're first come first serve, and anyone can come and register one after you whose typesetting only very subtly different, opening the door for phishing. So you need a PKI built on top, which is much more difficult to do than namecoin itself. Not to mention, as retep did earler ITT, it can't do lightweight clients without trust. Even with the complex UTXO commitments he mentioned, you have to trust that miners won't rewrite history (because lightweight clients won't be able to check a UTXO proof for every block for every name they're interested in).
If we slightly temper our expectations of a secure, decentralized naming system, then we can solve these problems very easily (or define them away, depending on how you look at it). And the result is Good Enough IMHO. Essentially, if we give up on names being meaningful (but still keep them short, pronounceable and memorable) then they can be used alone securely as identities - no PKI needed. The idea is that there are a relatively small number of transactions in the Bitcoin blockchain (< 2^25 currently), so you don't need very many bits to encode a transaction's location in the blockchain uniquely. You then run these encodings through an universally agreed upon cipher to make them dissimilar, and encode the result into some phonemic base. By encoding a pubkey fingerprint in a transaction, you have a secure name to pubkey mapping. This can build directly off of Jeff Garzik's identity protocol: https://en.bitcoin.it/wiki/Identity_protocol_v1.
For example, with a large set of CVC phonemes (consonant - vowel - consonant), you only need three to describe a 32 bit name: ~reb-mizvig. Wisely selecting a smaller set of phonemes may make for more readable names in general at the expense of needing another phoneme: ~bitlyr-worwyd. Might be worth it. And you could have lots of different "languages" for different styles of names. Or different alphabets even. The guys working on Urbit are currently developing some of these phonemic bases and said we can just copy what they come up with if we like.
Note that all a lightweight client needs to resolve a name to a pubkey fingerprint is the block headers and a merkle path, which encodes the transaction's location via the ordering of hashes. Also, names done this way would be very dissimilar, so you could safely use them alone as your identity. This is probably best for identities that live purely online; if people know you only by this name, then key verification comes for free.
Regarding transfer of names, I wonder if that really makes sense. I can wholeheartedly vouch for a person, but can I really sell your trust in me to to them? The names are sufficiently throwaway, so I say don't bother with this. System's much simpler without it.
Of course this all glosses over the need for good key management. Maybe devices like Trezor could be useful here. Some random thoughts on a distributed key revocation blockchain:
- Identity protocol's miner sacrifices makes this hard to spam.
- Authenticated prefix trees instead of merkle trees could make it so you only have to pay attention to small subsets of each block containing (or not containing) names you care about.
- We only care about unjammability, so we can pay attention to, say, the 5 longest branches to make it more difficult for miners to suppress revocations.
Thoughts? Is this all crazy/expecting too much of people? Am I misunderstanding the problem?
Just some thoughts I've been having about this problem I wanted to share.Using namecoin strings alone as identities is clearly crazy - they're first come first serve, and anyone can come and register one after you whose typesetting only very subtly different, opening the door for phishing. So you need a PKI built on top, which is much more difficult to do than namecoin itself. Not to mention, as retep did earler ITT, it can't do lightweight clients without trust. Even with the complex UTXO commitments he mentioned, you have to trust that miners won't rewrite history (because lightweight clients won't be able to check a UTXO proof for every block for every name they're interested in).
If we slightly temper our expectations of a secure, decentralized naming system, then we can solve these problems very easily (or define them away, depending on how you look at it). And the result is Good Enough IMHO. Essentially, if we give up on names being meaningful (but still keep them short, pronounceable and memorable) then they can be used alone securely as identities - no PKI needed. The idea is that there are a relatively small number of transactions in the Bitcoin blockchain (< 2^25 currently), so you don't need very many bits to encode a transaction's location in the blockchain uniquely. You then run these encodings through an universally agreed upon cipher to make them dissimilar, and encode the result into some phonemic base. By encoding a pubkey fingerprint in a transaction, you have a secure name to pubkey mapping. This can build directly off of Jeff Garzik's identity protocol: https://en.bitcoin.it/wiki/Identity_protocol_v1.
For example, with a large set of CVC phonemes (consonant - vowel - consonant), you only need three to describe a 32 bit name: ~reb-mizvig. Wisely selecting a smaller set of phonemes may make for more readable names in general at the expense of needing another phoneme: ~bitlyr-worwyd. Might be worth it. And you could have lots of different "languages" for different styles of names. Or different alphabets even. The guys working on Urbit are currently developing some of these phonemic bases and said we can just copy what they come up with if we like.
Note that all a lightweight client needs to resolve a name to a pubkey fingerprint is the block headers and a merkle path, which encodes the transaction's location via the ordering of hashes. Also, names done this way would be very dissimilar, so you could safely use them alone as your identity. This is probably best for identities that live purely online; if people know you only by this name, then key verification comes for free.
Regarding transfer of names, I wonder if that really makes sense. I can wholeheartedly vouch for a person, but can I really sell your trust in me to to them? The names are sufficiently throwaway, so I say don't bother with this. System's much simpler without it.
Of course this all glosses over the need for good key management. Maybe devices like Trezor could be useful here. Some random thoughts on a distributed key revocation blockchain:
- Identity protocol's miner sacrifices makes this hard to spam.
- Authenticated prefix trees instead of merkle trees could make it so you only have to pay attention to small subsets of each block containing (or not containing) names you care about.
- We only care about unjammability, so we can pay attention to, say, the 5 longest branches to make it more difficult for miners to suppress revocations.
Thoughts? Is this all crazy/expecting too much of people? Am I misunderstanding the problem?
Is there such a thing as a thin client DNS server? I can't think of any way to store an entire database on IPs and domain names in a thin client...
Yes - you make it possible for someone else to store it and provide you a cryptographic proof that what they gave you was correct. This lets you distribute the actual data with any number of solutions.
Namecoin doesn't do this, so unless you have the full namecoin database you have no idea if a given DNS name->ip mapping was correct.
If Namecoin is the best shot we have at a decentralized DNS then that's bad news, because the Namecoin protocol wasn't well thought through and therefore it doesn't really enable a decentralized DNS, see here:
https://bitcointalksearch.org/topic/m.2534114
https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
https://bitcointalksearch.org/topic/m.2534114
https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
Is there such a thing as a thin client DNS server? I can't think of any way to store an entire database on IPs and domain names in a thin client...
Anyway, IMHO, Namecoin, while perhaps not perfect, has been running for a couple of years, already has a large community (relatively speaking) involved in it, and, for these reasons, is the best shot we have at a decentralized DNS. This bug is critical but fixable from what I've gathered.
If Namecoin is the best shot we have at a decentralized DNS then that's bad news, because the Namecoin protocol wasn't well thought through and therefore it doesn't really enable a decentralized DNS, see here:
https://bitcointalksearch.org/topic/m.2534114
https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
Combining all efforts in one blockchain (or several merge-mined blockchains) means that the threshold for a successful attack is higher, reducing the number of organizations that have the resources to be capable of attacking it.
Same higher threshold that leads bitcoin mining into absolute centralization?This is not the way life survived on planet Earth. The key to a successful ecosystem is diversity not uniformity!
Jump to: