Many of you will know, or at the very least know of my HIVE(formerly STEEM)-first published mythpunk novel Ragnarok Conspiracy. The world where my novel is set in, is a postcrypocalyptic world where all currency, most importantly cryptocurrency, has lost its value as the direct and indirect result of a quantum blockchain heist in the year 2027.
Both prior to completing my novel, and after it, I've invested a lot of time researching the subjects of quantum computing and blockchain technology, and while when I wrote it, the scenario of a quantum blockchain heist was just as much out-there scifi as the return of the jǫtnar from Norse mythology, the day such a quantum blockchain heist could actually become a realistic possibility seems to be coming closer quite quickly.
So what is the problem with blockchain technology and quantum computing? Why is it so worrying that an actual cryptocalypse, like the one in my novel could actually end up happening in the not so distant future? Let's have a high level overview. I'll try not to deep dive too much into the technical details, but some technical depth is still called for. I hope the below strikes the proper balance.
Let's start with public key encryption. There are three concepts that matter there:
- private keys
- public keys
- signatures
- addresses
There is also encryption, but for the illustration of the problem, or for the specific crypto algorithms involved, encryption isn't actually all that relevant. Its just these four. Let us start with what for the algorithms involved with block chains like Bitcoin are operations that "without quantum computing" are possible:
- If you have the private key, you CAN derive the public key.
- If you have the public key, you CAN'T deriv the private key.
- If you have the public key, you CAN derive the address.
- If you have the address, you CAN'T derive the public key.
- If you have the private key, AND a transaction, you CAN create a signature
- If you have the signature AND the transaction, you CAN'T derive the private key.
- If you have the transaction AND the signature you CAN derive the public key.
- If you have the transaction AND the public key, you can't create a signature
- If you have the public key AND the signature AND the transaction, you CAN validate the signature
This is all great. Hope you are with me so far. The important thing is the "CAN'T"s here are as important as the "CAN"s.
The most important one here, for now is:
"If you have the public key, you CAN'T derive the private key"
When this premise fails, as it could if practical QC reaches about 1500 cubits of fast and resettable quantum computing, we might have a really big problem.
To illustrate this, we shall look how all of this is used in blockchains like bitcoin, first, by looking at what of this all will end up on the blockchain.
Threat model #1: Blockchain-exposed public keys
If you own a bit of Bitcoin and you want to transfer it to someone else, you:
- Take what is called an unspent output (USO) that is linked to one of your private keys, let's call this key PRIVATE1. This USO is linked to your private key because the address (let's call this one ADDRESS1) was used in an earlier transaction that is already on the chain.
- You create a new private key, let's call this key PRIVATE2 and from it derive its address ADDRESS2.
- You take the address of the person you want to send the bit of BTC to (ADDRESS3), the USO linked to ADDRESS1, your own ADDRESS2, and basically make the transaction say: I' the owner of ADDRESS1 want this USO to be split up into amount X payable to the owner of ADDRESS3, and I want my change to go to ADDRESS2.
- You sign this transaction with PRIVATE1 and after a bit of time the transaction is final.
From a high level view, so far everything is great. Even if the prime premise fails, PUBLIC1 isn't exposed on the blockchain while the initial USO remains unspent. There is just ADDRESS1, and for now the premise that PUBLIC1 can't be derived from ADDRESS1 isn't threatened by quantum computing.
But there is a problem. The scenario we just sketched hasn't always been adhered to. Let's see what happens if we change the scenario a tiny bit.
- Again take the USO linked to PRIVATE1
- Fail to create/use a new private key.
- Create a transaction like before, but now use ADDRESS1 as the address where you want your change to go to.
- You sign this transaction with PRIVATE1 and after a bit of time the transaction is final.
Now PRIVATE1 has two, not one things on the chain:
- A new USO with funds attached to it.
- A signature from what PUBLIC1 can be derived.
Now if we have a quantum computer with enough qubits, PRIVATE1 could be reconstructed from PUBLIC1, and an adversary could use this reconstructed PRIVATE1 key to steal your funds.
These funds could have been sitting there for many years. In fact, there are quite some rather large and rather old USOs on the bitcoin blockchain that haven't moved for many-many years. If bitcoin moved to using quantum resistant signatures tomorrow, chances are much of the old exposed USO's will still be sitting there when QC becomes powerful enough to launch an attack against them.
You may thing: who cares, my funds are safe, I've never re-used any private keys ? But thinking so is naive. There exists zero market separation between BTC sitting in exposed-pubkey USOs vs non-exposed-pubkey USOs, so when someone with a quantum computer gets his hands on a large stash of exposed-pubkey funds and starts selling off his spoils, this will directly affect the price and value of BTC. Then, when it becomes clear the amount of funds from exposed-pubkey USOs isn't Satoshi Nakamoto himself selling off some of his stash, but is the likely result of a quantum blockchain heist, much of the market won't grasp the nuances of exposed vs unexposed USOs, or old pre-QC resistant vs QC resistant signatures, all they will see is that a quantum blockchain heist happened and that measures apparently hadn't worked. The price of BTC would likely collapse and it's questionable if BTC could ever recover in terms of reputation if something like this were to happen.
Threat model #2: Attacks against unconfirmed or under-confirmed transactions
While the above attack factor is arguably the most disruptive and unstoppable at the moment, there is a second attack factor that is very important for the future of blockchain technology.
Imagine a blockchain like Bitcoin, but one where private keys are never, have never and will never be reused. You would think, maybe, that then everything would be fine, as no public key is ever exposed on the blockchain until the USO that it is attached to is spent anyway.
Well, guess what, that is almost true, but the devil is in the details. When you send out a transaction for inclusion in the blockchain, there is an important aspect of the transaction we haven't yet discussed. That aspect is the transaction fee. Fully discussing transaction fees fals outside of the scope of this blog post. The important thing to realize is that your transaction won't be final until it has been confirmed a number of times, and that time window combined with the fact that transactions that set a higher fee will likely be included in a block and be confirmed faster than transactions that have a normal fee set.
Let's walk through an attack that exposes.
- Like before, you create a transaction from your USO, set part of the funds to go to your friend, the owner of ADDRESS3, and the other part to the ADDRESS2 you just created. You set a normal transaction fee on your transaction.
- The attacker snoops your transaction and extracts the public key from the transaction and it's signature.
- The attacker, using a QC attack, converts PUBLIC1 to PRIVATE1
- The attacker creates his own transaction for the exact same USO transfering most of the funds to ADDRESS4. An address that he owns. Now instead of setting a normal transaction fee, the attacker sets a rather high transaction fee and submits his transaction.
- Now your transaction and the one of the attacker are competing. The USO can be spent only ones, and your transaction had a little head start in terms of time. The attackers' transaction though has a high transaction fee set, making it likely his transaction would end up on the blockchain instead of yours.
$QRL and quantum resistant signatures.
QRL is a blockchain just like Bitcoin, but one that uses signatures that don't suffer from the (future) QC vulnerability that bitcoin signatures suffer from, that most blockchains today suffer from. If you currently own bitcoin or any other cryptocurrency, hedging your crypto holdings with 10%..20% $QRL is probably a really good idea. If trust in ECDSA blockchains comes crumbling down in the case of an actual quantum blockchain heist, or the public knowledge of the existence of a practical >1500 qubit quantum computer, at least when it happens before blockchain based market isolation as described in the below sections becomes a reality, $QRL (or other new coins like it) will likely be on top of things. $QRL and $BTC could swap places in terms of market capitalization over night.
Could the signatures $QRL uses safe $BTC from a cryptopocalypse like the one in Ragnarok Conspiracy ?
Partially.
It could protect BTC, part of BTC, against attacks against unconfirmed or under-confirmed transactions as described in the previous section. But then, only those unspent outputs that were created after the move to the quantum resistant signature scheme. Next to this, it wouldn't protect the sitting-duck exposed-pubkey USOs at all.
Because of this, it's probably a really good idea to hedge with $QRL even if $BTC implements quantum resistant signatures tomorrow.
$HIVE and multi-coin on-chain market isolation
HIVE at the time of speaking isn't particularly quantum resistant. In fact, key-reuse isn't just a fundamental part of the design of HIVE, the actual public keys are sitting there in the open on the chain, available for everyone through the public JSON-RPC API servers. So why look at HIVE at all for a solution to Bitcoin's QC resistance problems?
HIVE comes with a number of features and design decisions that could help HIVE itself move to a quantum resistant future, but more than that, these features and design artifacts, when applied to bitcoin would, together with the use of the technology currently used in $QRL, could potentially help fix Bitcoin enough for it to survive a large scale quantum computing attack in the future. Let's look at the features first, and look at how these could fit together.
Multiple coins on one chain.
One very interesting feature the HIVE blockchain features is that it has two coins on a single chain. Not one real coin and a whole lot of tokens, but two equal peer coins that are a fundamental part of the architecture. $HIVE and $HBD. The reason HIVE has these two coins has nothing to do with Quantum Resistance, but it's a feature we will see below could have use for QR if applied to for example Bitcoin.
Blockchain embedded conversion.
One important feature that HIVE implements that Bitcoin requires for effectively using the multiple coins on one chain paradigm as a market isolation mechanism that is politically more acceptable than simply forking out long-time exposed funds, is embedded conversion.
HIVE has blockchain embedded conversion from $HBD to $HIVE. In $HIVE this is meant as part of the $HBD pegging mechanism for pegging $HBD to the US dollar. Its use will be quite different for Bitcoin, but the technology needed it essentially the same.
Blockchain embedded market.
An other feature that HIVE has implemented for its multi-coin chain solution is an on-chain exchange for its single $HIVE/$HBD trading pair. This too for HIVE is an important part of its HBD pegging strategy/ This too is a feature Bitcoin would need in order to effectively leverage the multi-coin chain concept for a quantum computing roadmap.
Putting it all together
The first important step would be obvious. Add quantum resistant signatures to bitcoin. HIVE most definitely needs those too, but that's a subject for another post. $QRL showed us how to tackle this, BTC and HIVE could tackle this too, but doing so isn't enough.
Imagine tomorrow BTC supports quantum resistant signatures like $QRL does. From the moment people start using these signatures, effectively there will be three types of transactions.
- Transactions involving USOs linked to exposed non-RQ signatures.
- Transactions involving USOs not linked to exposed non-RQ signatures, using a non-QR signature
- Transactions involving USOs not linked to exposed non-RQ signatures, using a QR signature
Whether it is possible to find a solution for Bitcoin that can do away with #2, by allowing non-exposed ECDSA private keys to be used for quantum resistant signing, is something I'm not sufficiently read in for into the subject of quantum resistant signatures. My below proposal for HIVE-modeled, multi-coin on-chain market isolation for bitcoin assumes we can't.
HIVE-modeled, multi-coin on-chain market isolation for bitcoin
Consider these three types of transactions to be transactions using three different coins
Consider only the last one to be $BTC and the other two to be alternate coins living on the same chain. Now consider that some point in time after the introduction of QR-signatures into bitcoin, Bitcoin gets a hard fork, and all funds existing on the ledger are assigned a coin.
- $BTC : Real bitcoin, living in QR-signed USOs at time of hard fork.
- $BTC-l : Legacy bitcoin, living in non-QR-signed USOs at time of hard fork, linked to address with a pubkey NOT exposed through a previous on-chain signature.
- $BTC-e : Exposed Bitcoin, living in non-QR-signed USOs at time of hard fork, linked to address with a pubkey EXPOSED through a previous on-chain signature.
As mentioned, $BTC and $BTC-l might end up all just being $BTC if private keys end up being interchangeable between signature algorithm.
Decay rates
Now we take the HIVE blockchain embedded conversion feature and apply it in a way where block-chain built-in exchange rates decay over time. Imagine a hard fork on January 1st 2022. We say $BTC-l and $BTC-e can both be converted by the blockchain to $BTC. At first at a 1.0 exchange value. Now what we do is we introduce a decay rate for the blockchain built-in conversion.
- 0.2% decay per day for $BTC-l to $BTC conversion.
- 0.3% decay per day for $BTC-e to $BTC conversion.
Now if we look one year into the future, $BTC-l and $BTC-e would see their value decay quite quickly if the on-blockchain conversion was all there was.
- $BTC-l: 0.998^365 = 48%
- $BTC-e: 0.997^356 = 33%
The market decides.
But this shouldn't be the final word. In the end the markets should decide just how serious the threat of QC should affect the price of $BTC-l and $BTC-e. For this, a blockchain built-in market with all three trading pairs, like the one $HIVE has for trading $HIVE for $HBD on-chain without the need for an exchange, should make sense. The market decides just how much the exposed-pubkey risk matters, and when a quantum blockchain heist hits the blockchain, market isolation should protect $BTC from immediate devaluation of either $BTC-e, $BTC-l or both.
For now, hedge your crypto's
Bitcoin currently has a market cap of almost €300,000,000,000. $HIVE is at about €40,000,000, $QRL at about €7,500,000. While I think $BTC is fixable, and could get fixed in time using a combination of QR signatures and a HIVE-like solution for multi-coin on-chain market isolation, its probably not wise to assume it will. There are other coins that would be much less problematic to fix, and $QRL is there, currently at a market cap of 0.025% of that of $BTC, ready to be our hedge against the cryptopocalypse.
Sure, like in my novel, industrial espionage is likely to be the more lucrative of clandestine types of usage of quantum technology in the future, but the risk is still very real. Hedge whatever crypto you choose with $QRL, at least untill major coins like $BTC come with real fixes, not just for future transactions, but also for old ones that leave funds exposed on the chain.
For me: $HIVE, $QRL, $ZEC
Personally I've gone $BTC minimalist for now; 0.000000 BTC, and I'm hedging my $HIVE with two coins I feel hold promise. $QRL and $ZEC. $QRL for obvious reasons, and $ZEC because I feel Zero Knowledge Proof, the math underlying this anonymity, could be part of the technology stack needed for the parts of the blockchain ecosystem that relies on key-reuse in a fundamental way. That includes HIVE, but also amazing block chain technology such as the FlureeDB blockchain based triple-store database.
Light reading
If this blog post makes you nervous about your crypto holdings, great, act on it, hedge your $BTC or $ETH with $QRL. Hedge your HIVE or other key-reusage blockchain technology with $QRL and $ZEC. If you can convey your nervousness with core developers working on your favorite crypto's and convey the need for both QR signatures and multi-coin on-chain market isolation.
If other than make you nervous, this blog post made you interested in doing some light reading involving the subject discussed here in a more lighthearted way in the context of some out-there sci-fi fiction, consider getting a copy of my e-book Ragnarok Conspiracy, currently available at 50% off.
