<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div><div>Hi all!</div><div><br></div><div>Thanks much to Trevor for doing what I was unable to do: starting and facilitating a foundation for discussion of how blockchain technology is relevant to end-to-end encrypted messaging projects.</div><div><br></div><div>Please forgive any excess brevity on my part as I reply to Zaki and Trevor's comments (I am in the middle of a cross-country move atm).</div><div><br></div><div><br></div><div><br></div><div>#### Reply to Trevor's comments</div><div><br></div><div><blockquote type="cite">Similar structures have been proposed for certificates and revocation<br>(Naor-Nissim [2] and related; Certificate Transparency and related).</blockquote></div><div><br></div><div>It's important to emphasize that CT and the blockchain have very significant differences, and that these significant differences lead to meaningful differences in the security that they are able to provide.</div><div><br></div><div>The main differences are:</div><div><br></div><div>- CT logs are generated in a centralized manner, whereas in Bitcoin they are generated in a decentralized manner</div><div>- CT logs are not secured by any decentralized consensus mechanism such as Proof-of-work / Proof-of-stack / Proof-of-activity / etc.</div><div>- CT is much more centralized and relies on central authorities to run these logs (the FAQ suggests logs will be maintained by "every major CA") [1]</div><div><br></div><div>These differences have major security implications:</div><div><br></div><div>- CT cannot to deliver on its promise to document every certificate that is issued. It makes it possible for malicious actors to issue fraudulent certs and never actually log or report them. [2] [3]</div><div>- Certs must be purchased via yearly subscriptions, whereas with Namecoin / DNSChain they are free.</div><div>- CT does not prevent MITM attacks, whereas DNSChain does.</div><div>- Whereas certificate revocation for compromised certificates is not an issue in Namecoin / DNSChain, it is still an unsolved problem with CT. [4]</div><div><br></div><div><br></div><div>[1] <a href="http://www.certificate-transparency.org/faq">http://www.certificate-transparency.org/faq</a></div><div>[2] <a href="http://www.ietf.org/mail-archive/web/trans/current/msg00233.html">http://www.ietf.org/mail-archive/web/trans/current/msg00233.html</a></div><div>[3] <a href="http://okturtles.com/#oktvs">http://okturtles.com/#oktvs</a></div><div>[4] <a href="https://news.ycombinator.com/item?id=7556909">https://news.ycombinator.com/item?id=7556909</a></div><div><br></div><div>// reference enumeration is reset after this point.</div><div><br></div><div><br></div><div><blockquote type="cite">2) Namecoin is a centralized namespace dependent on Bitcoin<br></blockquote><div><br></div><div>Namecoin maintains its own blockchain that is completely independent of Bitcoin's blockchain.</div><div><br></div><div>Also, I think you meant "global" instead of "centralized". Namecoin's namespace a decentralized, global namespace.</div><div><br></div><div><blockquote type="cite">not just a log that different parties could run.</blockquote></div><div><br></div><div>Perhaps I'm misunderstanding what you mean by "run" here, but just to be clear: the decentralized nature of Namecoin means anyone (not just CAs) can "run" this log.</div><div><br></div><div><br></div><blockquote type="cite">(1) means Namecoin-type logs probably can't be used with existing<br>namespaces, since existing service providers probably don't want to<br>surrender control over their names. But these logs might be a good<br>way to assign a new name to a public key (e.g. an alternative to<br>fingerprints). Bob just has to check that his name was registered, he<br>doesn't have to worry about changes after that.<br></blockquote><div><span></span><br></div><div>If you're referring to ICANN TLDs, there is a proposal for how to migrate these over:</div><div><br></div><div><a href="https://forum.namecoin.info/viewtopic.php?f=5&t=1439">https://forum.namecoin.info/viewtopic.php?f=5&t=1439</a></div><div><br></div><div>I think it would difficult to implement, and there seems to be little interest at the moment, but it seems possible.</div><div><br></div><blockquote type="cite">(2) means Namecoin *definitely* can't be used with existing<br>namespaces, as there's a single global namespace and anyone could<br>register any names. It also means we're tied to this blockchain and<br>its quirks, and the only way to get names is to buy them via Namecoin,<br>which seems like a poor user experience at the moment.<br></blockquote></div><div><br></div><div>Yes, this is a relevant issue that must be solved. The underlying issue here is name squatters and spam on the blockchain, and so far I am aware of only a handle of ways to deal with this:</div><div><br></div><div><div>- The current pay-for-name and keep updating it mechanism.</div></div><div>- Some type of auction mechanism on the blockchain (this is something that Bitshares DNS is working on, I think. It may also be possible with Ethereum contracts.)</div><div>- Centralized "official" registration points.</div><div><br></div><div><blockquote type="cite">Greg Slepak has DNSChain [4], which looks up<br>Namecoin entries so you don't need your own copy of the blockchain<br>(currently 2 GB). Interestingly it doesn't provide Merkle Tree proofs<br>that the entries match widely published root hashes. The argument is<br>you should just query a trusted DNSChain server.<br><br>I don't see anyone else using proofs either. I'm a little surprised<br>by that, since that seems like the main point of this datastructure.<br>Curious if anyone has an explanation.</blockquote><br></div><div>Merkle proofs play a greater role in CT and SPV-based blockchain clients than they do in standard (height-based) blockchain verifications, see Thin-Client Security:</div><div><br></div><div><a href="https://en.bitcoin.it/wiki/Thin_Client_Security">https://en.bitcoin.it/wiki/Thin_Client_Security</a></div><div><br></div><div>Either way, all of the proof-stuff is implied by the authenticated connection to DNSChain (since it is speaking to the local namecoind). In other words, it is being used.</div><div><br></div><div><br></div><div><br></div><div>#### Reply to Zaki's comments</div><div><br></div><div><blockquote type="cite"><div dir="ltr">1. The inefficiencies of the proof of work scheme for block ordering in NameCoin are unlikely to remain relevant over the medium term. 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></blockquote><br></div><div>Their previous consensus algorithm was called TaPoS, or Transactions as Proof of Stake. I reviewed that and pointed out some issues to them.</div><div><br></div><div>Their new one is called Delegated Proof of Stake:</div><div><br></div><div><a href="http://bitshares.org/delegated-proof-of-stake/">http://bitshares.org/delegated-proof-of-stake/</a></div><div><a href="http://bitshares.org/intro-to-delegated-proof-of-stake/">http://bitshares.org/intro-to-delegated-proof-of-stake/</a></div><div><a href="https://bitcointalk.org/index.php?topic=558316.0">https://bitcointalk.org/index.php?topic=558316.0</a></div><div><br></div><div>I haven't yet had time to fully review it, but I'm sure there will be concerns with it as well. If anyone has reviewed it please comment with your thoughts!</div><div><br></div><div><blockquote type="cite"><div dir="ltr">2. While the blockchain data structure itself offers a high degree of cryptographic trust, it isn't appropriate structure for doing fast lookups. The current state of the art in bitcoin technology is to parse a blockchain and generate a derivative structure that supports fast response to a number queries. Either building a full SQL database of names, values, transactions etc or building a variety of key/value stores is common. What is lost in building derivative data structures is the underlying cryptographic trust, these query tables can only be trusted if built locally under the users control. Maintaining a locally built database is an expensive operation from both a bandwidth and storage point of view. Running a queriable bitcoin instance requires about 20GB for the blocks and up to 40gb for indexed data tables of ledger. The need to provided some sort of query interface in generic Blockchain 2.0 clients has been getting increasing attention in the last few months. </div></blockquote><br></div><div><a href="http://Chain.com">Chain.com</a> seems to be trying to address this issue, but it's a centralized solution and therefore I'm not terribly thrilled with it.</div><div><br></div><div>Libcoin uses sqlite to provide a queriable interface, but has the storage issue.</div><div><br></div><div>Storage and bandwidth issues can be completely solved with UTXO and/or a "rolling-root". UTXO seems best for dealing with Bitcoin. Am running out of time to find the links for this, but it's there in bitcointalk forums (search for sugarpuff's posts in the UTXO thread).</div><div><br></div></div><div><br></div><div><br></div><div>Thanks again Trevor for spinning off this discussion! Gotta hit the road again...</div><div><br></div><div>Kind regards,</div><div>Greg Slepak</div><div><br></div><div apple-content-edited="true"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">--</span><br style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">Please do not email me anything that you are not comfortable also sharing</span><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;"> with the NSA.</span></div><div apple-content-edited="true"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;"><br></span></div></body></html>