One comment I have noticed continually re-appear on social media over the last couple months is roughly the following:
If you’re building a new blockchain you should regularly take a hash of the network state and “anchor” it (write it) into another blockchain, for redundancy purposes.
This “anchor” idea has appeared in public material from BitFury, Factom, Tierion, Gil Luria and now 21inc (a VC-backed botnet operator).
Part of the current popularity in the anchoring meme is that some cryptocurrency enthusiasts and Bitcoin maximalists in particular want other non-cryptocurrency distributed ledgers to rely on existing cryptocurrency networks — networks that some enthusiasts own tokens to and hope that price appreciation will take place in the event that the network is used.
Ignoring the hypothetical monetary incentives, let’s assume that writing/storing network states externally is useful and it is the goal of every blockchain designers such as Bob and Alice. Are other blockchains the only relevantly secure places that all blockchain designers should look at using?
Probably not.
For instance, if the goal is to publish a hash of a state in a media that is difficult to censor and widespread enough to retrieve over time, then there are several “old school” newspapers and magazines that can be used for such purposes (which is what Guardtime does).
For instance:
- There are half a dozen Japanese newspapers that each have over 2 million in circulation.
- In the UK, both The Sun and Daily Mirror have a circulation of over 1.5 million
- Similarly, in the US, there are three companies: USA Today, The New York Times and The Wall Street Journal that also have a circulation of over 1.5 million
The question for the paranoid is, what is more likely: someone deliberately destroying and/or replacing 1.5 million newspapers which contain the hash of the network state, or someone knocking out 5,728 network nodes?
While “anchoring” the hash of state into other media may be useful, leaving it in just one blockchain — such as the Bitcoin blockchain — does not fully reduce the risk of a well-funded attacker trying to revise history. Safety in this case comes in numbers and if it is redundancy Bob and Alice are looking for (and paranoid about), it may be worth it to publish hashes in multiple venues and media.
Similarly, if sustainability is a key concern then public goods such as cryptocurrencies have a question mark on them as well. Why? Because there are over 100 dead altcoins now. Convincing users — and more importantly miners — to maintain a network when it is no longer profitable to do so is an uphill challenge.1
Lastly, a well designed network (or distributed ledger in this case) that is robust and mature should not necessarily rely on “anchoring” at all. But this dovetails into a different conversation about how to design a secure network, a topic for another post. Either way, hash-storage-as-service, is probably not the next big trillion dollar idea for 2016.
- It’s a challenge for any public good, not just Bitcoin, that eventually relies solely on altruism and charity. [↩]
I agree with Tim’s basic sentiment. The world already has a plethora of timestamping services and places to publish a hash. If your only utility is anchoring data in the blockchain, then you’re not providing much value. Customers are using Tierion to create a verifiable record of any data or business process. Anchoring data to the Bitcoin blockchain is just one element of providing customers with this capability. Guardtime is great for banks with deep pockets. There’s a whole world of other applications that can benefit from verifiable data.
It’s also important to note that use cases that relying on the long term storage of a hash in the blockchain are risky. The most well known example is Factom wanting to secure land titles. There’s no guarantee that the blockchain will contain the unadulterated copy of data stored in OP_Return in 40 years.
It is also worth clearing up another misconception: anchoring hashes of chain A into chain B doesn’t actually give chain B the full security of chain A. To see why, imagine that a 51% attack on chain B actually takes place and, from the point of view of raw hashpower on chain B, wins. What happens? If clients use the same block scoring mechanism as they do now, then the anchoring is useless; another approach is “subjective scoring” techniques where blocks are automatically treated as having a larger contribution to “total chain difficulty” if they appear on chain A earlier. However, this adds a vulnerability: a <51% attacker could publish hashes of blocks to chain A without publishing the actual blocks to the network, and thereby outrace the actual live chain (which users will perceive to be an attack chain). Second, note that the attacker could just publish hashes of the attack chain _before_ revealing the actual blocks to the network – this works regardless of the block scoring mechanism that is used. Both attacks at the very least provide denial of service, and at the most the latter attack can revert blocks.
Lesson 1 of blockchain scalability research: cryptoeconomically verifying "data availability", or circumventing the need to do so, is capital-H Hard.
Hi Tim,
I agree there are limitations yo pure notaries, however, Lightning does not use a hash published on the blockchain as some kind of “proof of existence” or notary service in the way described.
It uses a multisignature output, much like any other 2-of-2 multisig transaction, a significant distinction from the other examples (a transaction enforces consensus state, pure notaries do not).
The thing about anchoring is that it’s very cheap to add it, but it’s very expensive to defeat (if implemented properly). So adding it “for redundancy” is a good idea.
Publishing a hash in a public blockchain is very different from publishing it in a newspaper: blockchain-published hashes can be continuously and automatically monitored, while with newspaper-published ones you’ll have to rely on manual processes.
You can never have 100% security. Even if you follow the best practices, use hardware security modules etc, some freak accident can happen. For example, if all your nodes use the same HSM device, they might all be compromised at the same time. So additional security never hurts.
Software breaches are often zero-cost, in the sense that all they take is hacker’s labor or some rogue employee to hijack servers.
But anchoring is different: it’s impossible to rewrite Bitcoin blockchain history without spending money (on the scale of hundreds of millions now).
So it’s orthogonal to other security mechanisms and strictly adds to security.
Even if someone rewrote bitcoin’s history using a fork prior to the point in time when the hash was embedded, this does not entirely undermine the value of that hash. Why? Because you (or anyone else) can still show a copy of the blockchain ith the original fork, and this still proves that a certain amount of money was spent on mining after your hash, say $500,000 per day. In other words, that it would be very expensive for you to fake it. Of course the other fork can show the same thing, so this doesn’t solve the problem of contentious forks, but it does solve the problem of “proof of existence”. Enough to cause any technically competent court to seek a deeper explanation and not just say “the longest fork must be the truth”.