Problems with Namecoin

[ChristopherA]

/re code-and-file-signing.adoc #37af399 /cc @msgilligan

I've always been uncomfortable with Namecoin for a variety of personal reasons, but ever since it was revealed that no one noticed that a single mining pool controlling over 60% of Namecoin’s hashrate I've been very concerned.

As further evidence of these concerns, OneName.com, who was one of the largest supporters of NameCoin, are now are now pulling out of NameCoin and using Bitcoin instead.

What specific features or functionality of NameCoin are you wishing to leverage? Can you break them out so that we can see if that functionality can be served another way?

[msgilligan]

Yes, mining centralization is a concern. I somehow get the impression that OneName.com had plans to create their own thing before the mining centralization story developed and used that as a time to announce. They seem to have had a go-it-alone attitude from the start. (For example they created a new namespace on Namecoin without much communication with the Namecoin devs.) Their solution does not seem to be as far along as Namecoin and is not fully documented IIRC. I'm also concerned that their solution relies on an external DHT and don't understand what incentives there are for keeping those servers running.

I don't think the basic solution I'm proposing in the paper requires Namecoin, that's why I'm saying blockchain-based. The DNSChain server is a blockchain-agnostic, so if we use it's REST API for the proof-of-concept implementation the possibility of using another blockchain remains open.

I've been working with @taoeffect and some folks in the Namecoin community and they have all been supportive of my efforts so far. (The beeLīn experimental browser I'm working on is using DNSChain and Namecoin)

The main features of Namecoin that I want to use in a prototype are the d/ (domain) and id/ (id) namespaces and the PGP key fingerprint field. Any alternative blockchain-based system would need to have equivalent features and I think would be likely to have them.

I will certainly be designing and implementing things to be modular and blockchain-agnostic.

[taoeffect]

All code signing stuff can be done using any blockchain. Easy to use Bitcoin instead via Blockstore.

[taoeffect]

I'm also concerned that their solution relies on an external DHT and don't understand what incentives there are for keeping those servers running.

Two answers:

• Sia: https://siacoin.com
• Filecoin: http://filecoin.io/

Interesting discussion on the matter: https://www.reddit.com/r/ethereum/comments/3opycc/potential_decentralized_storage_for_ethereum_sia/cw06gx2

[msgilligan]

@taoeffect Any thoughts on the Namecoin mining centralization issue?

[ChristopherA]

If it is proof-of-existence that is paramount for your solution, and not some other property of a blockchain, then I like the approach that Tierion's Chainpoint uses https://github.com/chainpoint as a way to create a blockchain agnostic receipt. I may quibble with the JSON a little, but the general ideas is with that data you have all you need to confirm your hash without relying on a DHT service (such as blockstore).

[taoeffect]

@taoeffect Any thoughts on the Namecoin mining centralization issue?

Namecoin has mining centralization problems. Bitcoin has mining centralization problems (though not as bad. Yet.). So do all blockchains, whether they use mining or not.

Don't ask for "the perfect blockchain". It doesn't exist (to my knowledge). Design systems where many blockchains can co-exist.

[msgilligan]

We need more than proof-of-existence, I believe. We need uniqueness, lookup, and proof-of-ownership. Standard naming stuff, but more than existence. Namecoin provides these well and seems a good fit for a PoC.

[msgilligan]

As long as Namecoin is merged-mined by a subset of mining pools, it will always be more centralized than Bitcoin. Is there any hope this can change?

[taoeffect]

To be clear, none of this is a real problem if @msgilligan implements his stuff with an agnostic tool like DNSChain.

It becomes simple to switch from Namecoin, to Bitcoin, to Ethereum, etc.

So, I really don't think there's much of an issue here, except perhaps the lack of a generic thin client protocol. ;)

[msgilligan]

I have two interests here:

1. Something I can quickly build a PoC Gradle plugin to demo code-signing using any Blockchain.
2. A long-term solution for naming that could be more broadly adopted for multiple applications.

Ultimately, I'm interested in both. But am leaning towards the DNSChain/Namecoin solution for the coming Hackathon.

[msgilligan]

My biggest question about Blockstore is in their FAQ: Is there any incentive to run a node? That seems like a good topic for discussion at the workshop.

[taoeffect]

What's wrong with the answer I gave last time you asked that? :P

[msgilligan]

I don't think Blockstore is using those solutions, is it?

And they both look like large projects that do much more than what is needed for naming and that may or may not be successful long term.

I'm also somewhat familiar with StorJ and Maidsafe.

[taoeffect]

Blockstore is not using those solutions, but that doesn't mean it couldn't, and if it doesn't, that doesn't mean they can't be used on their own without Blockstore.

I'm just saying, you asked a question, and that's the best answer I'm aware of. If you can think of something better you're welcome to suggest it! :P

[msgilligan]

Yeah, so for my interest (1) above, being Blockchain agnostic with DNSChain seems like the right approach. For interest (2) I need to learn more about all these solutions. I'd definitely like to see something as minimal as possible that works on top of Bitcoin that can provide naming services. I appreciate the pointers!

I thought @ChristopherA's reference to Chainpoint was interesting as a nice, stand-alone piece of functionality. I'd like to see something really minimal like that that could do name registration and lookup. If there were a way to provide incentives and allocate costs for doing it on the Bitcoin blockchain that would be really interesting.

[peacekeeper]

I'm also concerned that their solution relies on an external DHT

My understanding is that Blockstore's DHT isn't really a critical component. Your incentive to run a DHT node is so you can do registrations/lookups more easily I think? But any problem with the DHT can't really impact existing registrations. Also, the DHT is just one of Blockstore's storage options, you could also store the data locally and publish regularly via FTP or something like that..

[msgilligan]

I see some interesting commits coming in from @shea256 ... They're not linked from the README yet, but they're looking very relevant.

[coder5876]

@msgilligan I've thought a bit about the problem you're trying to tackle here. IMO the way to go is something like this:

• Store the file (.jar or whatever) to be downloaded in a content-addressed file storage network like IPFS
• The developer puts a hash of the file on a blockchain. The process of putting it on the blockchain will automatically associate a digital signature with the hash, i.e. the signature on the transaction that puts the hash in there.
• Now anyone can access the hash (signed by the developer) and then retrieve the file from IPFS (which will automatically verify the hash)

So now you need lookups. For lookups the developer could post their public key or hash thereof and you can look up the hashes associated to that public key. You could also use a lookup table with human-meaningful strings, but in a decentralized system that always brings the problem of name squatting etc...

[jimscarver]

Individuals are free to trust any blockchain they choose in the FreeTrust.org philosophy so being blockchain agnostic is essential. A challenge of FreeTrust will be finding services trusted in common by parties or running redundant services to satisfy all the parties.

FreeTrust itself cannot trust any blockchain so at least 3 blockchains need to agree in order to detect a deviant blockchain. I envision there being huge numbers of blockchains using technologies like eros.

FreeTrust plans running the user agent on Synereo with formal process calculus social contracts enforces by the network. These contracts will evolve as users specify new rules and other copy those rules.

We cannot figure our in advance what people will come to trust, and need to build a system where users can make their own rules.

While I could not attend I hope to submit something for the meeting. The FreeTrust community has slowed down and the material is slightly data but expertise has been assembled there covering academic and technical areas. Comments would be appreaciated. https://docs.google.com/document/d/1HF5iEVaVWzrYjqGNuKfy00EEtrjBnRsTvBKvKCmQW0g/edit Join the slack at http://FreTrust.net