mirror of
https://github.com/0xb100d/manifestos.git
synced 2025-12-17 08:04:20 +01:00
Create poelstra mimwim paper
This commit is contained in:
0xb100d
860
poelstra mimwim paper
Normal file
860
poelstra mimwim paper
Normal file
@@ -0,0 +1,860 @@
|
||||
http://mimblewimble.cash/20161006-WhitePaperUpdate-e9f45ec.pdf
|
||||
|
||||
Mimblewimble
|
||||
Andrew Poelstra∗
|
||||
2016-10-06 (commit e9f45ec)
|
||||
Abstract
|
||||
At about 04:30 UTC on the morning of August 2nd, 2016, an anonymous person using the
|
||||
name Tom Elvis Jedusor signed onto a Bitcoin research IRC channel, dropped a document hosted
|
||||
on a Tor hidden service[Jed16], then signed out. The document, titled Mimblewimble, described
|
||||
a blockchain with a radically different approach to transaction construction from Bitcoin, supporting
|
||||
noninteractive merging and cut-through of transactions, confidential transactions, and
|
||||
full verification of the current chainstate without requiring new users to verify the full history of
|
||||
any coins.
|
||||
Unfortunately, while the paper was detailed enough to comminicate its main idea, it contained
|
||||
no arguments for security, and even one mistake1
|
||||
. The purpose of this paper is to make
|
||||
precise the original idea, and add further scaling improvements developed by the author.
|
||||
In particular, Mimblewimble shrinks the transaction history such that a chain with Bitcoin’s
|
||||
history would need 15Gb of data to record every transaction (not including the UTXO set, which
|
||||
including rangeproofs, would take over 100Gb). Jedusor left open a problem of how to reduce
|
||||
this; we solve this, and combine it with existing research for compressing proof-of-work
|
||||
blockchains, to reduce the 15Gb to less than a megabyte.
|
||||
License. This work is released into the public domain.
|
||||
∗grindelwald@wpsoftware.net
|
||||
1https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_
|
||||
and_better/d61n7yd
|
||||
1
|
||||
Contents
|
||||
1 Introduction 2
|
||||
1.1 Overview and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
1.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2 Preliminaries 5
|
||||
2.1 Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
2.1.1 Standard Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
2.1.2 Sinking Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
2.2 Mimblewimble Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
3 The Mimblewimble Payment System 9
|
||||
3.1 Fundamental Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
3.2 The Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
3.3 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
3.3.1 Block Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
3.3.2 Proven and Expected Work . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
3.3.3 Sinking Signatures and Compact Chains . . . . . . . . . . . . . . . . . . . 14
|
||||
4 Extensions and Future Research 16
|
||||
5 Acknowledgements 17
|
||||
1 Introduction
|
||||
In 2009, Satoshi Nakamoto introduced the Bitcoin cryptocurrency[Nak09], an online currency system
|
||||
to allow peer-to-peer transfer of digital tokens. These tokens’ ownership is ascertained by the
|
||||
use of public keys, and transfer is accomplished by means of a public ledger, a globally replicated
|
||||
list of transactions which destroy unspent transaction outputs (UTXOs) and create new ones of
|
||||
equal value but different keys.
|
||||
All Bitcoin coins originate in coinbase transactions, transactions which create new outputs without
|
||||
destroying any old ones, and which are limited in value to maintain a fixed inflation schedule.
|
||||
Once created, they change hands by means of ordinary transactions. This means that new users, in
|
||||
10 order to fully verify that their view of the system is uncompromised (absent theft or illegal inflation),
|
||||
must download and validate the entire history from the system’s genesis in 2009 until today.
|
||||
In other words, they must download and “replay” every transaction that has ever occurred.
|
||||
Today the Bitcoin blockchain sits just shy of 100Gb on the author’s disk. Had Bitcoin used Con-
|
||||
fidential Transactions[Max15] (CT), each of the approximately 430 million outputs would consume
|
||||
2.5Kb each, totalling over a terabyte of historical data2
|
||||
.
|
||||
In this paper, we describe a research project to design a Bitcoin-like cryptocurrency, which
|
||||
achieves dramatically better scaling and privacy properties than Bitcoin. In particular, it allows
|
||||
2The author is aware of unpublished research that would reduce this quantity by about 25%; the total is still formidable.
|
||||
2
|
||||
removal of most historic blockchain data, including spent transaction outputs, rangeproofs and all,
|
||||
while still allowing users to fully verify the chain. Indeed, it is possible for the system to function
|
||||
20 even if no users retain the vast majority of historic blockchain data.
|
||||
Further, this currency allows transactions to be noninteractively combined (a la Coinjoin[Max13a])
|
||||
and cut-through[Max13b], eliminating much of the topological structure of the transaction graph. If
|
||||
this is done without publishing the original component transactions, the result is an enormous boon
|
||||
to user privacy, amplified by CT.
|
||||
Unfortunately, it accomplishes these goals at cost of sacrificing functionality.
|
||||
1.1 Overview and Goals
|
||||
Mimblewimble is a design for a cryptocurrency whose history can be compacted and quickly veri-
|
||||
fied with trivial computing hardware even after many years of chain operation. As a secondary goal,
|
||||
it should support strong user privacy by means of confidential transactions and an obfuscated trans-
|
||||
30 action graph. However, to achieve these goals, Mimblewimble cannot support a general-purpose
|
||||
scripting system such as that in Bitcoin. This precludes such functionality as zero-knowledge contingent
|
||||
payments[Max16], cross-chain atomic swaps[Nol13] and micropayment channels[PD16].
|
||||
Further research is needed to emulate these functionalities on top of Mimblewimble, and is discussed
|
||||
in Section 4.
|
||||
More precisely,
|
||||
• Direct transfer of value between parti(es) to other parti(es) should be possible on the system.
|
||||
• All transactions should use confidential transactions to blind their output amounts.
|
||||
• Transactions should be noninteractively aggregable[Mou13], i.e. support a noninteractive
|
||||
variant of CoinJoin[Max13a, Max13b], such that parties not privy to the original transactions
|
||||
40 are unable to separate them. This can improve censorship resistance and privacy, though it is
|
||||
unclear how to design a safe peer-to-peer network capable of exploiting this ability.
|
||||
• For a new participant, the amount of bandwidth and processing power needed to catch up
|
||||
with the system should be proportional to the current state of the system, i.e. the size of the
|
||||
UTXO set plus rangeproofs, rather than the total size of all historical transactions.
|
||||
As described in the next section, and more thoroughly in Section 3.3, Mimblewimble has
|
||||
a scheme for compressing blockchain history to a size polylog in the original size, which in
|
||||
practice for a system with Bitcoin’s scale should allow a decade or more of transaction history
|
||||
to be verified in several seconds using a couple megabytes of data3
|
||||
.
|
||||
3Experiments with the compact chains described in this paper suggest that a 500000 block chain may have a compact
|
||||
length of around 300 blocks (though with high variance across multiple experiments), each containing sinking signatures
|
||||
which average ten 96-byte elliptic curve points, merkle commitments to previous blocks consisting of forty 40-byte (blockhash,
|
||||
difficulty) pairs, and some extra block header data, totalling less than 3Kb of data. Across 300 blocks this is 900Kb
|
||||
total of compact chain data. Verification time is dominated by pairing computations, of which there are on average ten per
|
||||
block, or 3000. On the author’s laptop using Ben Lynn’s libpbc library, these can be done in under 20 seconds using a
|
||||
single core. By more careful choice of elliptic curve, and focused optimization work, this number can surely be improved.
|
||||
3
|
||||
On the other hand, Bitcoin’s current state of 40 million unspent outputs would grow to 100Gb
|
||||
50 and a few days of verification on a modern CPU, thanks to Mimblewimble’s use of confidential
|
||||
transitions. It is an open problem how to improve this. We observe that even without
|
||||
cryptographic improvements, it would go a long way to simply cap the UTXO set size as a
|
||||
function of blockheight and let the transaction-fee market take care of it.
|
||||
1.2 Trust Model
|
||||
Like Bitcoin, Mimblewimble is a blockchain-based cryptocurrency intended to be instantiated in
|
||||
a decentralized manner in which users may join or leave the system at any time. Further, upon
|
||||
(re)joining the network, users should be able to determine the network state, at least up to some
|
||||
recent time, and verify that this state was obtained by a series of valid state transitions, without
|
||||
trusting the honesty of any third parties.
|
||||
60 However, there are two points of departure from Bitcoin’s trust model:
|
||||
1. Unlike Bitcoin, whose blockchain describes every transaction in its entirety, and therefore
|
||||
allows all users to agree on and verify the precise series of transactions that led to the current
|
||||
chainstate, Mimblewimble only allows users to verify the essential features:
|
||||
• A transaction, once committed to the block, cannot be reversed without rewriting the
|
||||
block (or by the owner(s) of its outputs explicitly undoing it).
|
||||
• The current state of all coins was obtained by zero net theft or inflation: there are exactly
|
||||
as many coins in circulation as there should be, and there for each unspent output there
|
||||
exists a path of transactions leading to it, all of which are committed in the chain and
|
||||
authorized.
|
||||
70 Note that there may be other paths which have also been committed in the chain, during
|
||||
which some transactions may have been invalid or unauthorized or inflationary, but
|
||||
since a legitimate path exists, all these things must have netted out to zero.
|
||||
2. Like Bitcoin, verifiers may see multiple differing blockchains, and select the valid one as the
|
||||
one with the greatest total work. This is detailed in Section 3.3.2.
|
||||
However, in Bitcoin the total work represents both the expected work to produce such a
|
||||
blockchain as well as the proven work of the chain, in the sense that any party who expends
|
||||
significantly less than this much work will be unable to produce such a chain except with
|
||||
negligible probability.
|
||||
Mimblewimble, on the other hand, separates these. The total work still represents the ex-
|
||||
80 pected work to produce the blockchain, and therefore incentivizes rational actors to contribute
|
||||
to the most-work chain rather than rewriting it. The proven work, on the other hand, is
|
||||
capped at some fixed value independent of the length of the chain, and serves to make forgery
|
||||
by irrational lucky actors prohibitively expensive.
|
||||
4
|
||||
2 Preliminaries
|
||||
2.1 Cryptographic Primitives
|
||||
Groups. Throughout, G1, G2 will denote elliptic curve groups adorned with an efficiently computable
|
||||
bilinear pairing ˆe : G1 ×G2 → GT , with GT equal to the multiplicative group of Fq
|
||||
k for some
|
||||
prime q, small positive integer k. We further require both G1 and G2 to have prime order r. Let G, H
|
||||
be fixed generators of G1 whose discrete logarithms relative to each other are unknown (i.e. they are
|
||||
90 nothing-up-my-sleeve (NUMS) points; G2 does not need any canonical generators. We will make
|
||||
computational hardness assumptions about these groups as needed. We write Zr for the integers
|
||||
modulo r, and write + for the group operation in all groups.
|
||||
All cryptographic schemes will have an implicit GenParams(1
|
||||
λ
|
||||
) phase which generates r, G1,
|
||||
G2, GT , G and H uniformly randomly given a security parameter λ.
|
||||
2.1.1 Standard Primitives
|
||||
Definition 1. A commitment scheme is a pair of algorithms Commit(v,r) → G , Open(v,r,C) →
|
||||
{true,false} such that Open(v,r,Commit(v,r)) accepts for all (v,r) in the domain of Commit. It
|
||||
must satisfy the following security properties.
|
||||
• Binding. The scheme is binding if for all (v,r) in the domain of Commit, there is no (v
|
||||
0
|
||||
,r
|
||||
0
|
||||
) 6=
|
||||
(v,r) such that Open(v
|
||||
0
|
||||
,r
|
||||
0
|
||||
100 ,Commit(v,r)) accepts. It is computationally binding if no PPT
|
||||
algorithm can produce such a (v
|
||||
0
|
||||
,r
|
||||
0
|
||||
) with nonneglible probability.
|
||||
• Hiding. The scheme is (perfectly, computationally) hiding if the distribution of Commit(v,r)
|
||||
for uniformly random r is (equal, computationally indistinguishable) for different values of v.
|
||||
Definition 2. We define a homomorphic commitment scheme as one for which there is a group
|
||||
operations on commitments and Commit is homomorphic in its value parameter. That is, one where
|
||||
commitments to v, v0
|
||||
can be added to obtain a commitment to v + v
|
||||
0 having the same security
|
||||
properties.
|
||||
Example 1. Define a Pedersen commitment as the following scheme: Commit : Z
|
||||
2
|
||||
r → G maps (v,r)
|
||||
to vH +rG, and Open : Z
|
||||
2
|
||||
r ×G → {true,false} checks that Commit(v,r) equals vH +rG.
|
||||
110 If the discrete logarithm problem in G is hard, then this is a computationally binding, perfectly
|
||||
hiding homomorphic commitment scheme[Ped01].
|
||||
Definition 3. Given a homomorphic encryption C, we define a rangeproof on C as a cryptographic
|
||||
proof that the committed value of C lies in some given range [a,b]. We further require that rangeproofs
|
||||
are zero-knowledge proofs of knowledge (zkPoK) of the opening information of the commitments.
|
||||
Unless otherwise stated, rangeproofs will commit to the range [0,2
|
||||
n
|
||||
] where n is small enough
|
||||
that no practical amount of commitments can be summed to produce an overflow.
|
||||
We may use, for example, the rangeproofs described in [Max15] for Pedersen commitments,
|
||||
which satisfy these criteria.
|
||||
5
|
||||
120 2.1.2 Sinking Signatures
|
||||
This brings us to the first new primitive needed for Mimblewimble.
|
||||
Definition 4. We define a sinking signature as the following collection of algorithms:
|
||||
• Setup(1
|
||||
λ
|
||||
) outputs a keypair (sk,pk);
|
||||
• Sign(sk,h) takes a secret key sk and nonnegative integer “height” h which is polynomial in
|
||||
λ, and outputs a signature s.
|
||||
• Verify(pk,h,s) takes a public key pk and signature s and outputs from {true,false}.
|
||||
satisfying the following security and correctness properties:
|
||||
• Correctness. For all polynomial h, (sk,pk) ← Setup(1
|
||||
λ
|
||||
), s ← Sign(sk,h), we have that
|
||||
Verify(pk,h,s) accepts.
|
||||
• Security. Let (·,pk) ← Setup(1
|
||||
λ
|
||||
130 ). Then given pk and an oracle H which given h returns
|
||||
Sign(sk,h), no PPT algorithm A can produce a pair (s,h
|
||||
0
|
||||
) with h0 > h for all h given to the
|
||||
oracle, and Verify(pk,h
|
||||
0
|
||||
,s) accepts. (Except with negligible probability.)
|
||||
The name “sinking signature” is motivated by the fact that given a signature s on height h, it
|
||||
may be possible for a forger to create a signature s
|
||||
0 on height h
|
||||
0 with the same public key and h
|
||||
0 ≤ h,
|
||||
thus “decreasing the height” of the signature. We will use this feature later to aid scalability for a
|
||||
Mimblewimble chain.
|
||||
Definition 5. We say a sinking signature is aggregatable or summable if given a a linear combination
|
||||
pk of pki
|
||||
values computed from Setup(1
|
||||
λ
|
||||
), the same linear combination of si ← Sign(ski
|
||||
,h)
|
||||
(for fixed h) it is possible to compute a signature s such that Verify(pk,h,s) accepts.
|
||||
140 For a summable sinking signature, we generalize the above security game to allow the adversary
|
||||
A to play polynomially many times in parallel and win with an arbitrary linear combination of its
|
||||
received public keys. (It must also provide the coefficients of the linear combination.)
|
||||
Definition 6. We propose the following summable sinking signature (Poelstra, Kulkarni). Let H2
|
||||
be a random oracle hash with values in G2.
|
||||
• Setup(1
|
||||
λ
|
||||
) chooses a uniformly random sk ← Zr and sets pk = sk ·G.
|
||||
• Sign(sk, x) first computes the sequence {x0,..., xn} where x0 = x and xi+1 is obtained by
|
||||
subtracting from xi
|
||||
the largest power of 2 that divides it (i.e., by clearing its least significant
|
||||
1 bit). We observe that xn = 0 and that n is one plus the number of one bits in x and is
|
||||
therefore O(log2
|
||||
x).
|
||||
Finally, it outputs s = {sk ·H2(xi}
|
||||
n
|
||||
i=0
|
||||
150 .
|
||||
• Verify(pk, x,{si}) computes S as the sum of all si
|
||||
, computes H = ∑
|
||||
n
|
||||
i=0H2(xi), and checks
|
||||
that e(G,S) = e(pk,H).
|
||||
6
|
||||
Observe that the verification step uses only the sum S of the elements of the signature. However,
|
||||
the extra data will be useful later, so we state it here so we can prove the scheme is secure with it.
|
||||
Correctness and summability of the scheme are immediate.
|
||||
Theorem 1. This is a secure summable sinking signature, in the following sense: if an adversary
|
||||
A exists which wins the game described in Definition 5, a simulator B exists which can solve the
|
||||
computational co-Diffie-Hellman (co-CDH) problem for (G2,G1), given oracle access to A .
|
||||
Proof. B answers random oracle queries to H and works in the following way. (Recall that the
|
||||
160 game in Definition 5 is the game from Definition 4 played in parallel.)
|
||||
We suppose without loss that before making signature queries on any height x, the adversary first
|
||||
all random oracle queries needed to verify such a signature; similarly before producing a forgery on
|
||||
height x
|
||||
∗
|
||||
it makes the required queries. We then suppose that in total it requests at most qp public
|
||||
keys and makes at most qh random oracle queries.
|
||||
1. B receives a co-CDH challenge (G,P,Q) from its challenger, where G,P ∈ G1, Q ∈ G2, and
|
||||
the goal is to produce R ∈ G2 such that ˆe(P,Q) = eˆ(G,R).
|
||||
2. B responds to the ith public key request by generating a uniformly random keypair (xi
|
||||
,Pi)
|
||||
and replies with Pi +P.
|
||||
3. B responds to the jth random oracle query by generating a uniformly random keypair (y j
|
||||
,Hj)
|
||||
except that Hj
|
||||
∗ = Q for j
|
||||
∗
|
||||
$←− {1,...,qh}, and replying with Hi
|
||||
170 .
|
||||
4. B responds to the kth signature query on height h
|
||||
k
|
||||
and pubkey P
|
||||
k
|
||||
as follows: it computes
|
||||
the sequence {h
|
||||
k
|
||||
n} and checks if any of the H(h
|
||||
k
|
||||
n
|
||||
) values is Q; if so, it aborts.
|
||||
Otherwise, for each i{0,...,n} it knows a zi such that H(h
|
||||
k
|
||||
i
|
||||
) = ziG and produces s = {ziP}i
|
||||
.
|
||||
5. Finally, A wins by producing a forgery consisting of coefficients {ci}
|
||||
m
|
||||
i=1 with not all ci zero,
|
||||
a pubkey P
|
||||
∗ = ∑
|
||||
m
|
||||
i=1
|
||||
ci(Pi+P), a height h
|
||||
∗ greater than any h
|
||||
∗
|
||||
thus queried on, and a signature
|
||||
s
|
||||
∗ = {Si} such that ∑
|
||||
n
|
||||
∗
|
||||
i=0
|
||||
e(G,Si) = ∑
|
||||
n
|
||||
∗
|
||||
i=0
|
||||
e(P
|
||||
∗
|
||||
,H(h
|
||||
∗
|
||||
i
|
||||
)).
|
||||
6. If some H(h
|
||||
∗
|
||||
i
|
||||
∗ ) = Q, then for the above sum to hold, writing x
|
||||
∗
|
||||
for P
|
||||
∗ = x
|
||||
∗G, we must have
|
||||
n
|
||||
∗
|
||||
∑
|
||||
i=0
|
||||
Si =
|
||||
n
|
||||
∗
|
||||
∑
|
||||
i=0
|
||||
y
|
||||
∗
|
||||
i P
|
||||
∗
|
||||
for y
|
||||
∗
|
||||
i
|
||||
such that H(h
|
||||
∗
|
||||
i
|
||||
) = y
|
||||
∗
|
||||
i G
|
||||
=
|
||||
n
|
||||
∗
|
||||
∑
|
||||
i=0
|
||||
m
|
||||
∑
|
||||
j=1
|
||||
[cjxjy
|
||||
∗
|
||||
i G+cjy
|
||||
∗
|
||||
i P]
|
||||
=
|
||||
n
|
||||
∗
|
||||
∑
|
||||
i=0
|
||||
m
|
||||
∑
|
||||
j=1
|
||||
[cjxjH(h
|
||||
∗
|
||||
i
|
||||
) +cjy
|
||||
∗
|
||||
i P]
|
||||
=
|
||||
m
|
||||
∑
|
||||
j=1
|
||||
cjR+
|
||||
n
|
||||
∗
|
||||
∑
|
||||
i=0
|
||||
i6=i
|
||||
∗
|
||||
m
|
||||
∑
|
||||
j=1
|
||||
[cjxjH(h
|
||||
∗
|
||||
i
|
||||
) +cjy
|
||||
∗
|
||||
i P]
|
||||
where R is the solution to B’s CDH challenge, and every other term is computable by B.
|
||||
7
|
||||
To complete the proof, we must show that we abort with probability bounded away from 1,
|
||||
and that our win condition occurs with nonneglible probability. We observe that we only abort if
|
||||
180 the attacker asks for a signature that requires Q be used, and we win if Q is used in the attacker’s
|
||||
forgery.
|
||||
Both occur if H(h
|
||||
∗
|
||||
) = Q, which has probability 1/qh, which completes the proof.
|
||||
2.2 Mimblewimble Primitives
|
||||
Definition 7. A Mimblewimble transaction is the following data:
|
||||
• A list of homomorphic commitments termed the inputs, with attached rangeproofs. Alternately,
|
||||
inputs may be given as explicit amounts, in which case they are treated as homomorphic
|
||||
commitments to the given amount with zero blinding factor.
|
||||
• A list of homomorphic commitments termed the outputs, with attached rangeproofs.
|
||||
• A blockheight x.
|
||||
190 • An excess commitment to zero, with a summable sinking signature on blockheight x with this
|
||||
as pubkey.
|
||||
We make the further restriction on transactions that every input within a transaction be unique.
|
||||
Definition 8. We define the sum of a transaction to be its outputs minus its inputs, plus its excess.
|
||||
If
|
||||
• the sum is zero4
|
||||
, and
|
||||
• the rangeproofs and sinking signature are valid
|
||||
then we say the transaction is valid.
|
||||
Definition 9. We define the canonical form of a transaction T as the transaction equal to T except
|
||||
if any input is equal to an output, both are removed.
|
||||
200 Notice that the canonical form of any transaction has equal sum to the original transaction; in
|
||||
particular a transaction is valid if and only if its canonical form is valid.
|
||||
We observe that all valid transactions are noninflationary; the total output value must be equal
|
||||
to the total input value.
|
||||
Definition 10. Given a finite set of transactions {Ti} with pairwise disjoint input sets, we define the
|
||||
cut-through of {Ti} as the canonical form of the union of all Ti’s.
|
||||
Next, we define some terms that will allow us to treat Mimblewimble transactions as mechanisms
|
||||
for the transfer of value within a blockchain.
|
||||
Definition 11. (Ownership.) We say that a party S owns a set of transaction outputs if she knows
|
||||
the opening of the sum of the outputs.
|
||||
4By zero we mean the homomorphic commitment which commits to zero with zero blinding factor.
|
||||
8
|
||||
210 Definition 12. (Sending n coins.) To send n coins from S to R, S produces a transaction: chooses
|
||||
inputs, creates uniformly random change output(s) and a uniformly random excess, whose sum is a
|
||||
commitment to n. S sends this to R along with the opening information of the sum.
|
||||
Definition 13. (Receiving n coins.) To receive n coins, R receives a transaction T0 which sums to a
|
||||
commitment of m ≥ n coins, along with opening information of this sum, and completes it to a valid
|
||||
transaction T by the following process:
|
||||
1. R first produces uniformly random outputs whose total committed value is n, and adds these
|
||||
to the transaction.
|
||||
2. If m = n, R negates the sum of this transaction and adds it to the excess of the transaction, so
|
||||
that the total sum is now zero. (It also computes a summable sinking signature for the amount
|
||||
220 added, and adds this to the original signature, so that the final excess has a valid signature
|
||||
on it.)
|
||||
Otherwise the transaction now has sum committing to m−n, so R adds a uniformly random
|
||||
value to excess, updates the signature, and gives the opening information of the new sum to
|
||||
another recipient who can take the remaining value.
|
||||
When we define a blockchain and require transaction inputs to be outputs of earlier transactions,
|
||||
we will show that after this process, R is the only party who owns any of the outputs that he added.
|
||||
3 The Mimblewimble Payment System
|
||||
3.1 Fundamental Theorem
|
||||
Theorem 2. (Fundamental Theorem of Mimblewimble) Suppose we have a binding, hiding ho-
|
||||
230 momorphic commitment scheme. Then no algorithm A can win at the following game against a
|
||||
challenger C except with negligible probability:
|
||||
1. (Setup.) C computes a finite list L of uniformly random homomorphic commitments. C sends
|
||||
L to A .
|
||||
2. (Challenge.) At most polynomially many times, A selects some (integer) linear combination
|
||||
Ti of L and requests the opening of this combination from C . C obliges.
|
||||
3. (Forgery.) A then chooses a new linear combination T which is not a linear combination of
|
||||
{Ti} and reveals the opening information of T .
|
||||
Proof. Consider the lattice Λ of formal linear combinations generated by L, that is, the set {∑A∈L bAA :
|
||||
bA ∈ Z}. Consider the quotient lattice Λ/Γ where Γ is the sublattice of Λ generated by the queries
|
||||
240 {Ti}. We may consider every element of Λ/Γ to be a homomorphic commitment by using some
|
||||
canonical representative. In particular, every element of Λ/Γ is a homomorphic commitment which
|
||||
satisfies the same hiding/blinding properties that the original scheme did.
|
||||
9
|
||||
Then the projection of every {Ti} into Λ/Γ is zero, and the projection of T is nonzero. Therefore
|
||||
A has learned no information about the projection of T from its queries; however, if A knows the
|
||||
opening of T then it also knows the opening of the projection of T, contradicting the hiding property
|
||||
of the homomorphic commitment scheme.
|
||||
3.2 The Blockchain
|
||||
Mimblewimble consists of a blockchain, which is a weighted-vertex directed rooted tree of blocks
|
||||
(defined below) for which the highest-weighted path is termed the consensus history.
|
||||
250 Definition 14. We define a Mimblewimble block as the following data:
|
||||
• A canonical transaction, whose inputs are of one of the two forms:
|
||||
– A reference to an output of the transaction in an earlier block; or
|
||||
– An explicit (i.e. with zero blinding factor) input restricted by rules above those given in
|
||||
this paper5
|
||||
.
|
||||
• A block header, which has a binding commitment to earlier blocks in the chain, termed backlinks;
|
||||
a commitment to the current UTXO set after this block’s transaction has taken effect;
|
||||
and the transaction included in this block.
|
||||
If the block’s transaction is valid, we say the block is valid.
|
||||
In Section 3.3, we will describe how blocks are weighted, and which previous blocks specifically
|
||||
260 should be linked to. For now we may use Definition 14 as our definition of validity, though note
|
||||
that there will be additional requirements on the commitments.
|
||||
Definition 15. We define the consensus chain state of a Mimblewimble blockchain as the cutthrough
|
||||
of all transactions on the consensus history.
|
||||
If the consensus chain state is valid, we call the blockchain valid.
|
||||
Note that for a blockchain to be valid, it is not required that all blocks be valid, only that the
|
||||
entire chain sum to a valid transaction.
|
||||
Next, we prove that Mimblewimble is a sound payment system, in the sense of the following
|
||||
two theorems.
|
||||
Theorem 3. (No inflation.) The total value committed by the outputs of the consensus chainstate of
|
||||
270 a valid blockchain is equal to the value of the explicit inputs in each block.
|
||||
Proof. By hypothesis the consensus chain state, which is the canonical form of the cut-through of
|
||||
all transactions, is valid. Since every non-explicit input of every block is the output of a previous
|
||||
transaction, it does not appear in this canonical form. Therefore the only inputs of the chain state
|
||||
are the explicit ones.
|
||||
5A typical rule would be that each block can have only a single coinbase input of fixed value.
|
||||
10
|
||||
Lemma 1. (Unique ownership.) Suppose that all outputs of a transaction were created by receiving
|
||||
coins as in Definition 13 or sending as in Definition 12, so that all blinding factors are kept secret.
|
||||
Then for every subset of outputs in which not all have not been sent, the only owner of that subset
|
||||
is the person who created all its outputs. (In particular, if the subset contains outputs created by
|
||||
different parties, then that subset has no owner.)
|
||||
280 Proof. Let O be an output in the subset which has not been sent. Then the only combination of
|
||||
outputs containing O whose commitment included O that may have been revealed also included
|
||||
some uniformly random excess E which was chosen when O was created.
|
||||
Further no other sum containing E was ever revealed, so that any combination including O but
|
||||
not E is not a linear combination of combinations whose opening information has been revealed.
|
||||
The subset in question does not contain E, since E is an excess not an output. Therefore by Theorem
|
||||
2 nobody knows the opening information of the subset except the person who created O.
|
||||
Theorem 4. (No theft.) Consider a valid blockchain. An output x created as in Definition 13
|
||||
cannot be removed from the consensus chain state without replacing the block in which it appeared,
|
||||
i.e., forming a higher-weighted valid blockchain not containing this block, except by parties who
|
||||
290 (collectively) own a set U of outputs containing x.
|
||||
Proof. Suppose otherwise; then there exists a higher-weighted chain containing the block B in
|
||||
which x appeared, but for which the consensus chain state does not contain x.
|
||||
Consider the transaction T which is the canonical form of the cut-through of the first block after
|
||||
B to the tip of the chain. (Note that T may not be valid; we know only that the full chain states are
|
||||
valid.)
|
||||
Then the outputs of T are a subset of the outputs of the new chain state; in particular they contain
|
||||
rangeproofs which are proofs of knowledge of the openings of the outputs. Similarly, the excess
|
||||
value is also known. We conclude that the parties who created these blocks (and therefore T) know
|
||||
the openings of all outputs and sum of the excess value, and therefore own the set of all inputs of T.
|
||||
300 However, the inputs of T form a set of outputs containing x, completing the proof.
|
||||
3.3 Consensus
|
||||
Mimblewimble uses a hashcash[Bac02] style blockchain in which every block in a blockchain is
|
||||
labelled by a weight called its difficulty. A blockchain is valid if every block of difficulty D has a
|
||||
header which hashes into a range of size 1/D of the total space of hashes. We define a directed edge
|
||||
from block A to B iff A commits to B in its header, and require each block commit to its unique
|
||||
parent.
|
||||
We can then refine our definition in Section 3.2 of consensus history as the highest-weighted
|
||||
path terminating at the root. This is the same as Bitcoin’s design.
|
||||
3.3.1 Block Headers
|
||||
310 However, in we also define a second graph structure on blocks as vertices, called the compact
|
||||
blockchain. We define the compact blockchain iteratively as follows.
|
||||
11
|
||||
1. The genesis block is in the compact blockchain.
|
||||
2. The first block after the genesis is added to the compact blockchain, and is assigned effective
|
||||
difficulty equal to its difficulty.
|
||||
3. Each new block is added to the tip of the compact blockchain, and may cause blocks to be
|
||||
removed from the compact chain as follows:
|
||||
(a) First, its effective difficulty is calculated as follows. Consider the “maximum possible
|
||||
difficulty” M of the block, which is the size of the hash space divided by the hash of the
|
||||
block. (This may be larger than the actual difficulty.)
|
||||
320 The effective difficulty is determined by starting with the block’s difficulty, then adding
|
||||
the effective difficulties of as many consecutive blocks as possible, starting from the tip,
|
||||
so that the total is less than or equal to M.
|
||||
(b) All blocks whose effective difficulty was used in the above calculation, except the new
|
||||
block itself, are dropped from the compact chain.
|
||||
The compact blockchain is encoded in the real blockchain by having every block commit to a merkle
|
||||
sum tree (with effective difficulty the quantity being summed) of all blocks in the current compact
|
||||
chain.
|
||||
We next prove several theorems to give an intuition of the properties of the compact blockchain.
|
||||
Lemma 2. The expected work required to produce a block with effective difficulty D is equivalent to
|
||||
computing D hashes; similarly to produce several blocks with total effective difficulty D0
|
||||
330 one must
|
||||
do expected work of computing D0 hashes.
|
||||
Proof. This is immediate in the random oracle model.
|
||||
Theorem 5. The expected amount of work to replace a block B in the compact chain (i.e. produce
|
||||
a blockchain of greater or equal total difficulty whose compact chain does not contain B) is greater
|
||||
than or equal to the work needed to replace B, its parent in the non-compact chain, its parent, and
|
||||
so on, up to but not including B’s parent in the compact chain.
|
||||
Proof. This follows immediately from Lemma 2 and the fact that the effective difficulty of every
|
||||
block is defined to be greater than or equal to the sum of the difficulty of the skipped blocks.
|
||||
Corallary 1. The expected work required to produce a compact blockchain is at least as large as
|
||||
340 the expected work required to produce a full chain containing the same blocks.
|
||||
Theorem 6. Assuming constant difficulty, given a blockchain of length N, the expected length of
|
||||
the compact chain will be O(logN).
|
||||
Proof. The compact chain has been defined such that the proof in [BCD+14, Appendix A] still
|
||||
holds. We summarize it here:
|
||||
12
|
||||
1. First, consider starting from the tip and scanning backward until we find a block that can skip
|
||||
all remaining blocks back to the genesis. By construction this block will be in the compact
|
||||
chain. The probability that such a block exists within the first x blocks we check is
|
||||
1−
|
||||
x
|
||||
∏
|
||||
i=1
|
||||
N −i
|
||||
N −i+1
|
||||
= 1−
|
||||
N −x
|
||||
N
|
||||
=
|
||||
x
|
||||
N
|
||||
and the expectation of this over all 1 ≤ x ≤ N is N+1
|
||||
2
|
||||
, i.e. we expect the chain length to be
|
||||
halved by this one skip.
|
||||
350 2. Inductively, we can scan back from the tip until we find a block that skips back to the block
|
||||
in the previous step. This halves (in expectation) the remaining chain, and so on.
|
||||
The number of times we repeat this process until we have no more blocks to skip is the length of
|
||||
the compact chain, since each step added one more block to the compact chain, and since each step
|
||||
halved the number of remaining blocks, we see that there are only logarithmically many steps.
|
||||
We observe that small variations in difficulty do not affect the character of this proof, and therefore
|
||||
the constant-difficulty case can be considered a good approximation to the real-world situation.
|
||||
Theorem 7. Given a blockchain B (for the purpose of this theorem, we considering B to be only the
|
||||
most-work path), there is exactly one compact chain C ⊆ B. Further, verifiers can determine that
|
||||
that C is the compact chain given only the blocks of C and the opening of each block’s commitment
|
||||
360 to the previous in the compact chain. Finally, no blocks in B\C will appear in the compact chain
|
||||
of any extension of B (i.e. once a block is dropped it may be forgotten forever).
|
||||
Proof. By construction, a compact chain C exists which is a subset of B. Suppose that some other
|
||||
compact chain C
|
||||
0 6= C of B also exists. Let C← be the longest path from the tip contained in both
|
||||
C
|
||||
0
|
||||
and C (since the tip itself is in both C
|
||||
0
|
||||
and C by construction, this is nonempty), and let β be the
|
||||
deepest block of C←.
|
||||
Now, the block preceding β must differ in C and C; however, this is impossible since β commits
|
||||
to an ordered Merkle sum tree of previous blocks in the compact chain, the “preceding block” must
|
||||
be the first one that β’s hash is not small enough to skip, and this is uniquely specified by the shape
|
||||
of the Merkle sum tree. We conclude that C
|
||||
0 = C.
|
||||
370 Next, we argue that when B is extended, no blocks of B\C are added to the compact chain. But
|
||||
this is immediate, since by construction only new blocks are ever added to a compact chain.
|
||||
3.3.2 Proven and Expected Work
|
||||
However, while the expected work can be computed to be the same, the the compact chain does not,
|
||||
in general, prove as much work as the full chain. Here by “proving an amount of work” we mean
|
||||
that a prover who does less than this amount of work has negligible chance of producing the chain.
|
||||
For example, consider a blockchain of total difficulty D across n blocks, whose compact chain has
|
||||
logn blocks.
|
||||
Suppose an attacker attempts to produce this chain in εD work, where 0 < ε < 1. Then this
|
||||
requires, on average, that each individual block be produced in ε the expected time. Each block’s
|
||||
13
|
||||
380 production time is an independent variable, so the Chernoff bound lets us approximate this more
|
||||
precisely: if ε < 1 then the probability decays exponentially with the number of blocks in the chain.
|
||||
For the full chain this means probability O(exp[(1 − ε)n]) (exponential in n); for the compact
|
||||
chain O(exp[(1−ε)logn]) or O(n
|
||||
1−ε
|
||||
) (sublinear in n). In fact, the extreme case is even worse: a
|
||||
compact chain may consist of only a single block which has difficulty D, in which case the probability
|
||||
is simply O(exp(1−ε)). This means an attacker willing to expend some fixed percentage of
|
||||
the total chain work has the same probability of successfully rewriting the chain regardless of the
|
||||
length of the chain.
|
||||
To be conservative, we conclude that compact chains, as described in this paper, prove no
|
||||
work.6
|
||||
.
|
||||
390 So what good are they? In Mimblewimble, we expect verifiers of a chain to demand all blocks
|
||||
from the most recent two months, say, and a compact chain from there to the start (in Section 3.3.3
|
||||
we will see how full verification can proceed using only a compact chain). The resulting composite
|
||||
will:
|
||||
• be forgeable with expected work equal to the entire chain’s work; but
|
||||
• only prove the most recent two months of work
|
||||
Unlike Bitcoin, where the expected work to forge a blockchain is the same (asymptotically) to its
|
||||
proven work, in Mimblewimble these quantities are different. The expected work affects incentives:
|
||||
rational actors will choose to extend the most-work chain rather than attempting forgeries, just as in
|
||||
Bitcoin; on the other hand, the proven work affects verifiers’ certainty about the state of the world:
|
||||
400 they know at least two months worth of work has been done to produce the chain they see, that it
|
||||
was not an accident, and that if it is a forgery it was a very expensive one that cannot be reliably
|
||||
repeated.
|
||||
3.3.3 Sinking Signatures and Compact Chains
|
||||
In this section, we describe how sinking signatures interact with compact chains, and in particular
|
||||
we find that it is possible to do a full Mimblewimble verification with only a compact chain. We
|
||||
introduce a notion of compact validity of blocks which which is weaker than validity as described
|
||||
in in Definition 14. Nonetheless, we preserve the trust model of Section 1.2.
|
||||
To do this, we modify the Merkle sum tree of previous blocks and their effective difficulty to
|
||||
sum not only difficulty, but (a) the excess of the blocks’ transactions (Definition 7), (b) the sinking
|
||||
410 signatures on this excess. The excess values are summed in the obvious way, added as points, but
|
||||
the sinking signatures are more complicated.
|
||||
Rather than directly adding the signatures, we combine sets of signatures from each child at
|
||||
every node of the Merkle tree, in the following fashion: for any blockheight x, let {xn} denote the
|
||||
decreasing sequence defined in Definition 6. Then the signature set on a node is the union of the
|
||||
signature set of its children, except that whenever two heights x < y appear in the set such that
|
||||
6This says nothing about the compact SPV proofs described in, e.g. [KLS16], which put lower bounds on the length of
|
||||
compact proofs in order to upper-bound the probability a less-than-expected-work attacker can succeed. We cannot take this
|
||||
approach because we are using these proofs in consensus code and therefore need Theorem 7.
|
||||
14
|
||||
{xn} ⊆ {yn}, then both signatures are dropped and replaced by the signature on {xn} obtained by
|
||||
adding the corresponding components of the original signature.
|
||||
Therefore for a block at height h, the root of the Merkle sum tree committing to its ancestor
|
||||
blocks will have O(logh) sinking signatures, one for every power of 2 between 0 and h.
|
||||
420 With this structure in place, we are able to define validity of a block.
|
||||
Definition 16. A block is compact valid if
|
||||
• It is valid in the sense of Definition 14.
|
||||
• Its Merkle sum tree commits to the deepest block allowable under the rules of Section 3.3.1.
|
||||
• This commitment is valid, in the sense that all the summing rules are obeyed.
|
||||
• The above commitment will be a Merkle proof consisting of a path from the commitment to
|
||||
the Merkle root of the form {ci
|
||||
, c
|
||||
0
|
||||
i
|
||||
} where c0 is a direct commitment to the block; for all i c0
|
||||
i
|
||||
is the sibling in the Merkle tree of ci; and ci+1 is a commitment to {ci
|
||||
, c
|
||||
0
|
||||
i
|
||||
}.
|
||||
We require the first c0
|
||||
i
|
||||
that is a right sibling in the tree to have a valid set of sinking signatures
|
||||
on it. (If there is no such c0
|
||||
i
|
||||
then this block is skipping back to the genesis, so we instead
|
||||
430 require that all the signatures at the root of the tree are correct.)
|
||||
Definition 17. A block is fully valid if it is compact valid and
|
||||
• It commits to its immediate predecessor in the full chain (and the excess/signature committed
|
||||
to in the tree match the previous block).
|
||||
• It has a valid commitment to the current UTXO set at the time of its creation.
|
||||
(The latter condition allows the UTXO set to be verified using only the compact chain; it also
|
||||
prevents consensus attacks whereby users are given the same chain but differing UTXO sets that
|
||||
it commits to. The former condition ensures that compact blocks’ contents don’t differ from full
|
||||
blocks’ contents, as long as full verifiers are watching.) (And if nobody is watching, it’s a moot
|
||||
point anyway.)
|
||||
440 The conditions of Definition 16 are very technical. We can summarize them simply as follows:
|
||||
whenever a block at height h skips back to h0
|
||||
, we sink the signatures of every intervening block to
|
||||
the lowest height greater than h0 possible, then aggregate all the signatures that wound up on the
|
||||
same height. This mess of Merkle sum trees is only to show how this condition can be checked by
|
||||
a verifier given only polylogarithmically much data.
|
||||
We argue that this design preserves the trust model. In particular:
|
||||
Theorem 8. No transaction can be removed without (doing as much work as) rewriting the block
|
||||
it appeared in.
|
||||
Proof. Every transaction has a sinking signature on the height h of the block it appears in. When a
|
||||
block is removed from the compact chain, the above construction may cause this signature to only
|
||||
be verified after being sunk to some lower height h
|
||||
0
|
||||
450 .
|
||||
15
|
||||
However, since h
|
||||
0
|
||||
is always guaranteed to lay between the same two blocks in the compact
|
||||
chain that h does, this signature cannot be removed except be rewriting the more recent of these
|
||||
two blocks. However, by construction, this has expected work greater than or equal to rewriting the
|
||||
block that the transaction originally appeared in.
|
||||
Theorem 9. The commitments required by Definition 16 take O(log3
|
||||
) space in the height of the full
|
||||
chain.
|
||||
Proof. The commitment contains logarithmically many nodes from the Merkle tree, each of which
|
||||
contain logarithmically many sinking signatures, each of them are logarithmic in size.
|
||||
4 Extensions and Future Research
|
||||
460 Multisignature Outputs. We observe that CT rangeproofs can be produced interactively in the
|
||||
same ways that Schnorr signatures can to produce multisignature outputs. Similarly the sinking
|
||||
signatures can be trivially produced in a multiparty way. So support for multiparty signatures, while
|
||||
not addressed in this article, is simply a matter of wallet support and requires no further changes to
|
||||
the system.
|
||||
Payment channels. Bitcoin’s script system supports off-chain payment channels, which are used
|
||||
by the Lightning network[PD16] to support unlimited transaction capacity in constant blockchain
|
||||
space. A scaling-focused blockchain design such as Mimblewimble ought to support such a scheme.
|
||||
It is an open problem to produce payment channels that are as ergonomic and flexible as those in
|
||||
Bitcoin, but to show that this ought to be possible, here is an example of a primitive Mimblewimble
|
||||
470 payment channel. Suppose that a party A wants to send a series of payments to party B of maximum
|
||||
value V.
|
||||
1. First A creates a spend of V coins to a multisignature output requiring both A’s and B’s
|
||||
signature to sign. A “timelocks” this by taking the highest 0 bit i in the current blockheight
|
||||
h, then asking B to sign a transaction with height h+2
|
||||
i
|
||||
returning the coins to A. Only after
|
||||
receiving this signature, A publishes the spend.
|
||||
The signing signature construction ensures that such a refund transaction cannot be spent in
|
||||
any block between h and h+2
|
||||
i
|
||||
. On the other hand, this means that if A wants a locktime of
|
||||
2
|
||||
i blocks he must wait for a blockheight that is a multiple of 2i+1
|
||||
to create it.
|
||||
2. Now that all V coins are in a multisignature output requiring both A’s and B’s signatures to
|
||||
spend (with the coins going back to A after 2i
|
||||
480 blocks in case of stall), A can send an amount
|
||||
v to B by signing a transaction from this output sending v to B and (V −n) to A.
|
||||
3. To increase the value v, A simply signs a new transaction with the new value v. B will not
|
||||
sign and publish until the channel is near-closing, at which point B can publish one transaction
|
||||
taking the whole value v, even if it was actually produced over the course of many
|
||||
interactions.
|
||||
16
|
||||
Sidechain support. If Mimblewimble blocks commit to a structure containing all peg-in transactions
|
||||
and all peg-out transactions (in the same way they commit to the UTXO set, except these
|
||||
structures will never shrink), then it is possible for Mimblewimble to be implemented as a pegged
|
||||
sidechain. This would provide a tremendous scaling benefit to its parent chain, since most blockchain
|
||||
490 transactions are of the simple transfer-of-value sort that Mimblewimble supports, and also reduce
|
||||
the risk to users of Mimblewimble from quantum computers, since it is easy to move coins off of a
|
||||
sidechain.
|
||||
On a technical level, both peg-ins and peg-outs may look like transaction excess values which,
|
||||
instead of signing blockheights, sign an output on the destination chain. Then verifiers add this
|
||||
excess plus as ±vH to the total utxoset value (where v is the value of the output).
|
||||
Working out the details of this, and arguing security, is left as future research, but it appears on
|
||||
a high-level that there are no open problems.
|
||||
Quantum resistance. Since Mimblewimble depends on the discrete logarithm problem for security
|
||||
against theft and inflation, it is highly susceptible to attacks by quantum computers. Find-
|
||||
500 ing quantum-secure analogues to the primitives used in this paper would allow a quantum-secure
|
||||
Mimblewimble with the same asymptotic scaling properties of the original. Some research in this
|
||||
direction includes:
|
||||
• Pedersen commitments can be replaced by a quantum analogue such as [CDG+15]. Note that
|
||||
these commitments are not homomorphic in the strong sense of allowing arbitrarily many
|
||||
commitments to be added, since after a fixed noise threshold the commitments will no longer
|
||||
open — however, this is not a problem since Mimblewimble only requires that (unmerged)
|
||||
transactions sum to (a non-hiding) commitment to zero.
|
||||
• Sinking signatures can likely be replaced by a LWE-based candidate, or a variation of the
|
||||
NIZK proof-of-openings given in the above paper. The only interesting property required of
|
||||
510 these is that signatures on same value can be added to form multisignatures, which should be
|
||||
algebraically easy to obtain.
|
||||
• The author is unaware of any quantum-secure rangeproofs.
|
||||
• The blockchain commitments, being based on hashes, are already quantum secure, and the
|
||||
compact chain arguments go through unchanged.
|
||||
5 Acknowledgements
|
||||
The author would like to thank
|
||||
• Avi Kulkarni for developing the sinking signature construction described in the paper (and
|
||||
breaking the author’s original construction).
|
||||
• Gregory Sanders for asking probing questions about Mimblewimble’s guarantees until a clear
|
||||
520 picture of its consensus structure appeared.
|
||||
17
|
||||
References
|
||||
[Bac02] A. Back, Hashcash — a denial of service counter-measure, 2002, http://hashcash.
|
||||
org/papers/hashcash.pdf.
|
||||
[BCD+14] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra,
|
||||
J. Timon, and P. Wuille, ´ Enabling blockchain innovations with pegged sidechains,
|
||||
2014, https://www.blockstream.com/sidechains.pdf.
|
||||
[CDG+15] D. Cabarcas, D. Demirel, F. Gopfert, J. Lancrenon, and T. Wunderer, ¨ An unconditionally
|
||||
hiding and long-term binding post-quantum commitment scheme, Cryptology
|
||||
ePrint Archive, Report 2015/628, 2015, http://eprint.iacr.org/2015/628.
|
||||
[Jed16] T.E. Jedusor, Mimblewimble, 2016, Defunct hidden service, http:
|
||||
//5pdcbgndmprm4wud.onion/mimblewimble.txt. Reddit discussion at
|
||||
https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_
|
||||
noninteractive_coinjoin_and_better/.
|
||||
[KLS16] A. Kiayias, N. Lamprou, and A.-P. Stouka, Proofs of proofs of work with sublinear
|
||||
complexity, Financial Cryptography and Data Security: FC 2016 International Workshops,
|
||||
BITCOIN, VOTING, and WAHC, Christ Church, Barbados, February 26, 2016,
|
||||
Revised Selected Papers (Berlin, Heidelberg) (J. Clark, S. Meiklejohn, Y.A.P. Ryan,
|
||||
D. Wallach, M. Brenner, and K. Rohloff, eds.), Springer Berlin Heidelberg, 2016,
|
||||
pp. 61–78.
|
||||
[Max13a] G. Maxwell, CoinJoin: Bitcoin privacy for the real world, 2013, BitcoinTalk post,
|
||||
https://bitcointalk.org/index.php?topic=279249.0.
|
||||
[Max13b] , Transaction cut-through, 2013, BitcoinTalk post, https://bitcointalk.
|
||||
org/index.php?topic=281848.0.
|
||||
[Max15] , Confidential transactions, 2015, Plain text, https://people.xiph.org/
|
||||
~greg/confidential_values.txt.
|
||||
[Max16] , The first successful zero-knowledge contingent payment,
|
||||
2016, Blog post, https://bitcoincore.org/en/2016/02/26/
|
||||
zero-knowledge-contingent-payments-announcement/.
|
||||
[Mou13] Y. M. Mouton, Increasing anonymity in Bitcoin ... (possible alternative to Zerocoin?),
|
||||
2013, BitcoinTalk post, https://bitcointalk.org/index.php?topic=290971.
|
||||
[Nak09] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2009, https://www.
|
||||
bitcoin.org/bitcoin.pdf.
|
||||
[Nol13] T. Nolan, Re: Alt chains and atomic transfers, https://bitcointalk.org/index.
|
||||
php?topic=193281.msg2224949#msg2224949, 2013.
|
||||
18
|
||||
[PD16] J. Poon and T. Dryja, The bitcoin lightning network, 2016, https://lightning.
|
||||
network/lightning-network-paper.pdf.
|
||||
[Ped01] T. Pedersen, Non-interactive and information-theoretic secure verifiable secret sharing,
|
||||
Lecture Notes in Computer Science 576 (2001), 129–140.
|
||||
19
|
||||
Reference in New Issue
Block a user