Thesis
Thesis
Thesis
Supervisor:
Prof. William Knottenbelt
Author:
Dragos Ilie (dii14)
Second Marker:
Prof. Kin Leung
I would like to start by thanking Research Associate Iain Stewart of the Cryptocur-
rency Research Centre at Imperial College London, for numerous clarifications and
discussions, without which this work would not have been possible. He consistently
contributed to deepen my understanding on the subject while allowing me to focus
on whichever aspect of the work I wanted.
I would also like to express my sincere gratitude to my thesis supervisor Prof.
William Knottenbelt for his continuous support, for pushing me to publish the
theoretical part of this work in the Royal Society Open Science Journal, and most
importantly, for encouraging me to pursue a PhD. degree. His availability in helping
me was really far beyond expectations.
Furthermore, I would like to thank PhD. students Alexei Zamyatin and Sam
Werner with whom I have co-authored the aforementioned journal paper. Together,
we gracefully overcame the various challenges encountered, thus producing an ele-
gant solution.
Finally, I must convey my absolute appreciation to my parents and girlfriend for
their inexhaustible support and unceasing encouragements throughout this venture.
1
Contents
1 Introduction 4
1.1 Problem and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 7
2.1 Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Elliptic Curve Arithmetics . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Elliptic Curve Public-Private Keys . . . . . . . . . . . . . . . 13
2.1.3 Elliptic Curve Digital Signature Algorithm (ECDSA) . . . . . 13
2.2 Some Cryptographic Primitives Used In Bitcoin . . . . . . . . . . . . 15
2.2.1 Cryptographic Hash functions . . . . . . . . . . . . . . . . . . 15
2.2.2 Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Bitcoin Network . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3 Bitcoin Transactions . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.4 Transaction Lifecycle . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Quantum Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Mathematical Framework . . . . . . . . . . . . . . . . . . . . 29
2.4.2 Basics of Quantum Theory . . . . . . . . . . . . . . . . . . . . 33
2.4.3 Quantum Algorithms . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Post-Quantum Cryptography . . . . . . . . . . . . . . . . . . . . . . 41
3 Post-Quantum Bitcoin 44
3.1 Attacks on Proof Of Work (PoW) . . . . . . . . . . . . . . . . . . . . 44
3.2 Attacks on ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1 Public key unveiling . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.2 Live Transaction Hijacking . . . . . . . . . . . . . . . . . . . . 47
3.3 Estimated Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Hindering Transition to Quantum Resistance . . . . . . . . . . . . . . 49
2
CONTENTS
5 Implementation 59
5.1 Quantum Resistant Signatures . . . . . . . . . . . . . . . . . . . . . . 59
5.2 QRWit Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.1 Commit Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.2 Reveal Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.3 Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . 68
5.2.4 Version Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6 Related Work 70
6.1 Johnson Lau’s Two-Stage Commitment . . . . . . . . . . . . . . . . . 70
6.2 Tim Ruffing’s Committed Transaction . . . . . . . . . . . . . . . . . 71
6.3 Fawkescoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7 Evaluation 73
7.1 Theoretical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Implementation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2.2 Manual Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8 Future Work 79
8.1 Commit Multiple Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.1 Merkle Pair-Tree . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2 Flexible Commitment Structure . . . . . . . . . . . . . . . . . . . . . 81
8.2.1 User-Configurable Commitment Location . . . . . . . . . . . . 81
8.3 User-Configurable Delay . . . . . . . . . . . . . . . . . . . . . . . . . 81
9 Conclusion 84
3
Section 1: Introduction
In this paper we approach the issue of integrating Bitcoin in a post-quantum world.
One of the aspects, for which Bitcoin is regularly praised is the security guarantees
it offers. However, with recent developments in the quantum computing research
area, it appears that one of the core cryptographic primitives, on which the whole
security model relies, is highly vulnerable. However, the system was designed in
such a modular and extensible fashion, that it can be smoothly recovered with little
modifications to the existing system.
In this paper we offer a protocol update called QRWit (QuantumResistantWit-
ness), as inspired by SegWit [40]. We propose a three stage, commit–delay–reveal,
scheme that allows Bitcoin users to safely spend their non-quantum-resistant funds
and secure them under a quantum-resistant cryptosystem.
Quantum computers (QCs) theoretically appeared about 40 years ago, but rel-
atively recent breakthroughs have placed the idea in the public eye once again. One
such breakthrough, with a direct impact on Bitcoin’s security, is Peter Shor’s poly-
nomial time quantum algorithm [60], which in its subsequently generalised form can
break ECDSA. Although the early generations are not scalable enough to affect Bit-
coin, various alternatives for the architecture of QCs are being considered, tested
4
1.2. CONTRIBUTION
and implemented [69, 22, 68]. As more entities enter this growing research area,
it seems increasingly likely that powerful QCs will emerge in the near future. A
sudden improvement in the approach towards scaling might lead to a powerful QC
appearing virtually overnight.
To this end, the Bitcoin community must be prepared to transition to a quantum-
resistant signature scheme. Post-quantum cryptography is an area of research with
substantial history and many different approaches are still being pursued and con-
sidered. Although such cryptosystems exist theoretically, not many satisfy the low-
bandwidth, space efficiency, and scalability requirements of Bitcoin. Furthermore,
even if a suitable quantum-resistant signature scheme is found and deployed in Bit-
coin, the issue of safely transferring ECDSA protected funds to the new signature
scheme remains. In particular, the scenario in which the transition has to be done in
the presence of quantum-capable adversaries must be taken into consideration and
solutions to overcome this problem must be developed as soon as possible.
1.2 Contribution
On these grounds, a protocol that allows Bitcoin users to safely consume funds
backed by ECDSA even in the presence of a quantum-capable attacker, should be
proposed. Consequently, we propose QRWit, a commit–delay–reveal protocol for
the secure transition from Bitcoin’s current signature scheme to a quantum-resistant
analogue, applicable even if ECDSA has already been compromised. Independent of
quantum computing, QRWit can be generally applied to react to the appearance of
any other vulnerabilities rooted in Bitcoin’s public-key cryptography. Furthermore,
unlike other proposals, we emphasise the necessity of a substantial delay phase to
provide strong guarantees against adversarial chain reorganisations.
We would like to note that the theoretical work we present here has already
been redacted in a paper co-authored with members of the Cryptocurrency Research
Centre of Imperial College London [62]. The paper has already been accepted for
publication in a special issue of the Royal Society Open Science journal on Blockchain
technology and is due to appear shortly after this work is submitted.
In support of our theoretical work and analysis, we have developed a prototype
implementation for QRWit, which we describe in detail in Section 5. We will show
how the changes we propose can be implemented as a soft fork using a similar
approach as, for example, SegWit [40].
5
1.3. OBJECTIVES
1.3 Objectives
At the beginning of the project, we set the following goals. To clear away any
suspense and to calm the reader’s curiosity, we will also mention in what proportion
we managed to achieve them.
1. Develop a scheme that can safely transition ECDSA secured funds to quantum
resistance. This goal was certainly achieved as we will show throughout this
paper.
2. Publish a paper on this scheme. We set this goal because we noticed that
there are no other papers or well defined proposals for how to solve this dire
problem. As mentioned, we achieved this, as our paper [62] was accepted for
publication.
The remainder of this paper is organised as follows. Section 2 presents the back-
ground knowledge necessary to understanding the core problem and the solution. In
particular, we give a somewhat formal and extensive introduction to elliptic curve
cryptography, quantum computing, Bitcoin, and post-quantum cryptography. In
Section 6, we present all the alternative proposals of which we became aware while
working on this project. Having covered the basic theory, we are in a position to
fully describe the impact QCs have on Bitcoin (i.e. vulnerabilities uncovered, attack
models and their feasibility), in Section 3. Consequently, in Section 4 we propose a
protocol for the transition from Bitcoin’s ECDSA to a quantum-resistant signature
scheme and address certain concerns that the community might have (e.g. costs,
flexibility, time frame). The specific prototype implementation demonstrating the
workings of our protocol is given in Section 5 and its effectiveness, correctness, and
scalability is assessed in Section 7. Furthermore, we present some extension possibil-
ities and specific optimisations that will improve the overall usability of the scheme
we suggest, in Section 8. Finally, we conclude this report with Section 9.
6
Section 2: Background
In this section we briefly present the basic concepts needed to understand the rest
of the material. We will use these building blocks to explain the problem our work
is aiming to solve and, in doing so, we will construct a clear image of the threats
that quantum computing is posing to Bitcoin.
Firstly, we will take a look at elliptic curve cryptography which is the mechanism
that ensures Bitcoin users maintain control of their funds and which is the main
vulnerability from the point of view of a quantum-capable attacker. Secondly, we
will go over the main aspects of Bitcoin that are relevant to understanding the
problem and our solution. Then, we will cover the basics of quantum computing
and give two examples of quantum algorithms that are of interest in the context of
this paper. Finally, we will present some alternatives to elliptic curve cryptography
that are believed to be secure even in the face of quantum computers.
Public-key cryptography is the first cryptosystem that relies on number theory rather
than simple substitutions or permutations. Such cryptosystems are intrinsically
asymmetric, requiring the use of two keys to encrypt and decrypt, thus providing a
solution to the problem of secret key sharing. The concept was publicly introduced
in 1976 by Whitfield Diffie and Martin Hellman [24] and one year later Ron Rivest,
Adi Shamir and Len Adleman leveraged the intractability of factoring large integers
to realize the first practical implementation: the RSA cryptosystem [55].
Elliptic curve cryptography (ECC) is a form of public-key cryptography devel-
oped in 1985 by Neal Koblitz and Victor Miller [37]. While it provides the same
functionality as RSA, ECC’s security relies on another hard mathematical problem:
the elliptic curve discrete logarithm problem (ECDLP). At the moment, the most ef-
ficient known classical algorithms for solving ECDLP have fully exponential runtime
complexity [44] which is an improvement over the subexponential-time algorithms
that can factor large integers [39]. Thus, the same level of security can be achieved
with smaller keys in elliptic curve systems than in RSA. As smaller key sizes imply
a more efficient use of power, bandwidth, and storage, many applications, including
Bitcoin, make use of ECC.
The remainder of this section is based on Darrel Hankerson’s, Alfred Menezes’,
and Scott Vanstone’s book "Guide to Elliptic Curve Cryptography" [30].
7
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
2. Associativity: a ⋆ (b ⋆ c) = (a ⋆ b) ⋆ c ∀a, b, c ∈ G.
⟨g⟩ = {g i : 0 ≤ i ≤ t − 1}
of all powers of g is itself a group under the same operation as G, and is called the
cyclic subgroup of G generated by g.
Definition 5 (Field)
A field is a set F together with two operations, addition (denoted by +) and multi-
plication (denoted by ·), that satisfy the usual arithmetic properties:
As for groups, the field is said to be finite, if the set F is finite. The order of the
field is the number of elements in set F .
8
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
Informally, this means that any finite fields of order q has the same structure of
elements (maybe the labelling differs). Hence, we say that any two finite fields of
order q are isomorphic and denote such a field by Fq .
Definition 6 (Subfields and Extension fields)
A subset k of a field K is a subfield of K if k is itself a field with respect to the
operations of K. In this instance, K is said to be an extension field of k.
Definition 7 (Elliptic Curve)
An elliptic curve E over a field K is defined by an equation
E : y 2 + a1 xy + a3 y = x3 + a2 x2 + a4 x + a6
where a1 , a2 , a3 , a4 , a6 ∈ K and ∆ = −d22 d8 − 8d34 − 27d26 + 9d2 d4 d6 = 0 with
d2 = a21 + 4a2 , d4 = 2a4 + a1 a3 , d6 = a23 + 4a6 ,
d8 = a21 a6 + 4a2 a6 − a1 a3 a4 + a2 a23 − a24
If L is any extension field of K, then the set of points on E is
E(L) = {(x, y) ∈ L × L : y 2 + a1 xy + a3 y − x3 − a2 x2 − a4 x − a6 = 0} ∪ {∞}
where ∞ is the point at infinity.
Remark 2 (Comments on Definition 7)
1. The equation of an Elliptic Curve is called a Weierstrass equation.
2. E is defined over K because the coefficients a1 , a2 , a3 , a4 , a6 of its defining equa-
tion are elements of K. Note that if E is defined over K, then E is also defined
over any extension field of K, by Definition 6.
3. The condition that ∆ = 0 ensures there are no points at which the curve has
more tangent lines.
4. The point ∞ is the point at infinity and it lies on any vertical (parallel with
the line of equation: x = 0).
5. The points on E are the points (x, y) that satisfy the equation of the curve and
whose coordinates are in L. ∞ is considered a point on all extension fields L
of K.
Definition 8 (Simplified Weierstrass equations)
Two elliptic curves E1 and E2 defined over K are said to be isomorphic over K if
∃u, r, s, t ∈ K, u ̸= 0, such that the change of variables in the respective Weierstrass
equations:
(x, y) → (u2 x + r, u3 y + u2 sx + t)
transforms equation E1 into equation E2 . This transformation is called an admis-
sible change of variables.
9
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
Due to Definition 8 we can drastically simplify the elliptic curve equation. De-
pending on the characteristic of the field K there are three simplifications that can
be made. If the characteristic of K is not equal to 2 or 3, then the admissible change
of variables:
( )
x − 3a21 − 12a2 y − 3a1 x a31 4a1 a2 − 12a3
(x, y) → , −
36 216 24
x x
Figure 2.1: Two elliptic curves over the infinite field (R, +, ·), i.e. the real numbers.
10
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
2. For a point P = (x, y), the point P ′ = (x, −y) is called the negative of P , i.e.
P = −P ′ and their addition is, as expected, the identity element ∞.
y y
P+R
b
P b
b
P
b
R
b
b
b
x R
b
x
2P
2P b
b
-P
b
P+R -P
b
b b
11
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
To give a formal description for the operation above we define the elliptic curve
group law:
Definition 10 (Elliptic Curve Group Law)
The group operation on points of E is represented by ’+’ and is defined as follows.
If P ∈ E then P + ∞ = ∞ + P = P as ∞ is the identity element.
If P = (x1 , y1 ), R = (x2 , y2 ) ∈ E then:
{
∞ when (x2 , y2 ) = (x1 , −y1 ),
P +R=
(x3 , y3 ) otherwise,
Using all the above theory, we are finally in a position to introduce the elliptic curve
discrete logarithm problem, whose hardness is crucial for the security of any elliptic
curve cryptographic scheme. The ECDLP belongs to a class of problems called the
Hidden Subgroup, hence we will first show what this subgroup refers to by noticing
the following:
Remark 4 (Elliptic Curve subgroup of P)
Given an elliptic curve E defined over a finite field Fq and the elliptic curve group
law denoted as +, we can define the abelian group (E(Fq ), +). In respect to this
group, we have from Definition 3 any point P ∈ E(Fq ) is a generator of a cyclic
subgroup ⟨P ⟩ of some order n.
Definition 11 (ECDLP)
For some Q ∈ ⟨P ⟩, find the integer l ∈ [0, n − 1] such that Q = P l = |P + .{z
. . + P}.
l
The integer l is called the discrete logarithm of Q to the base P , denoted l = logP Q.
2. We should note that there is no proof that the ECDLP is intractable, but there
is no publicly known efficient algorithm that can solve it.
12
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
3 for i ← 0 to t − 1 do
4 if ki = 1 then
5 Q←Q+P
6 P ← 2P
7 return Q
The time complexity of this algorithm is O(t) = O(log2 n) which is definitely tractable.
Furthermore, if the point P is known beforehand, there are algorithms which use this
knowledge to pre-compute a table of powers of p which can then be used to speed up
the algorithm even more.
ECDSA is a scheme based on elliptic curve cryptography that implements the Dig-
ital Signature Standard (DSS) [13]. The purpose of signature schemes is to replace
handwritten signatures, or, in the context of digital signatures: to provide authen-
tication, integrity, and non-repudiation. Digital signatures are closely related to the
concept of private and public keys. A signature created with some private key will
be correctly verified only by the corresponding public key.
13
2.1. ELLIPTIC CURVE CRYPTOGRAPHY
The relevant algorithms for constructing and validating ECDSA signatures are
given below. Note that in the following two algorithms, H is a cryptographic hash
function whose outputs have bitlength no more than that of n.
Algorithm 2: ECDSA Signature Generation
Input : private key d, message m, P, n
Output: signature (r, s)
1 Select k ∈ [1, n − 1].
′
2 Compute kP = (x1 , y1 ) and convert x1 to an integer x1 .
′
3 Compute r = x1 mod n.
4 if r = 0 then
5 go to step 1
6 Compute e = H(m).
7 Compute s = k −1 (e + dr) mod n.
8 if s = 0 then
9 go to step 1
10 return (r, s)
14
2.2. SOME CRYPTOGRAPHIC PRIMITIVES USED IN BITCOIN
This section introduces some cryptographic primitives used in Bitcoin that are es-
sential to understanding the rest of the paper as we make use of them regularly.
Definition 14
An ideal cryptographic hash function H takes an input of any size and returns an
output of predefined size. Furthermore, it must exhibit the following properties:
1. Deterministic - It produces the same result for the same input, regardless of
any other factors.
3. Butterfly Effect - A small change to the input changes the output completely.
Remark 9
The last two properties of definition 14 are both required because they protect against
different types of possible vulnerabilities. Collision resistance protects against special
types of messages which can be modified in a way that will yield the same hash. On
the other hand, second pre-image resistance refers to the more specific case in which
a message is already known and a second message with the same hash is wanted.
15
2.2. SOME CRYPTOGRAPHIC PRIMITIVES USED IN BITCOIN
In Bitcoin there are a few important hash functions that are used to offer im-
mutability guarantees. Hashing a piece of data is a common practice for creating a
fingerprint of the data. If even one bit of the data would change the hash would be
completely different.
SHA256 is a secure hash algorithm (SHA) part of the SHA-2 family of cryp-
tographic hash functions designed by the National Security Agency (NSA) and is
believed to be an ideal cryptographic hash function, satisfying all the required prop-
erties. It returns outputs with exactly 256 bits.
Merkle Trees were patented in 1979 by Ralph Merkle [45]. They are trees in which
each leaf is some block of data and each non-leaf node is the hash of the concatenation
of its children. An example of this is in Figure 2.3 below.
H(HAB ||HCD )
A B C D
Proof of Existence
An interesting property of Merkle trees is the fact that we can construct proofs that
some data is present in the Merkle tree without actually transmitting the whole
structure. The proof creators need all the data in the leaves in order to create
16
2.2. SOME CRYPTOGRAPHIC PRIMITIVES USED IN BITCOIN
proofs, but the verifiers only need to have a trusted value for the root node in order
to be completely convinced that some data exists in the tree. Although the proof
creator can simply deny answering a proof request, he cannot trick the requester by
providing a misleading proof as this would involve breaking the pre-image resistance
of H. Such proofs are also called Merkle branches, because they essentially provide
all the information needed to recompute one branch of the tree from leaf to root.
HABCD
HAB HCD
A B C D
Figure 2.4: The data that needs to be proven to be in the merkle tree is in red.
The merkle branch to prove this is depicted in blue. The verification requester can
compute the brown values from the blue and red values, thus being able to check
that the value of the root matches the trusted value he owns.
Below we give the algorithm that a proof creator would use to generate the proof
that some node exists.
Algorithm 4: Merkle Tree Branch Construction
1 function constructBranch(node)
2 if node is root then
3 return ([], [])
4 end
6 (hashes, bits) = constructBranch(node.parent)
7 hashes.append(node.sibling)
8 bits.append(node is on the right)
9 return (hashes, bits)
The algorithm starts at the leaf we want to prove appears in the merkle tree and
builds a list of sibling hashes, marking at each step whether the sibling was on the
left or on the right.
Next we give an algorithm that verifiers could use to check the correctness of
some existence proof. Note that, they must already be in possession of the root
value as otherwise they would have nothing to match against.
17
2.3. BITCOIN
The algorithm starts from the data we required verification of and computes suc-
cessive hashes using the provided sibling at each step. When it runs out of siblings,
the full root should have been constructed, so a comparison with the trusted value
of the root is done.
2.3 Bitcoin
This section gives a high-level overview of Bitcoin, while focusing with some more
detail on the aspects which are specifically important to our work. One can find a
more complete description of Bitcoin in Andreas M.Antonopoulos’ book "Mastering
Bitcoin" [15], on which this section is based.
Bitcoin can be described as a set of standards, ideologies, protocols and tech-
nologies that form the basis of a decentralized currency system. The units of dig-
ital money are called bitcoins and their ownership can be handed over to other
participants through transactions. Users communicate to each other, broadcasting
transactions, via a peer-to-peer network over the Internet. Transactions are aggre-
gated together into blocks which are appended to a distributed public ledger called
the blockchain. To avoid a central authority that issues new blocks, any consen-
sus participant can append a new block after completing a cryptographically hard
puzzle. Each block also contains the hash of its predecessor, thus providing strong
guarantees for the immutability of the transaction history.
For the purpose of this section, it can be assumed that transactions are just chunks
of data of arbitrary lengths. The blockchain structure is an ordered list of blocks of
transactions where each block links to its predecessor by referring to its hash in the
block header. We shall first define some basic terms in Bitcoin.
Definition 15 (Block Reward)
The block reward is a diminishing amount of newly created currency that is awarded
to miners that successfully append a block to the blockchain. The block reward halves
18
2.3. BITCOIN
every 210,000 blocks. It started at 50 Bitcoins and is now at 12.5. Apart from this
reward miners also collect the fees associated to transactions in a block.
Block
Each block in the blockchain contains all the transactions included in that block, a
block header and some meta-data (see table below).
19
2.3. BITCOIN
yield a shorter chain than the original one so other consensus participants would
immediately disregard it. As the blockhash is sensible to changes in the merkle tree
root of all transactions in a block, this implies that any change to any transaction
in a block would require recomputing all the blocks on top of the altered one. This
hash chain goes all the way back to the first block ever created, also known as the
genesis block.
The first block that was ever created in Bitcoin is called the genesis block. It was
created in 2009 and was statically encoded within the Bitcoin client software. Its
purpose is to serve as a trusted root for all participants to build the blockchain upon.
This block only contains one transaction that created the first units of Bitcoin ever.
Mining serves to protect users against fraudulent transactions (eg.: double spend-
ing), and to create a consensus on the current main chain. Miners validate new
transactions and record them in blocks. A new block gets added to the blockchain
approximately every 10 minutes. For donating their computational power to validate
transactions, miners are rewarded in two ways: transaction fees and block rewards.
However, in order to publish a block to the blockchain, miners compete to solve a
cryptographically hard puzzle called Proof of Work.
Definition 17 (Proof of Work)
Given a block header, find a nonce such that D-SHA256(block header) < difficulty,
where the difficulty is specified in the block header and the nonce has to be inserted
in the block header.
Remark 10 (Hard to find, easy to prove)
Although it is extremely hard to solve PoW as the only guaranteed way is to test
random numbers for the nonce, it is trivial to check that a solution to PoW is
correct or not. All that is needed is one hash computation and one comparison with
the difficulty.
The reason PoW needs a difficulty threshold, is to regulate the rate of new block
additions. The only reason consensus participants can establish which is the longest
chain is that miners prefer to mine blocks on top of the longest chain, so eventually
one of the competing chains will become the longest as more miners are competing
on it. However, if miners would be able to generate new blocks much faster than 10
minutes, then competing chains would exist for much longer as blocks are relayed
across the globe and a split of very distant miners would appear. This is why the
difficulty threshold adjusts automatically such that the average block time remains
at around 10 minutes.
20
2.3. BITCOIN
Blockchain Forks
abandoned fork
t=3.04 t=4.5
Figure 2.5: Three competing forks; blocks are marked with the creation time. The
green miners mine at the same rate as the blue ones until they receive block t=5
which clearly proves to them that the chain they are working on is not the longest.
At the same time, the red miners cannot mine as fast as the blue miners and they
become aware of this when they receive block t=4. Unfortunately, they have already
mined block t=4.5, but they abandon it as they see the longest chain is going to be
on top of t=4.
Consensus forks
Hard Fork - If the current protocol rules are extended and become less strict
(i.e. a transaction that was previously invalid is now valid), then old (un-upgraded)
clients will not understand the new rules and will not follow the chain of the new
miners who will basically be forced to transact only between them. This situation
can only be resolved if either all clients upgrade to the new rules or the upgraded
clients give up their fork and start running the original code again.
Soft Fork - If the current protocol rules are extended and become more strict
(i.e. a transaction that was previously valid is now invalid), then the success of the
fork depends on how many miners switch to the new rules. If there is a majority
21
2.3. BITCOIN
of miners switching, the fork will be valid as there is more hashing power working
towards extending the chain with the new rules. Old miners would see the chain as
valid by their rules, so they would not disagree. However, they would not be able to
use the new features until they upgrade. On the other hand, if the majority of the
hashing power runs the old code, then the fork will fail. Upgraded clients will be
able to publish their transactions and they would be valid, but the new rules would
not be in effect.
Thus it is usually the case, that any software update in Bitcoin is better deployed
as a soft fork. This means that in case the majority of consensus enforcers do not
want to upgrade then the fork just fails instead of permanently remaining split in
the case of a hard fork.
The Bitcoin network is a peer-to-peer network, meaning that nodes (clients, miners,
etc.) connect to other nodes and form a mesh network over which they relay (dis-
tribute) transactions and blocks. Nodes can answer to special type of requests from
other nodes soliciting data they haven’t seen. Even if the network communication
layer is not reliable or secure, the security of the Bitcoin system is not undermined
as hash functions form digital fingerprints (checksums) of transactions and blocks.
Full Node
A full node is a node which stores all the transactions and all the blocks and indexes
them accordingly. A full node has complete knowledge of the state of transactions
and can serve information to other nodes which are trying to build their own copy of
the blockchain. To run a full node one requires relatively powerful hardware memory
and CPU wise.
Miners are full nodes, that also participate in the competition of publishing the
next block to the blockchain. They have no incentive to spam, misinform, or trick
other nodes as the consensus rules would ban the miner for a period of time and,
thus render his hashing power useless. This would imply major financial losses for
the miner.
SPV nodes are lightweight devices that only store a list of block headers and relevant
transactions (eg: only the ones associated to the user) instead of all the transactions
in the whole blockchain. The reason SPV nodes can exist is because of the merkle
tree structure in which transactions are stored. As shown in Section 2.2.2, it is
possible for an SPV node to check the existence of a transaction in the blockchain
by simply asking a full node for a proof of existence. The full node would return a
merkle branch, which the SPV node would check. This would completely convince
him that his transaction is included in the blockchain.
22
2.3. BITCOIN
Transactions are the most basic and important structure in Bitcoin; they are data
structures that encode the transfer of ownership of funds. All the other parts of the
system are designed to ensure that transactions can be created, propagated on the
network, validated, and persisted.
Transactions are formed of inputs, outputs and some meta-data. The basic
(before segregated witness, a.k.a SegWit, was deployed) format of a transaction is
depicted in the figure below.
23
2.3. BITCOIN
Thus, to consume some unspent output, a user needs to know the transaction in
which it resides and the index of the output. However, to successfully consume an
output, the user also needs to provide a scriptSig that can successfully unlock the
scriptPubKey found in the referenced output.
Transaction Outputs are the building blocks of transactions. They are both
produced as outputs out of a transaction, but also referenced as inputs. The outputs
must consume all the Bitcoins produced by the inputs, minus a remainder which
will be automatically considered as fee. The structure of an output is quite simple
(see Table 2.5).
Transaction Scripts
24
2.3. BITCOIN
Very complex scripts can be created, but most users just construct the following
basic scripts.
Note that with the exception of OP_RETURN, all other script types require a
signature. This is a crucial part of a Bitcoin transaction as this ensures, the owner
of the private key is the only one that can modify the transactions he created.
25
2.3. BITCOIN
includes it in the output. This abstraction allows users to protect against transmis-
sion errors, i.e. if one of the bits in the address is changes, the fingerprint will not
match any more and the payer will know he is about to send funds to an invalid
scriptPubKey.
Transaction Signatures
In Bitcoin digital signatures use the ECDSA signature scheme and sign the data of
the transaction in part or fully, depending on the signature type specified:
3. SIGHASH_SINGLE is a flag specifying that all the inputs and only the
output corresponding to this input should be signed. This is used when users
want to ensure their output is not modified, but other outputs which do not
belong to the user can be modified.
ECDSA in Bitcoin is implemented over the elliptic curve Secp256k1. This curve
was rarely used before Bitcoin, but due to its several nice properties it is gaining
popularity. The structure was constructed to optimize computations so it is often
more than 30% faster than other curves when sufficiently optimized.
Definition 18 (Secp256k1)
Let E : y 2 = x3 + 7 be defined over Fp where p = 2256 − 232 − 29 − 28 − 27 − 26 − 24 − 1
is a prime number. The generator of the cyclic subgroup of E(Fp ) is
n=F
| F {z
. . . F} EBAAEDCE6AF 48A03BBF D25E8CD0364141
31
Considering the large characteristic of Fp and the large order of the cyclic subgroup,
it is certain that classical computers would not be able to break ECDSA in Bitcoin.
26
2.3. BITCOIN
1. Transaction Creation
(a) Find UTXOs that Bob can unlock until the sum of their values is larger
than n.
(b) Crate the input vector by referencing each UTXO we found at the previ-
ous step.
(c) Create an output to Alice, by specifying the amount n and the script-
PubKey that she supplied to us.
(d) Create an output to Bob with the change. Leave some fees though, to
give incentive miners to include our transaction in a block.
2. Transaction Signing - We will just use the general SIGHASH_ALL type, for
simplicity. Go through each input and provide a corresponding scriptSig as
explained in section 2.3.3. Include this scriptSig in the corresponding input.
4. Transaction Confirmed - From time to time, Bob will ask full nodes if the
transaction he created is part of the blockchain. When the transaction is
indeed included, any full node can notify Bob that his transaction exists in
the blockchain and offer him a Merkle branch proof that will convince him
that the transaction is indeed accepted.
5. More confirmations - For extra security, Alice should wait a bit longer so that
more Proof Of Work is accumulated on top of the block with Bob’s transaction
and she can gain more confidence in the immutability of the transaction.
27
2.4. QUANTUM COMPUTING
In this section we offer some insight into Quantum Computing, its mechanisms,
phenomena, the current state of physical realizations, and the direction it is heading
towards.
Even though the idea that atoms or photons could be manipulated to perform
highly efficient parallel computations was first formulated in 1959 by Richard Feyn-
man [26], the idea of quantum computers became of (somewhat) wide interest only
recently (1994), when Peter Shor developed a polynomial time algorithm for factor-
ing large integers [60]. This is one of the major threats to current cryptographic
systems (RSA and Bitcoin’s ECDSA included) which rely on the hidden subgroup
problem on finite abelian groups.
The power of quantum computing stems from several phenomena and laws of
quantum mechanics that are fundamentally different from those encountered in clas-
sical computing. In order to understand complex probability amplitudes, quan-
tum interference, quantum parallelism, quantum entanglement, and the unitarity of
quantum evolution, one has to understand several basic principles on which quan-
tum mechanics is based. To use these features in the design of quantum algorithms,
networks, and processors, we need to study the basics of Hilbert space formalism,
which represents the mathematical framework used in quantum mechanics.
In general, quantum algorithms work by preparing the state on which the com-
putations are performed as a superposition of more (or all) possible classical states,
thus computing all the possible solutions in only one step. The major problem quan-
tum algorithms have to overcome is wave function collapse, i.e. when the result of
a computation is measured, the superposition of states is collapsed and only one of
the results is observed, the others being lost forever. Hence, quantum computations
try to use the underlying structure of the problem and manipulate the superim-
posed state in order to increase the likelihood of a certain outcome which can be
interpreted deterministically and yield the result wanted.
Before diving into the mathematics of quantum mechanics, we note the motivation
behind quantum computing and we argue that it is only a matter of "when" and
not "if" this technology will become functional. The challenges QC poses to current
cryptographic systems must be addressed and resolved before it reaches a stage of
maturity.
Current, classical, computers are getting smaller and faster, approximately sat-
isfying Moore’s Law. Unfortunately, this trend will stop very soon as physical laws
impose limits on how much smaller we can build transistors. Intel currently produces
transistors only 14 nanometres wide [41] while an atom is about 0.5 nanometres.
We are getting close to a scale where the classical laws of physics simply do not
apply any more and quantum mechanics takes over. Phenomena such as quantum
tunnelling will render transistors useless as electrons will pass right trough them. To
overcome this barrier, we need to drastically change the paradigm of building a com-
28
2.4. QUANTUM COMPUTING
puter and make use of the laws of physics at this extreme scale. In fact, according
to our current knowledge, the physical world is fundamentally driven by quantum
mechanics. All computers are physical devices and computations are physical pro-
cesses. However, all classical computers and models of computers rely solely on
classical mechanics and while their performance is impressive, they do not tap into
the full potential of information processing power that our world offers. As such,
it is a fundamental duty to deepen our knowledge and understanding of the laws
of quantum mechanics and how they can be used to overcome the computational
limitations of classical mechanics.
This section aims to present the mathematical tools needed to model, operate, and
measure quantum systems. For a deeper understanding of the theory presented here,
please refer to Jozef Gruska’s book "Quantum Computing" [29].
Hilbert Spaces
The set of all possible (pure) states of a quantum system constitutes a so called
Hilbert space. This formalism is the basic framework for rigorous, precise definitions
and for the study of quantum mechanical concepts, phenomena, algorithms, and
processes.
Definition 19 (Vector (linear) Space)
A vector (linear) space S, with a carrier H, over a field K is an algebra S =
⟨H, +,−1 , 0, K, +f , ×f , 0, 1, ·⟩ such that ⟨H, +,−1 , 0⟩ is a commutative group, K =
⟨K, +f , ×f , 0, 1⟩ is a field, and · : K × H → H is a scalar multiplication satisfying
the following axioms for any a, b ∈ K and ϕ, ψ ∈ H:
1. a · (ϕ + ψ) = a · ϕ + a · ψ, (a +f b) · ϕ = a · ϕ + b · (distributive laws)
2. (a · (b · ϕ)) = (a ×f b) · ϕ
3. 1 · ϕ = ϕ.
29
2.4. QUANTUM COMPUTING
∑
n
⟨(x1 , . . . , xn )|(y1 , . . . , yn )⟩ = x⋆i yi
i=1
For our purposes, we will assume the above definition for the ⟨·|·⟩ operator.
Dirac Notation introduces ⟨ψ| and |ψ⟩ called bra and ket vectors respectively.
For n-dimensional complex Hilbert spaces a ket |ψ⟩ can be considered as an n-
dimensional column vector and a bra ⟨ϕ| as an n-dimensional row vector. As such,
the scalar product ⟨ϕ|ψ⟩ is the result of a usual row vector × column vector
product, i.e. a complex number and the tensor product |ψ⟩ ⟨ϕ| is the result of a
usual "column vector × row vector" product, i.e. a matrix. For an indexed set of
vectors {xi } we sometimes write |i⟩ or ⟨i| to represent the bra or ket vector of the
i-th element in the set.
Definition 22 (Hilbert Space)
An inner-product space H is called complete if for any sequence {ϕi }∞i=1 with ϕi ∈
H, and with the property limi,j→∞ ∥ϕi − ϕj ∥ = 0 there is a unique element ϕ ∈ H
such that limi→∞ ∥ϕ − ϕi ∥ = 0. A complete inner-product space is called a Hilbert
space. The elements of H are usually called vectors and those elements with norm
1 denote (pure) states.
The concept of orthogonality is one of the key constructs in the theory of Hilbert
Spaces.
Definition 23 (Orthogonal and Orthonormal)
Two vectors ϕ and ψ of a Hilbert space H are called orthogonal if ⟨ϕ|ψ⟩ = 0. A set
S ⊆ H is orthogonal if any two of its elements are orthogonal. S is orthonormal
if it is orthogonal and all its elements have norm 1.
30
2.4. QUANTUM COMPUTING
As such, orthogonal vectors can represent events that are independent of each other;
e.g. all positions a particle can be located in, all the possible polarizations of a
photon.
2. All bases of a Hilbert space H have the same cardinality, also called the dimen-
sion of H. Hence, all Hilbert spaces of the same dimension are isomorphic.
1. f (x + y) = f (x) + f (y)
The space of all linear functionals on H, is itself a vector space called the dual space
of H and is denoted H ⋆ .
31
2.4. QUANTUM COMPUTING
1. T (x + y) = T (x) + T (y)
2. T (αx) = αT (x)
Similar to linear functionals, which can be represented as vectors which map other
vectors to complex numbers, linear operators can be represented as matrices that
map vectors to other vectors. For ease of notation we will usually denote the
matrix of an operator
∑ A with A also. As such the application A(x) becomes
Ax = (Aij )(xi ) = i Aij xi . Furthermore, the composition of two operators A ◦ B
is just matrix multiplication AB.
Definition 27 (Adjoint Matrix/Operator)
For a matrix T = (Tij ), the adjoint matrix is T † = (T T )⋆ . Furthermore, if T = T † ,
then T is called self-adjoint and is a Hermitian matrix.
4. (M ⊗ N )T = M T ⊗ N T .
32
2.4. QUANTUM COMPUTING
Quantum State
The state of a quantum system offers a complete description of the internal "mem-
ory" of the quantum computer at any point during the computation. These states
are modelled as vectors of a Hilbert space.
One can say that to each isolated quantum system corresponds a Hilbert space.
Other interpretations go further by claiming that reality on the quantum level does
not exist and only emerges when measurement is done. Everything we know about
the quantum level are computational procedures (expressed in terms of Hilbert space
mathematics) that compute the evolution of quantum systems and probabilities of
the measurement outcomes.
Using the Hilbert space formalism, any state X of the system can be represented
as a ket-vector or a bra-vector. Any state X can be written in terms of any basis B:
∑ ∑ ∑
|X⟩ = |i⟩ ⟨i|X⟩ = αi |i⟩ and ⟨X| = αi⋆ ⟨i|
i∈B i∈B i∈B
The complex numbers ⟨i|X⟩ are called probability amplitudes and represent the
probability that when measuring the state with respect to basis B, the qubit will
collapse to |i⟩.
Qubits
33
2.4. QUANTUM COMPUTING
where α and β are complex numbers with ∥α∥2 + ∥β∥2 = 1. Note that all quantum
states are normalised, so ∥ψ∥ = ⟨ψ|ψ⟩ = 1.
•
H H hidrogen atom (see figure on the left), or
the vertical and horizontal polarizations of
a photon.
Before quantum mechanics was introduced, it was taken for granted that measuring
something represents gaining knowledge of a pre-existing state. In other words, it
was thought that measurement does not affect the state of the system in any way.
The quantum interpretation is that measurement cannot be done without affecting
the system.
Example 1 (Measurement affects the system it measures)
This concept can be understood even in a classical world. When one measures the
speed of a an object (e.g. car), what usually happens is that a wave (eg. radio, light)
is emitted towards the object and the reflection of the wave is caught with a receiver.
As the object is moving, the wavelength will be different after reflection and the speed
of the object can be determined. It would appear that the object was not affected at
all during this measurement, but, in fact, when particles reflect off the surface of the
object they exert a small pressure on the object which slightly changes its position. In
a classical world this effect is negligible, but when we talk about microscopic entities
(e.g. atoms, photons, electrons) this intervention to the system completely changes
the output of the measurement.
Observables are properties of the physical system that can be measured. While
in classical physics these can be position, speed, or size, in quantum theory an
observable is a self-adjoint operator. The outcome of the measurement of a quantum
34
2.4. QUANTUM COMPUTING
state |ψ⟩ with respect to an observable A is one of the eigenvalues of A and the effect
of such a measurement is a collapse of |ψ⟩ into a state which is represented by the
corresponding eigenvector.
During the evolution of a quantum system, some transformations of the initial state
are performed such that the state can be manipulated to amplify certain probability
amplitudes. Some physical quantum gate A is represented mathematically by a
linear operator A which transforms each complex vector to another complex vector
that represents the new state. Since all quantum states should be normalised vectors,
the condition for an operator to represent a quantum transformation is to be unitary.
This implies that any transformation is also reversible using the adjoint operator
A⋆ .
as the tensor product of some other states. In case this cannot be done, the state is
said to be entangled and it exhibits some extremely counter-intuitive properties.
For example, we know that the state collapses when we measure it, but what would
happen if we only measure one of the particles from a fully entangled state. Quantum
laws dictate that the whole state would collapse to another superposition where the
qubit observer is fixed and all the other qubits are fully entangled. This means that
observing a certain particle somehow affects the behaviour of other particles too. In
fact, the particles could have been moved to very far locations before observation
and the collapse of the un-measured particles would still happen simultaneously with
the measurement. Although very un-intuitive, this is the nature of the world.
35
2.4. QUANTUM COMPUTING
Quantum Gates
Likewise classical computers, the basic elements of a quantum computer are qubits,
quantum registers, quantum gates and quantum networks. However, the properties
of these elements are very different from their classical counterparts. A qubit can be
in an infinite number of states and a quantum register composed of n qubits can be
in any superposition of the 2n basis states, at the same time. This enables massive
parallelism, which can be exploited by performing transformations using quantum
gates (implementations of self-adjoint operators). In Figure 2.6 are some examples
of common 1 qubit quantum gates and their matrix representation.
Figure 2.6: Some examples of 1 qubit quantum gates. In fact, from these gates we
can construct any other unitary matrix.
Furthermore, we give the representation of the much utilized controlled not gate.
The operation ⊕ is defined as addition mod 2.
|x⟩ |x⟩
1 0 0 0
0 1 0 0
CNOT =
0
0 0 1
0 0 1 0
|y⟩ |x ⊕ y⟩
Figure 2.7: The CNOT gate. Whenever |x⟩ = |1⟩, the lower qubit is negated.
|x⟩ |y⟩ = (α |0⟩ + β |1⟩)(α′ |0⟩ + β ′ |1⟩) = αα′ |00⟩ + βα′ |10⟩ + αβ ′ |01⟩ + ββ ′ |11⟩
36
2.4. QUANTUM COMPUTING
we apply the first C-NOT gate → αα′ |00⟩ + βα′ |11⟩ + αβ ′ |01⟩ + ββ ′ |10⟩
we apply the second C-NOT gate → αα′ |00⟩ + βα′ |01⟩ + αβ ′ |11⟩ + ββ ′ |10⟩
we apply the third C-NOT gate → αα′ |00⟩ + βα′ |01⟩ + αβ ′ |10⟩ + ββ ′ |11⟩
≡ α′ |0⟩ (α |0⟩ + β |1⟩) + β ′ |1⟩ (α |0⟩ + β |1⟩) ≡ (α′ |0⟩ + β ′ |1⟩)(α |0⟩ + β |1⟩) ≡ |y⟩ |x⟩
Another way to see this would be to use matrix multiplication using the matrix rep-
resentation of the C-NOT gate.
|x⟩ |y⟩
|y⟩ |x⟩
Figure 2.8: Graphical representation of the circuit for swapping two qubits.
Quantum algorithms outperform their classical counterparts for some classes of prob-
lems by using quantum phenomena. In general, they prepare a state in quantum
superposition and move through entangled states, thus being able to leverage the
power of quantum parallelism. By a single application of a unitary operator, quan-
tum algorithms can perform 2n (where n is the number of qubits) classical compu-
tations on basis states. Note that in quantum registers the amount of parallelism
increases exponentially with the size of the system, only requiring a linear increase
of physical space.
For our paper we will only present the algorithms which affect Bitcoin and the
building blocks needed to create them.
Classical Fourier transforms are regarded as powerful mathematical tools that map
functions of period r to functions with non-zero values only at the multiples of the
frequency 1/r. Thus, a quantum analogue was developed that can perform the same
task in polynomial time.
37
2.4. QUANTUM COMPUTING
Definition 32 (QFT)
QFT with the base q (or in the group Zq ) is the unitary transformation:
1 ∑ 2πiab/q
q−1
QF Tq : |a⟩ → √ e |b⟩
q b=0
|x3 ⟩ H X2 X3
|x2 ⟩ H X2
|x1 ⟩ H
Figure 2.9: Quantum network implementation for the Quantum Fourier Transform
for n = 3.
Shor’s Algorithm
Shors algorithm can solve in polynomial time the hard problems of integer factor-
ization and discrete logarithms. The first part of the solution can be run on classical
computers and reduces the problem of factoring large integers to finding the period
of a function. The second part makes use of the QFT to extract the exact period.
However, for our purposes we are more interested in how we can solve the ECDLP
not integer factorization. For simplicity, we will only show how Shor’s algorithm
is implemented for a general discrete logarithm problem as the elliptic curve spe-
cialization requires implementing the elliptic curve group law (addition of points).
This can be implemented easily as it reduces to simple operations [60], but it would
exceed the space limitations of this paper.
Definition 33 (Discrete Logarithm Problem)
Determine an r such that g r ≡ x mod p given a prime p, a generator g of the
multiplicative group Zp⋆ and some x ∈ (0, p).
38
2.4. QUANTUM COMPUTING
. We apply the QF Tp−1 two times to modify the third and fourth registers and
obtain
1 ∑∑
p−2 p−2
|ϕ1 ⟩ = |x, g, a, b, 0⟩
p − 1 a=0 b=0
a uniform distribution of all pairs (a, b) with 0 ≤ a, b ≤ p − 2. Next we apply
the following uniform transformation mapping (unitary operator): (x, g, a, b, 0) →
(x, g, a, b, g a x−b mod p) and have
1 ∑∑
p−2 p−2
|ϕ2 ⟩ = |x, g, a, b, g a x−b mod p⟩ .
p − 1 a=0 b=0
From now on, the computation leaves the registers on which x and g reside un-
touched, so we will not include them anymore until the end. We apply the QF Tp−1
2πi
twice on the registers of a and b again. First we map a → c with amplitude p−1
1
e p−1 ac ,
2πi
and then we map b → d with amplitude 1
p−1
e p−1 bd . The result is
1 ∑
p−2
2πi
|ϕ3 ⟩ = e p−1 (ac+bd) |c, d, g a x−b mod p⟩ .
(p − 1)2 a,b,c,d=0
Now let us compute the probability amplitude of the states that are of interest to
us, i.e. the states for which x = g r mod p. The probability is the square of the sum
of all the corresponding probability amplitudes. Substituting x in the last register
gives g a (g r )−b mod p = g a−rb mod p. Further, we can use the fact that for a prime
p the following holds: g p−1 ≡ 1 mod p. As such, the following implication holds
a ≡ b mod (p1) → g a ≡ g b mod p. Now if we define a − rb ≡ k mod (p − 1), the
final register becomes g k mod p.
Therefore, we measure the state y ≡ g k mod p with probability
2
∑p−2
1 2πi
(ac+bd)
e p−1
where a − rb = k
(p − 1)2
a,b,c,d=0
2
∑
p−2
1 2πi
≡
e p−1
(kc+b(d+rc))
(p − 1) 2
b,c,d=0
When d + rc ̸≡ 0 mod (p − 1), the above expression is over a set of (p − 1)st (even)
roots of unity that cancel each other, so the probability of this event is 0.
As such, it must be that d + rc ≡ 0 mod (p − 1)) and the above expression
2πikc
becomes (p−1)−1 e p−1 . Because the expression does not depend on b, the probability
is (p − 1)−2 .
Hence, we can measure the registers of c and d to retrieve some c, d < p − 1
that satisfy: d ≡ −rc mod (p − 1). From this we can extract r = − dc mod (p − 1),
provided that gcd(c, p − 1) = 1.
39
2.4. QUANTUM COMPUTING
Grover’s Algorithm
Remark 15
In fact, this class of problems covers all the hash functions and many more problems.
Classically this problem can only be perfectly solved in O(N ) time which means
exponential in terms of the number of bits in N. Grover’s
√ quantum search algo-
rithm can find a desired value x in approximately O( N ), which means a quadratic
speedup. To design such an algorithm we first need to create a unitary operator Uf
that can compute f and select the elements we want. In fact, it can be proven that
we can construct Uf which maps |x⟩ → (−1)f (x) |x⟩. This essentially means that we
will negate (invert) only those basis states that correspond to wanted solutions.
Let N = 2n and assume there is only one state we are looking for, i.e. f (x) = 1
holds for exactly one state. The Grover quantum search algorithm is:
1 ∑
2 −1
n
3. Apply Uf to |ϕ⟩.
1 ∑
2 −1
n
40
2.5. POST-QUANTUM CRYPTOGRAPHY
41
2.5. POST-QUANTUM CRYPTOGRAPHY
It follows then, that there must be a non-singular matrix S and a permutation matrix
P such that: G = SG′ P
Thus, in such cryptosystems, we can construct private and public keys as follows:
42
2.5. POST-QUANTUM CRYPTOGRAPHY
Furthermore, it is intuitive that for any lattice there are more than one basis that
correctly describe it. However, some of these basis will allow the computations of
vectors in the lattice to be relatively cheap computationally, while others will require
very expensive calculations.
Therefore, a public-key cryptosystem can be designed where the private key is
a "good" basis, which consists of short vectors, almost orthogonal vectors and the
public key is a "bad" basis for the same lattice.
Although lattice problems exhibit a periodic underlying structure, which is what
quantum algorithms usually look for, attempts to create such algorithms date since
Shors factoring technique and none have been successful in applying the same strate-
gies.
For the purposes of our paper, it is important that the Bitcoin community agrees
on and implements an appropriate alternative (or perhaps more than one) to replace
Elliptic Curve Cryptography as the basis for digital signatures of transactions.
43
Section 3: Post-Quantum Bitcoin
In this section, we analyse the impact a malicious adversary in possession of a
quantum computer can pose to Bitcoin.
Nowadays, multiple companies have shown major interest in quantum computing
and extensive research on error-correction, physical implementations, theoretical
algorithms and much more is going on [69, 22, 68]. Considering the number of new
players that enter this growing domain, it seems increasingly probable that powerful
quantum computing will emerge in the near future. A sudden improvement in
the approach of physical implementations might lead to a fast quantum computer
appearing virtually overnight.
We will present a few attack strategies that become possible with quantum com-
puting and the extent to which they can be used. Note that we do not discuss
the possibility of using Grover’s quantum search to retrieve the public key from a
P2PKH or P2SH challengeScript in our work, as the achieved speed-up is merely
quadratic and can be mitigated by increasing the key size [14].
Attacks on Bitcoin’s Proof Of Work (PoW) have the purpose of gaining an unfair
advantage when mining such that the attacker can produce valid blocks considerably
faster than the rest of the network. As such, an adversary can successfully rewrite
the blockchain history by publishing a chain of blocks that links to an older block
instead of the tip of the blockchain. In order for such an attack to be successful,
the attacker needs to extend his chain until it exceeds the length of the main chain,
thus convincing the rest of the nodes to abandon the original main chain and start
mining on the malicious chain. This is especially difficult since while an attacker is
mining blocks, the rest of the network keeps mining on the main chain, adding a
block every 10 minutes.
Figure 3.1: The red attacker mines blocks that do not link to the tip of the blockchain
and outperforms the honest miners (in blue) so his chain will become the new main
chain.
44
3.1. ATTACKS ON PROOF OF WORK (POW)
Given the current state of quantum computing research, the most suitable tool
for attacking Proof of Work is actually Grover’s quantum search algorithm that we
described in Section 2.4. Grover’s algorithm was designed exactly for this type of
unstructured search problems. This provides a quadratic speed-up compared to a
classical computer, which should give a decent advantage to the adversary. In fact,
the multiple acceptable solutions version of Grover’s algorithm should be employed
here as any√ H(m||n) < t is acceptable. Thus, the worst case runtime complexity is
actually O( 2t ). Compared to the classical worst case time complexity of O(2n −t),
n
45
3.2. ATTACKS ON ECDSA
Once efficient quantum computers with internal states comprised of many qubits are
implemented, the underlying cryptographic guarantees of Bitcoin’s ECDSA can be
challenged. As mentioned in Section 2.4, an attacker with a quantum computer of
about 6 ∗ n ≈ 1500 (given the ECDSA public key is a 256 bit string) qubits [54, 63]
can use Shor’s algorithm to solve the ECDLP and compute an ECDSA private key
given the public key. Once an adversary obtains a private key, he is indistinguishable
from the original owner so he is in full control of the funds.
46
3.2. ATTACKS ON ECDSA
members of the group have access to all the public keys. In fact, this type
of UTXO usually appears when different set of parties in the group are not
trusted, so it would make sense for one of the parties to disclose the public
keys of the other members to a quantum attacker.
4. Bitcoin users that own currencies on other Bitcoin forks (e.g. Bitcoin Cash [1]
or Bitcoin Gold [2]) can use the same public key on all forks where they
operate. As such, users could reveal a public key in the challengeScript of
one of the outputs or in the scriptSig of any of the inputs of transactions on
Bitcoin forks. As Bitcoin forks share the same transaction history prior to the
fork point, such behavior may allow adversaries to gain control over the funds
on all forks.
5. A Bitcoin user can reveal his public key as part of a signed message to ensure
integrity, in forums, or in payment channels (e.g. Lightning Network [52]).
This type of unveiling is not immediately threatening as attackers do not
know if any public key they find online is also used to secure some bitcoins.
However, it is not far-fetched to imagine adversaries that regularly scan the
network for standard type challengeScripts built using the revealed public
key. As they have precomputed the private key needed to unlock the output,
they can simply consume the funds. Furthermore, attackers could monitor all
broadcast transactions and wait until one of the public keys they found online
appears in an input as part of the scriptSig. When this happens they can use
the computed private key to overwrite the transaction by specifying a higher
fee on their own transaction. Miners would not be able to tell which of the
transactions is the original one so they would just include the one with the
higher fee.
In this section we consider the special case in which a quantum capable attacker
can perform live transaction hijacking. Thereby an attacker attempts to compute
the private key corresponding to a public key revealed in the input of a transac-
tion broadcast to the network but not yet included in a block. Consequently, just
like in a double-spending attack [34, 56, 35, 61], the attacker creates a conflicting
transaction1 spending the same UTXOs, thus stealing the victim’s funds. Note,
however, that this form of transaction hijacking differs from the more conventional
notion of double-spending as the attacker is the beneficiary rather than the original
transaction initiator.
It is important to note that the attacker, must not only create, sign and broadcast
the conflicting transaction, but also first run Shor’s algorithm to derive the private
key. As timing is essential for such attacks, the performance of quantum computers
plays a central role for the success probability of this type of attack.
An extension to this attack could be to combine it with selfish mining strate-
gies [25, 57, 48, 27]. Assuming the adversary is also a miner, he could employ his
1
Possibly with a higher fee to incentivise inclusion in the blockchain over the victim’s transaction
47
3.3. ESTIMATED LOSSES
computational power to attempt to build up a secret chain and, when in the lead,
selectively publish blocks to cause main chain reorganisations. In contrast to tra-
ditional selfish mining attacks, the feasibility of this combined attack is expected
to improve significantly, since the adversary can now also perform transaction hi-
jacking, thus drastically increasing his profits. As such, the prospectively-gained
revenue consists of more than just block rewards and transaction fees, as all funds
contained in (non-quantum-resistant) UTXOs spent in the overwritten transactions
are also at the mercy of the attacker.
48
3.4. HINDERING TRANSITION TO QUANTUM RESISTANCE
Given these possible attacks, the Bitcoin community is considering different quan-
tum resistant signature schemes that could be suitable for Bitcoin. Once one of them
is deployed, users will be able to create challengeScripts using the new quantum re-
sistant public key, hence securing their funds against quantum capable attackers.
However, if adversaries have the ability to perform live transaction hijack-
ing, users will not be able to transition their funds to quantum resistant
UTXOs as their transactions would be immediately hijacked. This is the
exact problem we are trying to solve in this paper.
49
Section 4: Transition to Quantum Re-
sistance
In this chapter we offer a solution to the problem of transitioning to quantum resis-
tance securely. More specifically, we describe a new scheme, called QRWit, that can
be used to consume outputs secured by the elliptic curve digital signature algorithm
by leveraging on the security of a quantum resistant cryptographic system1 . Thus,
our scheme can be used to transition to quantum resistant signature schemes by
simply consuming the funds and sending them to a quantum resistant output. As
the scheme we are about to describe relies on a quantum resistant cryptographic
construct that can produce signatures for a given message, we are assuming that
such a system will be deployed before or at the same time with our scheme. A
detailed discussion on deployment of quantum resistant signatures and their timing
is done in Section 5. For the remainder of this section we assume quantum resistant
signatures are deployed in Bitcoin. This means users can generate pairs of private-
public keys that cannot be broken by quantum computers. The protocol update we
propose will make use of such a pair of keys.
After the transition protocol is given, we offer a deeper analysis of each step of
the protocol and demonstrate the security guarantees we claim it provides. Bitcoin-
specific implementation details, as well as discussions on parametrization and nec-
essary data structures are considered separately in Section 5.
In order to consume funds protected by some ECDSA public key pk, we propose the
creation of a new quantum resistant public key (pkQR ) which will act as surrogate
for pk. Thus, whenever pk is used to verify the validity of a signature, the protocol
update we introduce would also require a second signature verification with pkQR .
Even though the classical signature can be forged by quantum attackers, we still
require it for backwards compatibility reasons. Un-upgraded users will trust the
transaction is valid because they check the classical signature. On the other hand,
upgraded clients will also check the quantum resistant signature which cannot be
forged. Furthermore, users must first prove to the network that pkQR is indeed their
own creation and is meant as a surrogate for pk. To achieve this we can employ the
same strategies used in hash-commitment schemes. Hence, before wanting to spend
funds associated with pk, a user must first publish a hash commitment H(pk ||pkQR ),
i.e., the hash of his concatenated public keys, thus linking the two keys together.
After including this commitment in the blockchain, the owner of pk can prove to
the network he is the creator of pkQR by revealing both pk and pkQR and pointing
1
Bitcoin community shall decide the specific one
50
4.1. PROTOCOL OVERVIEW
Figure 4.1: Overview of the commit-delay-reveal protocol for secure spending in the
presence of a quantum attacker.
4.1.1 Commit
The first phase of the transition is to create a quantum resistant surrogate for pk.
Such a public key can be created by simply using the quantum resistant crypto-
graphic system that is now active in Bitcoin to generate a pair (skQR , pkQR ). To
mark the commitment of the funds secured by pk, the user must include the hash
of both public keys pk and pkQR concatenated, i.e. H(pk ||pkQR ), in some block of
the blockchain in a transaction denoted Tcommit . There are multiple variants for
how to achieve this and the community or developers can decide upon the most
suitable format and method of this commitment. For example, we could create a
transaction Tcommit which includes the hash commitment in an OP_RETURN type
challengeScript in one of the outputs.
After Tcommit is broadcasted to the network and included in the blockchain, the
user will ask for a merkle branch proof of the existence of this transaction. This can
be used at a later stage to prove to the network the existence of the commitment.
An important discussion should be made on what type of transaction is Tcommit .
As Tcommit would immediately reveal the public key that verifies the signature on
51
4.1. PROTOCOL OVERVIEW
itself, this poses an intrinsic problem in publishing it. Basically, an adversary capable
of performing live transaction hijacking could attempt to prevent the creation of
Tcommit by double spending the transaction thus performing a denial of service.
To overcome this problem there are multiple defence mechanisms we could employ
depending on the timing of the transaction. For example, a guaranteed method
of ensuring Tcommit cannot be hijacked is to sign it with some quantum resistant
′ ′
key-pair (skQR , pkQR ). In fact, this can even be the same key-pair as (skQR , pkQR ).
To achieve this, the user needs to consume some output that is already secured by
a quantum resistant signature scheme. He could acquire these through trade or by
successfully mining a new block.
Note that Tcommit does not even have to be created by the owner of pk. In
fact, one can envision a service that could offer commit transactions. Users would
send the bytes representing the hash of their concatenated keys and the service
providers would send back the proofs of existence which can be checked by the
users immediately. After a delay of tsec , the user can transition his funds as we will
describe in the following paragraphs.
An important aspect of this phase is that it does not require any code changes in
the Bitcoin code. The earlier a user publishes a commitment, the earlier he can reveal
the keys and transition the funds. Users can start publishing such commitments even
now, provided that they can guess the format on which the developers will decide
upon for the commitment data.
4.1.2 Delay
This phase requires no user interaction and its only purpose is to allow the network
to build Proof of Work on top of the block where Tcommit was included. The user
just needs to wait for a predefined security period tsec .
Any funds associated with pk must be left untouched for this period of time as
otherwise, pk would be revealed and quantum capable attackers would compromise
the entire scheme. In fact, if one would try to consume funds associated with pk
after our scheme is deployed, the transaction would not even be valid under the
new protocol rules. For instance, clients that did not upgrade their code to our
protocol update would still be constructing transactions without the quantum sur-
rogates which would never be accepted. At the same time, they would be revealing
the classical public key which would allow attackers to break the private key and
subsequently use our scheme to steal the funds.
We argue that a long delay is necessary to ensure no blockchain reorganization
could have occurred accidentally or have been caused intentionally by an adversary.
While the specific choice of delay may be subject to follow-up scientific work and
discussion in the community, we propose an initial period of 6 months.
The reasoning behind our choice is explained in the next paragraphs taken from
the paper [62], which we have co-authored.
52
4.1. PROTOCOL OVERVIEW
The correct choice of the security period tsec , used as protection against accidental
and adversarial chain reorganisations, has a significant impact on the security prop-
erties of the proposed transition protocol. In contrast to previous proposals and
discussions [6, 65, 66, 67], we emphasise the necessity of a sufficiently long delay
phase, substantially longer than the standard confirmation period of ∼ 6 blocks in
Bitcoin. While the exact duration of tsec may be subject to future discussion, we
propose to require hash commitments to be older than 6 months, i.e., the UTXOs
used as input to Treveal must remain unspent during this period.
As explained in Section 3 we assume that the feasibility of block reorganisation
attacks, such as 51% attacks or selfish mining attacks requiring a smaller fraction
of the overall computational power, is significantly increased for quantum-capable
adversaries. In contrast to traditional reorganisation attacks, the prospective gains
in this scenario are not only comprised of block rewards and transaction fees but
also include any funds whose public keys have been revealed in one of the blocks
overridden by the attacker. Hence, relying on a short security period of a few blocks
(or no delay at all) provides insufficient protection against chain reorganisations in
the presence of a quantum-capable attacker.
We note that in theory an adversary controlling a significant portion of the overall
computational power could successfully rewind the chain further than tsec , thereby
altering the transaction history, and attempt to steal funds from all non-quantum-
resistant outputs which were spent from during this period. However, we argue
a fork overriding the block history of such substantial period as 6 months would
be classified as a catastrophic failure of the system, forcing out-of-band measures
to be undertaken by the majority of honest consensus participants. Specifically,
we assume clients and miners will have incentive to manually reject the conflicting
branch of the attacker2 .
However, by intuitive continuity arguments there must exist a point between
short- and long-ranged attacks, where the community is unable to find even out-of-
band consensus on how to proceed, i.e., whether to perform a manual invalidation
(override) of attacker’s fork or accept the conflicting branch of the adversary, as
visualized in Figure 4.2. While under different circumstances, similar disputes have
been observed in other cryptocurrencies and have led to permanent chain splits,
as in the case of Ethereum [21] and Ethereum Classic [5]. Hence, a quantum-
capable adversary may have incentive to attempt to exploit this “sweet-spot” to her
advantage, as a destabilisation or split of the chain could yield a higher success
probability of an attack.
By implementing a long delay phase, sufficient to trigger out-of-band actions in
case a longer fork is created by an adversary, the probability of a malicious chain
reorganisation interfering with the transition protocol can be minimized.
2
Note that this does not require any changes to the reference client implementation, as Bitcoin’s
JSON-RPC API provides an invalidateblock call, which permanently marks a specific block as
invalid, as if it had violated a consensus rule [19]. (There are of course many other clients available,
some of which may require code changes to manually reject a branch.)
53
4.1. PROTOCOL OVERVIEW
Figure 4.2: While long-range forks are expected to be manually rejected by the
majority of nodes, this may not be possible with short-range chain-splits due to the
limited time frame. There may exist a “sweet-spot” which causes a dispute whether
to accept or reject the conflicting branch, destabilising or even permanently splitting
the network to the benefit of the adversary (red).
4.1.3 Reveal
After the delay period has passed, the user can safely spend funds associated with
pk by creating a transaction Treveal , in which he does the following:
1. Reveal pk; this happens intrinsically when trying to consume an output locked
by pk. To be more exact, this will appear in the scriptSig of the input of Treveal
that references the output to be consumed.
2. Give a classical signature that can be checked with pk; this also happens auto-
matically when trying to consume the output. The signature is required as part
of the aforementioned scriptSig. Note that this signature can be forged by any
quantum attacker, but we require it for backwards compatibility reasons. The
challengeScript was created using the old protocol rules, so the un-upgraded
clients would consider the transaction invalid if the scriptSig does not provide
the classical signature.
3. Give a quantum resistant signature that signs exactly the same data as the
classical signature did; this can be included in a new segregated area that
we call QRWit and that only upgraded clients can see. The purpose of this
signature is to offer ownership guarantees in the presence of quantum attackers.
4. Reveal pkQR ; this will be needed in order to verify the quantum resistant
signature and can be included in QRWit as well.
54
4.2. AN ALTERNATIVE INTERPRETATION OF QRWIT
As all the additional data will be transmitted through the segregated area of the
transaction QRWit, un-upgraded consensus participants will simply believe Treveal is
a normal transaction consuming some UTXO secured by pk. They will be satisfied
with just the classical signature and accept the transaction. However, the upgraded
users will be able to see the additional data and to check the proof of existence for
the creation of the surrogate quantum resistant key. Finally, they can now check
that the quantum signature is valid and accept the transaction as valid.
The necessary implementation specifics are provided in Section 5. The protocol
updates P → P ′ that we propose restricts the definition of a valid transaction. As
such, the set of blocks that are valid under the new rules (P ′ ) is a proper subset of
the blocks that would have been valid under the old rules (P ). This means we can
be deploy these changes as a soft fork. Once the majority of the network upgrades
and accepts our code changes, the new protocol begins to be enforced.
We would like to accentuate that once the protocol is deployed, classic ECDSA
signatures will no longer be accepted in Bitcoin without providing the extra data as
well. Furthermore, if one uses an un-upgraded client and spends some funds, then
the respective funds will not be transferred and will become prone to theft, as the
public key is now revealed.
To prove the simplicity of the new protocol we would like to offer the following
summary in the form of a definition, which also offers a different point of view on
QRWit. What we would like to do is to strengthen the concept of a valid ECDSA
signature, to require the extra checks we described.
Definition 38 (QRWit (Quantum Resistant Witness))
Denote an ECDSA signature created with secret key k for message m as sigk (m).
Denote a quantum resistant signature created with secret key k for message m as
qrsigk (m).
For any elliptic curve digital signature d = sigsk (m), where (sk, pk) is a private-
public key pair, d is valid only if:
1. a new valid quantum resistant signature, over m, is generated with skQR and
verifiable with pkQR , i.e. qrsigskQR (m) can be checked using pkQR . In this sce-
nario, validity refers to the rules of the quantum resistant signature verification
algorithm.
2. a proof of common ownership of the two public keys is given, i.e. the user
must provide a proof that (skQR , pkQR ) was created by the owner of (sk, pk).
To prove that our protocol really implements this definition we would like to
explicitly show how each requirement is satisfied by our protocol update.
1. During the reveal phase of our protocol we require a quantum resistant signa-
ture over exactly the same data that the classical signature was over.
55
4.3. REAL CASE SCENARIOS
2. The proof of existence of the hash commitment and the impossibility of altering
this commitment, serves as proof that pkQR was created by the owner of pk,
which in turn implies the second requirement.
4.2.1 Flexibility
The advantage of looking at the protocol in this way is that the flexibility of the
scheme is immediately clear. In this section we would like to illustrate this and show
how users can benefit from it.
The inputs can reference any type of output. Apart from the standard output
types that were described in Section 2.3, the scripting language of Bitcoin can be
used to create many different challengeScripts. However, our scheme is not concerned
with this in any way. We are just requiring that whenever an ECDSA signature is
checked against a public key, a second quantum resistant signature over the exact
same data is given. This means that more complex challengeScripts that include
multiple signatures are automatically accommodated.
The outputs can be created in any way the user wants. There is no limitation
imposed by our scheme on how to spend the coins. We only enforce rules on the
consumption of UTXOs. A user could even send his funds to an UTXO secured by an
old, non-quantum-resistant public key, if he wishes so. Furthermore, in comparison
to other schemes we became aware of while working on this project, our protocol
does not require the user to predefine the way in which he wants to spend the coins.
The user can take this decision at the time of transitioning the funds.
In this section, we give a few real case scenarios that we believe are very probable to
arise. In terms of when quantum capable attackers appear, we can rate the scenarios
from optimistic (appears very late) to pessimistic (appears tomorrow). Hence, to
prove our scheme is needed in any scenario, we will present the scenarios and the
actions that should be taken from most optimistic scenario to most pessimistic.
Although this scenario is highly unlikely, we will go ahead and consider it. Even
though quantum computers are not scalable enough to be used against Bitcoin,
the community will still upgrade the current signature scheme (ECDSA) to a more
evolved one (let us call it MISS: Much Improved Signature Scheme) at some time.
Thus, when MISS will be deployed, the community will need to offer a way to
transition from ECDSA to MISS under MISS security guarantees. If this would not
be the case, then attackers that can break ECDSA would hijack the transition and
56
4.3. REAL CASE SCENARIOS
MISS would never be used. Our scheme can be used in this scenario by use of a
MISS surrogate for the ECDSA public key.
This scenario assumes that the community is aware of the appearance of a quantum
capable attacker with months in advance. In such a case, the community has plenty
of time to deploy a quantum resistant scheme (let us call it QRS). QRS can be ran
alongside ECDSA until quantum capable attackers are believed to start operating.
In fact, the exact moment should take into consideration tsec as quantum attackers
could try to rewind the blockchain and replace older transactions. Anyway, while
both signature schemes are active, users would be able to transition their funds from
ECDSA secured UTXOs to QRS secured UTXOs just by normal transactions.
However, at some point, ECDSA must be considered broken and invalidated in
Bitcoin. At that time, instead of simply invalidating all ECDSA signatures, the
community should instead deploy our scheme. If ECDSA would just be invalidated,
then users who did not transition and still have their funds in UTXOs will never be
able to recover them. On the other hand, replacing ECDSA with our scheme, would
allow users to transition to QRS even at a later time.
We note that ECDSA must not be invalidated before deploying our scheme as this
would require a hard fork to recover the funds. We will prove this by contradiction.
If ECDSA is invalidated before deployment of our scheme, there will be some new
clients which upgrade to this protocol change which only accept QRS. Thus, the set
of rules for valid blocks would state that all valid blocks contain only transactions
signed with QRS. Now, if we further want to deploy our scheme, we would have
to loosen the set of rules to re-allow ECDSA signatures which are required by the
challengeScript in the outputs to be consumed. As such, this cannot be deployed as
a soft fork as the set of blocks valid under the new rules is not a proper subset of
the previous set of valid blocks.
This scenario analyzes the extreme case in which quantum computers appear with-
out notice and our scheme has not been deployed yet. However, we assume quantum
resistant signatures exist. This scenario could be identified by the Bitcoin commu-
nity through reports made by users who are attacked. If this becomes real, all funds
associated with revealed public keys are not recoverable and is only a matter of time
until attackers consume them.
To recover the system from this extreme scenario, all transactions consuming
ECDSA secured UTXOs should stop as live transaction hijacking is possible. The
next step the community should take is to deploy a scheme such as ours as soon as
possible. Commit transactions would need to be created using quantum resistant
UTXOs, so we expect a surge in the price of quantum resistant bitcoins as most of
the currency is still not quantum resistant.
57
4.4. STANDARD REVEAL TRANSACTION
To conclude the description of our new scheme (QRWit), we would like to describe
how an average reveal transaction would look like. We shall try to predict the
behaviour of an average user. The scenario in which he operates can be any of the
above and we assume all his public keys have quantum resistant surrogates. In fact,
he could even have the same quantum resistant surrogate for more of his public keys.
However, this is not recommended as it would prove to the network that all those
public keys belong to the same person, information that would aid adversaries in
deanonymizing a user.
Furthermore, let us assume that the average user has multiple UTXOs where
his funds reside. After he waits for the delay period to pass for each of the public
keys he plans to use, he can construct reveal transactions. Once he uses one of
the public keys in the reveal transaction, this key is now revealed and a quantum
attacker can immediately use it to commit to his own quantum resistant surrogate.
However, in order to consume the rest of the funds associated to it, the attacker
would have to wait for the delay tsec to pass. During this time, the legitimate owner
of the funds should consume all of them by using his quantum resistant surrogate
and creating reveal transactions. If the user consumes all the UTXOs in time, the
quantum attacker cannot do anything to steal the funds as the outputs are already
consumed.
As such, we would like to emphasize that there is not a one-to-one correspondence
between commit transactions and reveal transactions. One commit transaction can
be used as proof of existence for many different reveal transactions. Moreover, one
reveal transaction can, and probably will, consume multiple UTXOs so multiple
commit transactions can be linked in one commit transaction. However, for the
whole reveal transaction to be valid, all commit transactions have to be older than
the delay period.
58
Section 5: Implementation
In this section, we describe the implementation of our scheme in Bitcoin. We will
show how we simulated the deployment of quantum resistant signatures and how
each phase of the scheme impacts the code. Furthermore, we will explain how
we adapted the code to allow this protocol update to be deployed through a soft-
fork. We have built our code on top of the Bitcoin code base [18] as it was on
the 18th of May 2018. More specifically, we have chosen the commit with hash
d792e47421fcb9ce3b381c1e6d8902777ae3f9f3. Bitcoin does have stable releases
every few months, but we decided to extend the code as it was at the aforementioned
commit as some pieces of code were refactored in such a way that enabled an easier
integration of the changes we were trying to implement.
59
5.1. QUANTUM RESISTANT SIGNATURES
CKey or a CPubKey, the strategy of choice can be specified in the constructor to obtain
a pair of keys that belongs to a certain cryptosystem. However, this would require
changes in all the seams where private or public keys are constructed. Furthermore,
the serialization implementation would have to be modified to specify the strategy
chosen.
In the future, the community will need to deploy quantum resistant signatures
and offer a way to check if a certain public key is quantum resistant or not. As our
protocol is not interested in how this will be achieved we are just assuming that
the CPubKey object will offer a method that can be called to obtain the guarantees
offered by the underlying public key (e.g. is it quantum resistant?). To avoid
modifying the code base in many different places, we have designed a simple hack
for providing the required functionality. We will simply consider that half of the
ECDSA public keys are quantum resistant. To implement this neatly we provide
the following implementation of the method IsQR which classifies public keys as
quantum resistant or not.
Note that the 4th byte was chosen randomly, while the hex value 0x80 is the
median of all 8-bit numbers. As any byte in a public key is essentially randomly
generated, the approach we implemented will yield quantum resistant public keys
half the time. Note that with such an implementation any quantum resistant public
key is also a valid ECDSA public key, which means that signature verification,
generation and any other constructs remain completely unchanged. In fact, the
only thing we care about is the ability to classify some keys as quantum resistant or
not. This is enough to allow implementing the other bits of the protocol.
60
5.2. QRWIT IMPLEMENTATION
To implement the protocol we have described, there are two stages we need to think
about: commit and reveal. Apart, from these aspects, we also have to consider
deployment of the code and backwards compatibility. In the following sections we
will approach each of these aspects with code samples and explications.
One of the challenges of being a Bitcoin developer is the backwards compatibility
thinking. Because the system supports a currency intended to be used by people
throughout the world, any protocol update should be backwards compatible so that
users who do not wish or are just unable to upgrade can do so without losing their
funds. Sometimes users are off-line for a long time, but they should be able to
recover their funds even after years of not using the system. Although sometimes
this is not possible and a hard fork is required, the core developers try to implement
all changes as soft forks.
We would first like to explain why we tried to alter existing code as little as
possible and why all code changes introduced have to be inserted in just the right
places in this very convoluted system. Bitcoin is an open source project where
developers are volunteers with expertise and a very specific Bitcoin mentality. As
ensuring security is one of the main goals of the system, all code changes have to
go through a very lengthy process of peer review, implementation, peer verification
and optimization. Before code is merged in, the core developers have to accept
the changes. Considering all these factors, code proposals should be very specific
and only implement the functionality required and no other refactoring should be
done. This does not mean refactoring doesn’t exist in Bitcoin, but that is a separate
process from integrating a new feature.
The first phase of our protocol is the hash commitment that will be used to prove
the common ownership of and ECDSA public key and a new quantum resistant
public key. As explained in Section 4.1.1, this phase requires no code changes
and users can start creating hash commitments whenever they want, once quantum
resistant signatures exist. Below we will describe the specific syntax we used and
the additional tools we created in order to help users create such commitments much
easier.
The structure of the hash commitment we use in our implementation is simply the
direct concatenation of the bytes of the old public key, followed by the bytes of the
quantum resistant public key. This can be seen below
uint256 hashCommitment = Hash (
oldPubKey . begin () , oldPubKey . end () ,
qrPubKey . begin () , qrPubKey . end ());
61
5.2. QRWIT IMPLEMENTATION
Although there exist other formats which would provide more flexibility, we decided
on this trivial approach for simplicity as we are building just a prototype to prove
the concept.
In our implementation this hash commitment is included in a transaction by
using an OP_RETURN type output. Transactions containing such outputs can be
created using the functionality that already exists in the Bitcoin client.
Tools
To enable users to easily create such hash commitments and to generate the proof
of existence for the commitment transaction, a few remote procedural call (RPC)
commands can be used. Some of them are implemented by us to add functionality
while others already existed in Bitcoin. As such, we will detail the functionality we
added and explain how to use the existing RPC commands. Note that the RPC
commands prefixed with m are implemented by us. The following list also serves as
a guide for completing the Commit phase of our protocol.
1. mkeys is an RPC command that takes no arguments and lists all the public
keys owned by the user. The output is a map from addresses 1 to key ids. For
informing the user, we classify the ids of the keys by resistance against quantum
computers. For example, after generating 5 new addresses and running the
command we obtain:
$ bitcoin - client mkeys
{
" 2 MtT7n9 ... " : " qr -e8fbc9703cc25... " ,
" 2 Mtx3HB ... " : " non - qr -8784e25c3c3a9... " ,
" 2 Mu9qcT ... " : " qr -13816 b76f42aa ... " ,
" 2 Mucsei ... " : " non - qr -90 e1a91b6161d ... " ,
" 2 Mv1wqz ... " : " qr -57 a3ea191b111 ... " ,
}
Colours are added to aid in the visualization of the example we will use
throughout the section.
62
5.2. QRWIT IMPLEMENTATION
The output can be checked using the RPC command verifytxoutproof which
takes as input merkle branch proofs and produces a list of txids and the block
in which they all appear. In fact, in our case it would be only one txid.
Equipped with all this data, a user can move on to the next stage of the protocol.
Delay Stage
This doesn’t require any actions from the users as they just need to wait for the
predefined 6 months delay period to pass. We have decided on 6 months for con-
siderations discussed in Section 4.1.2, but this could be determined to be different
after more extensive research on the topic.
To ensure users do not reveal their public keys during this stage, we added code
in the Bitcoin client that warns the user every time he is about to broadcast a
transaction where a public key, with a surrogate commitment, would be revealed.
63
5.2. QRWIT IMPLEMENTATION
Having waited for the security period to pass, users can consume funds secured by
ECDSA public keys with the guarantee that no attacker can hijack their transaction.
In order to complete this section in code we had to think about adding the surro-
gate data (i.e. quantum resistant signature, quantum resistant public key, proof of
existence) to a transaction, verifying the proof and validating the signature.
Under the new protocol rules, all transactions that consume an ECDSA secured
UTXO, will need to provide quantum resistant surrogate data. To this end, we
create the concept of a quantum resistant witness (QRWit), i.e. data witnessing the
fact that quantum resistant surrogates exist in this transaction.
For each input of a transaction, there will be an additional area of data at the
end of the transaction. We will name this area "qrWit" and it will contain a vector
of public key surrogates. We require one qrWit for each input instead of a global
one, because each input could be signed with a different SIGHASH type so for
ease of implementation and clarity we have taken this choice. All the qrWits in a
transaction form the segregated are we call QRWit.
A public key surrogate is represented by the following object:
class CPubKeySurrogate
{
public :
CPubKey pubKey ; // old key
CPubKey qrPubKey ; // new key
CTransactionRef commitTx ; // commit transaction in full
std :: string proof ; // a serialized merkleproof object
std :: vector < unsigned char > qrSig ; // new signature
...
}
We have modified the code such that when users sign transactions under the new
protocol rules, the Bitcoin client will automatically add surrogates for all the ECDSA
public keys that appear in the input as part of the scriptSig. The surrogates are
grouped by input and added in vectors that represent qrWits, one for each input.
Furthermore, we have created an additional RPC command, mgetrawrevealtx
that creates a reveal transaction which moves all the funds associated to a public
key to some new address. This does not mean users have to move all the funds
tied to a public key at once, but as explained in Section 4.4 they will have to do
it in a certain time frame. To simplify this process for them, we have created the
aforementioned command. The command takes as inputs the id of the public key
we are trying to transition to quantum resistance, the new address to which we
wish to send the funds, a serialized transaction representing the commit transaction
and a serialized merkle branch proof. The returned value is a serialized transaction
64
5.2. QRWIT IMPLEMENTATION
with all the surrogate data in place and all the UTXOs associated to the old public
key consumed as inputs. The user can now sign and broadcast this transaction to
transition his funds.
Verification of QRWit
Having described the creator’s part of the protocol, we will now focus on the verifier’s
part. More specifically, we need to add code that enforces the new protocol rules at
a consensus level. To this end, we will first give a short introduction on the stages
a transaction has to go through in order to be accepted by a node. Afterwards,
we will continue to demonstrate the changes we implemented to accommodate our
protocol updates.
Currently, a transaction object is serialized and relayed to the network using the
Bitcoin peer-to-peer network. Whenever e node receives a transaction, it will have
to decide whether this transaction is valid or not. If it is valid the transaction
will be added to the node’s memory pool, where it will sit until it is included in
a block. However, we do not want to perform unnecessary expensive checks if
there is no need. Furthermore, we want to access the global state, which requires
thread synchronization, as little as possible. Thus, the Bitcoin pipeline for validating
transactions is the following:
2. Perform transaction checks that require no context. Some of this checks are not
consensus critical, but enforce a good behavior and prevent denial of service
attacks through CPU or memory exhaustion.
3. Acquire a lock on the memory pool and UTXO set and cached the outputs
referenced as inputs by the transaction. After the caching is done, the lock is
released and the data cached is used to check for conflicts with other transac-
tions in the memory pool. If the inputs of two transactions overlap then the
transactions conflict and it is guaranteed that one of them will not be included
in a block. The miner will choose to keep the one with a higher fee as that
will benefit him most.
4. Acquire a lock on the blockchain and retrieve the current consensus rules rep-
resented through flags in the latest block. Use these flags to perform specific
checks that might require the blockchain and pass them to the signature vali-
dating objects to enforce specific protocol updates.
65
5.2. QRWIT IMPLEMENTATION
5. Fully validate the transaction by checking the scripts in the inputs and the
signatures. This is the most expensive part of the validation.
If all the above checks pass, the transaction is considered valid and is included in
the memory pool. Every ten minutes it will have the chance to be picked up and
included in a block.
We will now describe in more detail steps 4 and 5 of the above changes.
Once our protocol update is activated, all transactions that have surrogate data
have to be validated. As such, we iterate over all qrWits and over all their elements
(CPubKeySurrogate objects) and call the
bool CheckSurrogate(CPubKeySurrogate surrogate)
static method. The boolean returned specifies if the given CPubKeySurrogate is
valid or not. The following checks, essentially, ensure that the two public keys
specified in the surrogate are indeed created by their owner.
66
5.2. QRWIT IMPLEMENTATION
4. Verify that the block in which commitTx appears, as returned by the unserial-
ized CMerkleBlock object, is indeed part of the main chain and is older than
tsec . In order to perform this check we need to obtain the blockchain lock once
again.
Once the check described above passes and we reach the final stage of validating
a transaction, the scriptSigs and the challengeScripts from each input will be con-
catenated and ran as a script. Inside this script, various operations will take place.
We are not interested in any of these operations and we do not add or change these
in any way. However, some of them will be signature verifications, i.e. a public
key and a signature will be provided and a TransactionSignatureChecker will be
used to check the validity of the signature. As we mentioned multiple times, this
is what we are interested in modifying. We will change the implementation of the
VerifySignature method as follows:
bool TransactionSignatureChe cker :: VerifySignature (
const std :: vector < unsigned char >& vchSig ,
const CPubKey & pubkey ,
const uint256 & sighash ) const
{
if (! pubkey . Verify ( sighash , vchSig )) return false ;
if ( enforceQR && ! pubkey . IsQR ()) {
for ( const auto & s : txTo - > vin [ nIn ]. qrWit )
if ( pubkey == s . pubKey )
return s . qrPubKey . Verify ( sighash , s . qrSig );
return false ;
}
return true ;
}
As we have added an additional area of data to the transaction, i.e. the qrWits,
we need to include a fingerprint of this data in the block that will contain this
transaction. Otherwise, adversaries could subsequently change this data when they
relay the block and other nodes would consider the transaction invalid. To this end,
we build a merkle tree of hashes of all the qrWits in the transactions of a block and
include it in a special script of the coinbase transaction. The hash of the coinbase
will be part of the merkle tree of all the transactions of the block, thus ensuring that
no one can alter any surrogate data of any transaction in a block. We could have
achieved the same goal by including the hash of the qrWits of a transaction in the
transaction itself, but for backwards compatibility reasons this is not possible as we
will explain.
67
5.2. QRWIT IMPLEMENTATION
As this protocol update is intended for soft fork deployment, we need to ensure that
old clients can also validate transactions with qrWit. However, if they would receive
such a transaction they would not be able to understand the format of the new
data. Hence, when a new node communicates with an old one, all the transactions
and blocks relayed will be stripped of the qrWit data. Thus, old nodes will consider
reveal transactions as normal transactions with just an ECDSA signature which
they will accept as they think such signatures are still valid.
For this reason, the merkle tree root in the block header has to be constructed
from stripped transactions so that old miners can validate them. At the same time,
new nodes know that the transaction has some extra data, the fingerprint of which
is included in the special script of the coinbase transaction. They will check that
the fingerprint matches the data and consequently validate the transaction.
Furthermore, in case a new node mistakenly sends a complete transaction with
the qrWit included, the old nodes should reject the transaction as soon as possible so
that they do not waste resources on transactions that they cannot even unserialize.
Hence we change the serialization format of a transaction as shown in the digram
below.
Original Serialization Format Updated Serialization Format
int nVersion int nVersion
vector < CTxIn > vin unsigned char dummy = 0 x00
vector < CTxOut > vout unsigned char flags (!= 0)
⇒ vector < CTxIn > vin
vector < CTxOut > vout
if ( flags & 2):
vector qrWits
uint nLockTime uint nLockTime
With this change, it is easy to see why old clients will immediately invalidate
such transactions. As vectors are serialized with their length first, old clients will
treat the dummy value as the length of the vector of inputs and any transaction with
no inputs is immediately rejected.
The flags variable is included there to mark the type of extra data we added.
In fact, this approach is already employed in Bitcoin for the implementation of
segregated witness (SegWit)[40], which uses the first bit of flags to mark extra
data serialized by them. Similarly, we reserve the second bit to mark our extra
data.
68
5.2. QRWIT IMPLEMENTATION
threshold
ST >= T reached
start DEFINED STARTED LOCKED_IN
Timeout Always
Timeout
FAILED ACTIVE
Figure 5.2: Finite state automata showing the different stages of a feature deploy-
ment using the Version Bits protocol. T denotes the current time and ST the
specified start time of the feature. Threshold reached refers to the fact that a cer-
tain percentage of the blocks in the last 2016 blocks signal the version bit of this
feature.
Therefore, to allow our protocol to be deployed in a manner that does not impact
other features and to allow the miners to upgrade their code at their own pace,
we implemented our code using the Version Bits technique. Hence, all consensus
critical changes we implemented such as surrogate validation and quantum resistant
signature verification only activate when the feature is in active state.
Therefore, to summarize the whole scheme, QRWit is a segregated transaction
area that is checked for the quantum resistant signature over the transaction, and
for the existence proof of the commit transaction.
69
Section 6: Related Work
Before we evaluate the overall success probability of QRWit, we would like to con-
struct a more complete picture of the existing proposals and alternative schemes
that we could find that aim to solve the same issue as our proposal, QRWit. With
the exception of Fawkescoin, which is a proposed cryptocurrency, none of the works
we found have formal descriptions. Before we go into these schemes, we would like to
present some general research done towards integrating Bitcoin in the post-quantum
era, even though it does not directly relate to our specific work.
As the possibility of quantum computers emerging in the near future is increas-
ingly appreciated by members of the Bitcoin community, a number of approaches to
make Bitcoin resilient against quantum-capable adversaries have recently appeared
online.
As we outline in Sections 3 and 4, a first step towards maintaining Bitcoin’s
security properties in a post-quantum world is replacing ECDSA with a signature
scheme that is at least believed to be quantum resistant. As presented in Section 2.5,
such schemes exist and are meant to be implemented on classical computers [28, 23,
64]. On the other hand, other proposals aim to provide quantum resistant signatures
by means of quantum hardware [32, 36, 31]. An alternative research direction focuses
on identifying alternatives to Proof-of-Work, as a countermeasure to possible unfair
advantages in mining through Grover’s algorithm [12, 33].
However, we will not focus on these works as they do not consider the issue our
paper is most interested in, i.e., transitioning Bitcoin in a post-quantum world in
the presence of an already fast quantum-capable attacker. Instead, we would like to
briefly analyse the following ideas and works. As very little data was available around
these proposals, we have contacted their authors and requested more explanations.
In some cases we obtained further details which we include here, while in others, we
learnt that the authors conceded their ideas, hence we will not mention them any
more. Furthermore, we would like to note that our scheme was developed completely
independently from all the ideas we are about to mention.
This method is presented on Twitter in a comment from Adam Back [6] and in
further explanations he offers [7, 8, 9]. From our understanding, the scheme follows
the structure of a two stage hash commitment. The first step is to commit to the
ECDSA public key and a quantum resistant public key in the form of a hashed
pair. This commitment would be stored in the OP_RETURN field of a transaction,
similarly to our scheme. The second step is to reveal the pair in plain-text in
another transaction that is signed against the quantum resistant public key. The
70
6.2. TIM RUFFING’S COMMITTED TRANSACTION
commitment ensures that the owner of the ECDSA public key, also controls the
quantum resistant public key, while the quantum resistant signature guarantees
QCs cannot modify the transaction.
This scheme is similar to out proposal, with the exception of the delay phase.
The lack of a sufficiently large delay period means quantum attackers have the
opportunity to rewrite the blockchain and insert their own commitment, thus being
able to steal the funds. It appears that Adam Back is aware [10] of this, but
assumes [11] Grover’s algorithm does not offer a considerable advantage in mining,
thus making massive chain rewrites impossible.
This scheme is clearly described on the Bitcoin-dev mailing list [65] and in the
discussions that led to it [66, 67]. The initial proposal suffered from multiple defi-
ciencies, as mentioned by the author, but the current version of the scheme seems
functional, although very rigid (i.e. the user has to create a transaction in advance
of actually broadcasting it). The general idea of the scheme is to secure a non-
quantum resistant transaction by first committing to it in a different transaction.
The commitment is enacted by symmetrically encrypting the unsafe transaction. To
guarantee that only someone who can consume the UTXOs being transitioned can
create such a commitment, the encryption key is the scriptSig itself.
Apart from this, the scheme also uses a tagging technique on the commitment
which eliminates the need for a link between the commit and the reveal transactions.
Similar to this, we found an improvement to our scheme that will allow users to self-
configure the delay period. We describe this in Section 8.
The question of long delay between commitment and reveal is not approached
and we would like to note that a delay actually affects the usability of this scheme
a lot. Although it might be feasible to predict spending in case of a delay of a few
blocks, it is certainly not feasible if the delay needs to be much larger. However, the
advantage of this scheme, as the author points out, is that the reveal transaction can
be immediately considered confirmed as its encrypted form was already committed
in the blockchain, so the community can trust this transaction.
6.3 Fawkescoin
This is a cryptocurrency relying only on secure hash functions, thus avoiding com-
pletely the need for public-key cryptography [20]. In this digital currency system,
each user holds a secret value which is used to provide ownership guarantees. Trans-
actions are implemented as a commit–reveal scheme, thus involving two interactions
with the blockchain for a single transfer. In this work, we present the basic mecha-
nism behind transactions. For a more detailed explanation, refer to the Fawkescoin
paper [20].
71
6.3. FAWKESCOIN
Assume that user OY , who holds secret Y , wants to receive some money from
user OX , who is in possession of secret X. To this end, the following steps are taken,
where H is a cryptographic hash function.
1. OY sends H(Y ) to OX .
3. A few blocks are added to the blockchain on top of the block including the
commitment. This is necessary to ensure immutability.
4. OX reveals (X, H(Y )). This act proves that OX owns any outputs to H(X).
72
Section 7: Evaluation
Having presented the theory behind QRWit, its practical implementation, and some
alternative schemes which achieve similar effects, we can evaluate our proposal both
theoretically and from the implementation perspective.
Furthermore, note that we have already provided a comparison with other schemes
that have the same goal as ours, in Section 6. Thus, the advantages of QRWit over
the other proposals are clear, i.e. it works even if quantum attackers can rewrite the
blockchain for limited periods of time, and is much more flexible in regards to when
and what types of UTXOs can be consumed.
Before we go into the actual analysis, we would like to clearly mention one of
QRWit’s drawbacks: the long security delay. Although, this delay is necessary in
the current implementation as we described in Section 4.1.2, there is another scheme
that we describe in Section 8 which solves this problem, letting the users to decide
for themselves how long to wait before commit and reveal.
Before ensuring that our code changes correctly implement the protocol rules en-
forced by QRWit, we need to show that the new scheme really is secure. To this end,
we will informally describe the requirements of a secure scheme in this scenario, and
show how the assumed capabilities of a quantum attacker do not offer any means of
hijacking a transaction. Through these, we can construct an adversarial model of
provable security, against which we can evaluate QRWit and determine if it meets
the requirements or not.
Furthermore, note that for our purposes, security only needs to refer to the
safe spending of funds under the presence of QC. We do not need to make any
additional claims about the type of outputs, as a quantum resistant output is just a
special case of a standard one (i.e. it requires a quantum resistant public key in the
challengeScript). In fact, for most outputs, it would be impossible to decide if they
are secured by ECDSA or a quantum resistant scheme, until they are consumed as
part of other transactions.
Without making any claims about the current security Bitcoin offers in the ab-
sence of quantum capable attackers, we can define the new notion of security (i.e.
in the presence of such attackers) by building on the former.
Definition 39 (Secure Spending of UTXOs)
A scheme for consuming (spending) UTXOs, in the presence of a quantum
capable attacker (QCA), is secure if and only if, the QCA is not more powerful
than a classical attacker, i.e. he cannot achieve anything more than what a classical
attacker can.
73
7.2. IMPLEMENTATION ANALYSIS
2. Given an ECDSA public key ( pk), can immediately compute the secret key
that was used to generate pk.
Therefore, we have to prove that Definition 39 holds under the new protocol
rules introduced by QRWit, as described in Section 4. First of all, any transactions
that consume quantum resistant UTXOs, are impossible to hijack by the QCA,
as he cannot forge quantum resistant signatures. Secondly, the commit and delay
phases of the protocol do not introduce any vulnerabilities, as there are no public
keys revealed during these stages, so a QCA cannot use his extra ability to gain an
advantage over a classical attacker. Thirdly, we have to analyse the main attack
point, Treveal .
During the reveal phase the ECDSA public key is revealed as part of Treveal .
However, for such a transaction to be valid, all the surrogate data must be valid.
This implies that any ECDSA public keys revealed must have an associated com-
mitment (H(pk, pkQR )) older than the security period tsec , and that any data signed
with ECDSA is also signed with a quantum resistant scheme. Thus, the QCA can
construct a valid transaction, that consumes the same input as the original one,
only if he manages to construct a quantum resistant signature over the data. As
he cannot break the quantum resistant signature scheme, the only option is to use
a a
a different quantum resistant private-public key pair, (skQR , pkQR ), that is under
a
his control. Furthermore, he also needs to have committed H(pk, pkQR ) in some
transaction older than tsec . It is impossible, even for a QCA, to construct such a
commitment as he did not have knowledge of pk at the time at which he should have
introduced the commitment in the blockchain. Thus, we conclude that a quantum
attacker cannot modify Treveal in any way.
Therefore, a quantum capable attacker does not benefit from his extra ability in
any way, hence he is equivalent to a classical attacker, as required by Definition 39.
For testing the implementation of our scheme, we have used both unit testing and
manual testing on a simulated blockchain over which we have full control. The former
tests target only the validity of the consensus rules and they act as a specification
of the protocol, while the manual testing allowed us to test real case scenarios and
also to create demonstrations that we can showcase when presenting the protocol.
74
7.2. IMPLEMENTATION ANALYSIS
To ensure that our core and most relevant functionality runs as expected, we decided
to write some unit tests that check the new transaction validation rules. We used
these tests as specification for the overall protocol. Naturally, these tests only regard
the reveal phase and the segregated data introduced in there. Using the current
Bitcoin code architecture, one can write unit tests that create transactions and then
send them through the standard verification pipeline, simulating the exact behaviour
of a network node who includes the transaction in the memory pool. Note that these
tests do not require a network or a blockchain to run as they will directly call the
functions which handle validation of transactions and blocks.
1. Transactions rejected when checking the surrogate data using the CheckSurrogate
function. This is the first check enforced by the new rules. Such transactions
can fail because one of the surrogates (qrWit) is invalid in the following ways:
(a) The surrogate public key is not quantum resistant. We tested this by
simply providing an ECDSA public key.
(b) The Tcommit referenced does not contain the hash of the pair of the pro-
vided ECDSA public key and quantum resistant public key. We tested
this by including some random data in Tcommit , instead of the actual hash.
(c) The proof of existence (i.e. a Merkle branch) given does not prove the
existence of Tcommit . This could happen for multiple reasons:
i. The Merkle branch does not generate the expected Merkle tree root.
ii. The Merkle branch references more than one transaction.
iii. The Merkle branch references one transaction, but it is not the hash
of Tcommit .
(d) Tcommit is not on the main chain. We tested this by creating an orphan
block that is not included in the main chain.
(e) Tcommit is on the main chain but it is not old enough. We tested this by
leaving a delay shorter than tsec between commit and reveal.
2. Transactions rejected when checking a signature. These tests are only inter-
ested in rejecting those transactions which do not provide valid signatures
under the new rules. Transactions that fall under this type of failure are:
(a) Transactions which present invalid ECDSA signatures. These would im-
mediately fail even by the old rules.
75
7.2. IMPLEMENTATION ANALYSIS
1. Remove the slice of data that represented the Merkle tree root. We achieved
this by computing the root in the test, searching for the binary data in the
serialised version of the block, and removing it.
2. Alter the slice of data that represented the Merkle tree root. To test this, we
had a similar approach as to the above case, but instead of removing the data
we simply flipped a random bit.
76
7.2. IMPLEMENTATION ANALYSIS
Bitcoin code base provides two main testing frameworks or modes of operation: the
testnet and the regtest.
Testnet
The testnet is an alternative blockchain with the same general rules as the actual
Bitcoin network. Coins on the testnet are completely separate, cannot be traded for
real bitcoins, and are supposed to have no value. The purpose of the testnet is to
allow application developers or bitcoin testers to experiment with their implemen-
tations, without actually paying the costs of transactions or having to worry that
their version of the code is broken.
For the changes we are trying to test, this framework is not useful because we
would need a majority of miners on the testnet to run our version of the code. If
we do not have a majority, then our rules would just never take effect. First of all,
the deployment through Version Bits would never activate. Secondly, if we would
manually activate the deployment, our client would basically drop all transactions
as it considers them invalid by the new rules. However, the rest of the network
would accept them so the blockchain would extend with blocks that we consider
invalid. Transactions created by our client with the segregated data in place, would
just look like normal transactions to the other miners as they would not even see
the segregated data.
One way to overcome this problem would be to spawn enough miners to exceed
the average hash power, so that we can construct a majority of miners. However,
this would require too much work and it would just not be efficient from a tester’s
point of view, as any small change would require each of the miners forming the
majority to upgrade.
Regtest
The regtest is one of the modes of operation of the Bitcoin client. It will instruct the
client not to connect to nodes on the real Bitcoin network, but to nodes specified
by the developer. As we do not require interaction with random nodes, this mode
is perfectly suitable to test our deployment. Furthermore, regtest lets developers
instantly create brand-new blocks that can be filled with no transactions. We will
use this feature to simulate the passing of time which is required for the delay phase.
Therefore, the tests we are interested in performing using regtest are those that
require node communication. From unit tests, we know that an individual node
will correctly validate transactions and blocks, but using manual tests through the
regtest mode, we can also test the communication between two nodes. As such, we
can check if blocks and transactions are correctly relayed by the upgraded nodes.
All upgraded nodes should see all transactions and blocks with the QRWit
present, hence being able to check the validity of that data as enforced by the
new rules. However, old nodes which did not upgrade should only see stripped
transactions which contain no QRWit data. The block will still contain the Merkle
77
7.2. IMPLEMENTATION ANALYSIS
tree root of all QRWits in the special location of the coinbase transaction, but they
will not try to validate it as they do not even understand what that data represents.
Thus, we have devised two manual tests that rely on regtest.
1. A new node communicating with an old node. In this case, we just aim to test
that any standard transactions are accepted by the old node. Furthermore, to
ensure that there is no mistake and the old node does not even see the QRWit
data, we send manually form blocks with invalid surrogate data and check that
the old node does not invalidate the block. In fact, he does not even receive
the invalid data.
2. A new node communicating with another new node. On the other hand, in
this scenario, the new node should be able to fully validate the data.
To conclude this section, we would like to note that the theoretical aspects of
the work described here have already been subject to peer review, as our paper [62]
was accepted for publication in a Blockchain Technology issue of the Royal Society
Open Science journal.
78
Section 8: Future Work
In this section, we present further improvements to QRWit that would enhance
usability thus increasing the chances of this scheme to be accepted by the Bitcoin
community. For each of the changes we mention in this section, we will also clearly
specify the issue they are addressing and the goals they achieve. We aim to describe
the enhancements both from a theoretical point of view and implementation wise.
As our current implementation of QRWit is only a proof of concept prototype,
we did not implement any of these changes, but we note that most of them could be
implemented with little code changes as the basic transaction validation mechanism
remains unchanged.
The improvements we address in this section aim to decrease the overall cost of
transitioning to quantum resistance. With the current scheme, users need to create
one commitment for each of their ECDSA public keys. However, we estimate that
Tcommit will be quite an expensive transaction, as it needs to be funded by UTXOs
secured with the new quantum resistant signature scheme and, under some scenarios,
such outputs might be very scarce, so their value would rise in comparison to the
non-quantum-resistant UTXOs. To solve this issue, we suggest to aggregate multiple
commitments of different ECDSA public keys under the same Tcommit .
However, one has to be very careful about how the aggregation is achieved in a
way that does not deanonymise the user, i.e. the scheme must not reveal any new
information about the user. In particular, it should not be possible to link multiple
public keys to the same owner, as this would allow attackers to gain information
that could lead to finding the owner’s real identity. In fact, even with the current
implementation, users should not commit different ECDSA keys to the same quan-
tum resistant key, as this would prove to the world that the ECDSA keys have the
same owner.
A naïve implementation, could try to optimise space by committing a list of
multiple (or all the) ECDSA public keys of a user to the same quantum resistant
public key. Although this would reduce space in both Tcommit and Treveal , it would
also act as evidence for everyone else that the keys belong to the same person.
79
8.1. COMMIT MULTIPLE KEYS
new data will be a Merkle Tree root constructed from multiple pair commitments.
More exactly, each leaf of the Merkle tree will contain the data that was previously
contained in Tcommit , as in Figure 8.1. Consequently, the root of the Merkle tree
will be included in the OP_RETURN output of Tcommit .
root
H(pk 1 ||pkQR
1
) H(pk 2 ||pkQR
2
) H(pk 3 ||pkQR
3
) H(pk 4 ||pkQR
4
)
Figure 8.1: Merkle tree of hash commitments. The green nodes are the leaves and
they each contain a hashed pair of keys. The blue nodes are intermediary nodes
composed by hashing the two children. The red node is the data that will be
included in Tcommit . pk i and pkQR
i
refer to keys of the same user i.
From the implementation perspective, the consensus rules validating the exis-
tence proof need to change to account for the fact that the hashed pair of keys is
now deeply buried in the root of the Merkle tree. To this end, the new segregated
area will also need to provide a Merkle branch that proves that the hash of the con-
catenated revealed keys (pk, pkQR ), is present inside the data committed in Tcommit .
The new Merkle branch required can be generated by the creator of the Merkle tree,
whoever he is. For space issues in Treveal , it might make sense to limit the size of
the Merkle tree (and thus the size of the branch) to prevent memory exhaustion
attacks.
Note that, this change does not weaken the security guarantees of the scheme
in any way, because faking a commitment in the Merkle tree requires breaking the
pre-image resistance of the cryptographic hash function.
Having described the improvement, we would like to point out that simply link-
ing to the same Tcommit from multiple ECDSA public keys, is not enough reason
for an attacker to believe that the keys have the same owner, as there could be,
and probably will be, service providers that post commitments on behalf of users.
Actually, this is a very probable scenario as users who do not own quantum resistant
UTXOs still need a way to commit.
Furthermore, using a service provider is economically better for all parties. The
providers will be able to combine different hash-pairs (from many users) into the
same Tcommit , which means that their cost is fixed regardless of how many key pairs
are committed. To prove to the client that the data given is indeed persisted in
the blockchain, they will send him a Merkle branch of the data in the tree, Tcommit ,
and the Merkle branch of Tcommit in the block. Thus, users can commit all of their
ECDSA public keys in one Tcommit , which they will reference every time they reveal
any of the keys.
80
8.2. FLEXIBLE COMMITMENT STRUCTURE
As we mentioned in Section 4.1.1, users can start committing their ECDSA public
keys to quantum resistant ones even now. However, in order to do this they would
need to know what quantum resistant signature scheme will be used, and the specific
format imposed by the validation format. It could be that the validation rules will
consider the commit data is included in the first OP_RETURN output (like our
current implementation), or maybe the rules will look for the commit data in some
other area of Tcommit that the community believes is better suited.
For the problem of where to place the commitment data (whatever that is: hash-pair
or Merkle root), we suggest some validation rules which do not decrease the security
of the scheme at all, while allowing users to place the data wherever they want in
the transaction. Instead of providing Tcommit in the qrWit segregated area, we could
provide three pieces of information:
1. prefix data – This is a slice of Tcommit from byte 0 to the first byte that is
part of the commitment data.
3. suffix data – This is another slice of Tcommit from the last byte of the com-
mitment data to the last byte in the transaction.
Concatenating these three pieces of data will create Tcommit , which can be checked
for existence in the blockchain as previously. The implementation changes that
should be done are obvious.
One of the most common objections to our scheme is the long delay phase. The
choice of how long the delay phase should be is sure to cause a massive debate in
the community. Some users will want very large periods out of precaution as they
believe QC to be extremely powerful, while other users will want to risk and choose
a short delay period as freezing their funds for long period of times is not acceptable.
As such, we will describe a variant of our scheme which offers configurable delays. To
understand why the scheme is structured as it is, we will first present an unsuccessful
attempt at creating a scheme with user-configurable delay.
81
8.3. USER-CONFIGURABLE DELAY
they feel confident that their commitment is immutable, even under the presence
of a quantum-capable attacker. However, this strategy has a major vulnerability
as attackers can listen for Treveal transactions (i.e. transactions with QRWit data),
retrieve the ECDSA public keys included, compute the private keys, create their own
commitments, and publish their own reveal transaction linking to their commitment,
all this while the owner’s Treveal is still in the memory pool. Thus, the attacker would
be able to steal any funds he wants given that he can complete the above actions
really fast.
To overcome the issue of griefing we have to change the strategy from first-seen to
first valid commitment. Where valid means that it must be possible to determine
if the commitment was created by the owner of the public key or by an adversary.
Thus, we will change the structure of the commitment data completely. The 80 byte
OP_RETURN output must now contain:
1. 1 byte flag that can indicate to miners that this is a commitment transaction.
This is needed so that miners know which UTXOs to index.
2. 32 bytes tag, H ′ (pk), that can link this transaction to the public key pk being
committed in it. This will be used by miners to index transactions. Note that
miners will need to index all transactions with a specific tag, rather than just
the first, as they do not know yet which ones are valid.
82
8.3. USER-CONFIGURABLE DELAY
With the above data in Tcommit , Treveal does not need the proof of existence any
more, as the commitment is indexed anyway. The new consensus rules would verify
a surrogate as follows.
From the revealed ECDSA public key, compute H ′ (pk) and use it to retrieve the
list of commitments for this tag. Only one of these commitments is created by the
real owner, and that is the first valid one. Given pk, we can check if a commit is
valid by doing the following:
1. Decrypt the validation data vd (last 15 bytes) using pk as key, i.e. DSpk (vd).
2. Check if the checksum of the first 12 bytes of vd matches the last 3 bytes of
vd.
Thus, this method solves the sole issue of the previous proposal as the only way
for somebody to construct a valid commitment for some pk, is to have access to pk.
Furthermore, note that this method can be combined with the strategy for ag-
gregating commitments, with a small change, i.e. The tag would be another Merkle
tree root, built from hashes of public keys that are committed inside this transac-
tion. As such, this would increase usability to the maximum, as users could commit
with low costs and reveal whenever they want. The delay is configurable in the sense
that it doesn’t exist any more. However, we still recommend a long delay between
commit and reveal as otherwise attackers could rewind the blockchain and include
a malicious commitment before the actual user.
83
Section 9: Conclusion
To conclude this paper, we would like to reiterate our contributions and accom-
plishments. We believe our most important achievement is the publication of the
theoretical part of this paper in a special issue (on Blockchain technology) of the
Royal Society Open Science journal [62].
We presented the basics of Elliptic Curve Cryptography and the workings of the
elliptic curve digital signature algorithm (ECDSA), which is the main vulnerability
in Bitcoin once quantum attackers appear. To place in context this breach of secu-
rity, we gave a short introduction to Bitcoin and explained how ECDSA is used and
what it guarantees. Furthermore, we illustrated the exact method through which
Quantum Computing enables attackers to break ECDSA and how scalable the QCs
would need to be for these attacks to be efficient. As alternatives to ECDSA, we
summarized some proposed quantum resistant cryptosystems, which will have to be
considered by the community.
In light of the emerging threat of quantum-capable adversaries in Bitcoin, we
have outlined how Bitcoin could become subject to theft of funds due to the exposure
of public keys. In particular, we showed how live transaction hijacking can be
achieved, and how it allows attackers to compromise any transactions published to
the network.
Thus, we have proposed QRWit, a commit–delay–reveal scheme, to allow for
the secure transition to a quantum-resistant signature scheme in Bitcoin. We have
explained the protocol, considering each phase individually, but we also offered an
alternative, more intuitive view, by regarding our changes as introducing quantum
resistant surrogate keys.
Given the theoretical specification of QRWit, we have shown how the underlying
protocol modifications can be implemented as a soft fork and how the initial commit
phase can be done even before QRWit is actually deployed.
For the security of the transition scheme, we emphasise the need for a sufficiently
long delay period and propose an initial period of 6 months in order to prevent
possible blockchain reorganisation. At the same time, we also provide a future
extension of QRWit which allows users to transition at their own pace if they believe
a shorter or longer delay is more suitable.
Furthermore, we mentioned all the other proposals which aim to solve the same
goal as QRWit and compared their usability and cost efficiency with ours. We also
individually evaluated the security model of QRWit, and the specific implementation
we provided.
Finally, we described a series of improvements which would further increase the
usability by decreasing the cost of the overall transition and by allowing users to
choose their own delay period.
84
Bibliography
[1] Bitcoin Cash. https://www.bitcoincash.org/. Accessed: 2018-02-18.
[13] American National Standards Institute. Public Key Cryptography for the
Financial Services Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA). ANSI X9.62, 2005.
85
BIBLIOGRAPHY
[25] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable.
In Financial Cryptography and Data Security, pages 436–454. Springer, 2014.
[26] R. Feynman. Theres plenty of room at the bottom. In Feynman and computa-
tion, pages 63–76. CRC Press, 2018.
86
BIBLIOGRAPHY
87
BIBLIOGRAPHY
[53] J. Proos and C. Zalka. Shor’s discrete logarithm quantum algorithm for elliptic
curves. arXiv preprint quant-ph/0301141, 2003.
[54] J. Proos and C. Zalka. Shor’s discrete logarithm quantum algorithm for elliptic
curves. arXiv preprint quant-ph/0301141, 2003.
[55] R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signa-
tures and public-key cryptosystems. Communications of the ACM, 21(2):120–
126, 1978.
88
BIBLIOGRAPHY
[61] Y. Sompolinsky and A. Zohar. Bitcoin’s security model revisited. arXiv preprint
arXiv:1605.09193, 2016.
[63] L. Tessler and T. Byrnes. Bitcoin and quantum computing. arXiv preprint
arXiv:1711.04235, 2017.
[70] Y. Yarom and N. Benger. Recovering OpenSSL ECDSA nonces using the
FLUSH+ RELOAD cache side-channel attack. IACR Cryptology ePrint
Archive, 2014:140, 2014.
89