<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 21, 2014 at 9:17 AM, <a href="mailto:zaki@manian.org">zaki@manian.org</a> <span dir="ltr"><<a href="mailto:zaki@manian.org" target="_blank">zaki@manian.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Several pieces of context that might be helpful to inform the discussion.<div>

<br></div><div>Virtually all Blockchain 2.0 are considering some variation on the block ordering algorithm that does not involve competitive hashing. BitShares is an example of an umbrella Blockchain 2.0  project that has been pursuing support for the DNS application and plans to release a working client within the next few weeks/months. <br>

</div></div></blockquote><div><br></div><div>This statement is specious at best. I would say most in the Bitcoin community are skeptical of any consensus mechanism that *doesn't* involve proof-of-work as none have been convincingly shown to work under fire, whereas Bitcoin has been shown to mostly work so far (of course it could fail later). If it seems like most "Blockchain 2.0" proposals don't involve hashing, that's because we already have a hashing-based scheme that works.</div>

<div><br></div><div>There are 2 big issues with Namecoin that haven't been brought up so far. One is definitely fixable, one maybe not:</div><div><br></div><div>1) Namecoin doesn't support efficient proofs of freshness. Knowing the most recent mapping requires storing the entire block chain, or trusting somebody else to do so for you. You can do an "SPV"-style proof that a name->key mapping existed at some point to anybody tracking the current head of the blockchain, but that doesn't prove that this wasn't overwritten later. This is fixable with a re-design by including the current Merkle tree of mappings in every block . This has been proposed for Bitcoin itself (<a href="https://en.bitcoin.it/wiki/Thin_Client_Security#Unused_Output_Tree_in_the_Block_chain_.28UOT.29">https://en.bitcoin.it/wiki/Thin_Client_Security#Unused_Output_Tree_in_the_Block_chain_.28UOT.29</a>, <a href="https://bitcointalk.org/index.php?topic=88208.0">https://bitcointalk.org/index.php?topic=88208.0</a>) and could certainly be built into a new system, potentially alongside a skip-list to enable compact SPV proofs.</div>

<div><br></div><div>2) Namecoin didn't find a good balance between low cost to register a new name and resistance to squatters and such a balance may not exist. Sovereign Keys avoids this problem by offloading to DNS (you have to own a name in DNS to claim a sovereign key for that name). With Namecoin squatters have already claimed loads of names even though the momentum behind Namecoin is pretty limited. This may be the missed vertex of Zooko's triangle: without centralized policing of claimed names, it may be impossible for people to get any of the human-memorable names they want. Or at least annoyingly expensive.</div>

</div></div></div>