<story><title>On the dangers of a blockchain monoculture</title><url>https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture</url></story><parent_chain></parent_chain><comment><author>nickpsecurity</author><text>Refreshing to see a critique talking alternatives instead of another fanboy post on Bitcoin&amp;#x27;s blockchain. Monoculture is a good word for it. Almost all the research and attention is going in one direction when there are &lt;i&gt;many&lt;/i&gt; valid directions worth exploring with &lt;i&gt;fewer&lt;/i&gt; issues than Bitcoin. Some leverage proven approaches in finance, databases, or transaction processing. Just need extensions, more analysis, open implementations, etc.&lt;p&gt;So, I look forward to more articles like this to draw attention to solutions other than Bitcoin architecture. Another thing I look forward to are links to interesting alternatives like SCP and Interledger in this. I haven&amp;#x27;t reviewed them yet but brief descriptions seemed more exciting than &amp;quot;Cut-and-Pasted-Coin launched yesterday while promising to change the world.&amp;quot;</text></comment>
<story><title>On the dangers of a blockchain monoculture</title><url>https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture</url></story><parent_chain></parent_chain><comment><author>geofft</author><text>It took me a while to understand why Certificate Transparency is sound without requiring proof-of-work, and Bitcoin is not, but the answer turns out to be fairly simple: you can merge two CT log entries without conflicts, but you can&amp;#x27;t merge two Bitcoin transactions. If I want to log &amp;quot;Certificate A exists for bitcoin.org&amp;quot; and you want to log &amp;quot;Certificate B exists for mtgox.com&amp;quot;, both of our data items are valid on their own (and can be independently verified, just by checking the signature on the cert) and the ordering doesn&amp;#x27;t matter. So as soon as a write goes to &lt;i&gt;some&lt;/i&gt; log server, as long as I trust the log server to propagate writes via the gossip protocol, I&amp;#x27;m done; I don&amp;#x27;t need to care about merges or retries. (Also, it&amp;#x27;s possible for the log server to send me a signed promise to propagate writes, that I can later use to prove its misbehavior if that entry never shows up.)&lt;p&gt;On the other hand, if I have a transaction &amp;quot;Transfer 1 BTC to bitcoin.org&amp;quot; and you have a transaction &amp;quot;Transfer 1 BTC to mtgox.com&amp;quot;, they don&amp;#x27;t necessarily commute or merge because of the double-spend problem: they might both be trying to spend the same 1 BTC.&lt;p&gt;There are a number of nifty decentralized systems you can build that don&amp;#x27;t have to think about double-spend problem, where all transactions commute&amp;#x2F;merge. Associating names with public keys &lt;i&gt;seems&lt;/i&gt; to be one of them, as long as you allow a name to be validly bound to multiple keys. (A Keybase-style binding of external service usernames to public keys would permit this, since you simply have multiple valid Keybase proofs; the external usernames are arbitrated by the various centralized services. A Namecoin-style approach doesn&amp;#x27;t, since names are first-come-first-serve, and you don&amp;#x27;t want multiple people to be served the same name.)&lt;p&gt;There appear to be ways to make a money-transfer system avoid the double-spend problem: as I understand Stellar, it simply just makes the spending account legitimately owe both people money (and puts limits on how much each link can transfer at a time, so that the money is actually recoverable). But for non-money-transfer systems, if you can arrange your problem statement such that double-spending isn&amp;#x27;t a concern in the first place, you can use regular Merkle trees and avoid the entire proof-of-work overhead.</text></comment>