Protocols for Provable Solvency

Introduction
The Problem
Building blocks
Preliminaries
Protocols for Accounting Declaration
Protocols for Asset Declaration
Open problems
Conclusion
Secure Protocols for Provable Solvency v0.5
Philippe Camacho (philippe.camacho@gmail.com)
Coin4ce.com
June 16th, 2014
Philippe Camacho Secure Protocols for Provable Solvency

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Who am I?
PhD en Cryptology, University of Chile, Chile. Worked on cryptographic hash
functions with special properties, in particular cryptographic accumulators.
Phd Thesis :
http://users.dcc.uchile.cl/˜pcamacho/papers/phdthesis.pdf
List of publications
http://www.informatik.uni-trier.de/˜ley/pers/hd/c/Camacho:Philippe
Slideshare presentations:
http://www.slideshare.net/philippecamacho/presentations
CTO of Coin4ce.com since mid 2013.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Acknowledgements
This work has been made while being at Coin4ce.com / Comprabitcoin.com.
I owe many thanks to Darren Camas, Austin Delonge and Adam Stradling for
their support and feedback.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Motivation
Catastrophic events like the MtGox bankruptcy have raised the need for an
automated, fully transparent and externally verifiable way to check the solvency
of financial institutions.
This presentation introduces an overview of previously proposed protocols that
can help to automate part of the process of auditing the solvency of financial
institutions.
We show that it is possible in practice to maintain the business data (amounts
owed/owned) private while still allowing to verify the solvency of some financial
institution. For this purpose we use two main cryptographic tools: commitments
and zero-knowledge proofs.
Feedback and questions welcome at philippe.camacho@gmail.com.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
The Problem
A Financial Institution (FI) usually keeps its database private.
Its database might not reﬂect the reality of its assets anyway.
In this situation, manual auditing is the only option. However it’s slow and
implies trusting the entity performing the audit.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Why Bitcoin changes the Scenario
With Bitcoin it’s simple to prove you own a given amount of coins:
1 Pick the address you claim to own.
2 Get a random (not controlled by you) message: data from the blockchain can
serve this purpose.
3 Sign this message with the private key corresponding to your bitcoin address.
4 The amount of BTC for this address is available in the blockchain.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Secure Broadcast Channel
Commitments
Building Blocks
Merkle Trees
Commitments and Zero-Knowledge Proofs

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
Merkle Trees [9]
g = H(e||f )
e = H(a||b)
a b
f = H(c||d)
c d
Figure 1 : Merkle tree for sequence (a, b, c, d). The hash function induced by the tree and a collision-resistant hash function H
takes the set (a, b, c, d) as input and returns the root hash value g as output. A proof that a belongs to the sequence is composed by
the nodes containing values (b, f ) (underlined) which are the siblings of the nodes on the path from a to the root g. Checking the proof
consists of computing e′ = H(a||b), then computing g′ = H(e′||f ) and finally checking that g = g′.
A Merkle Tree [9] is a cryptographic data-structure that enables to
Hash a sequence of values.
Prove that a specific value belongs to this sequence by giving the hash of this sequence and a short cryptographic proof.
It works as follows:
Put the values of the sequence at the leaves of a balanced binary tree.
Compute each internal node value by hashing the value of the left child concatenated with the right child.
The value at the root is the hash of the sequence.
To prove that an element at a leaf belongs to the sequence:
Provide the siblings of the nodes on the path from this leaf to the root.
Using these nodes recompute the hash value at the root and check it is the same as the one provided initially (see
Figure 1).
Efficiency: The size and the time to check the cryptographic proof is logarithmic in the size of the set.
Security: If the hash function used is collision-resistant, then it is hard to compute a fake cryptographic proof for an element that
does not belong to the sequence.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
A Secure Broadcast Channel (SBC) guarantees the following:
One can post messages.
Everyone sees exactly the same messages in the same order.
No one can delete messages.
Hey! Bitcoin is a SBC :)
It’s quite an important tool, it can be used for example in electronic-voting
protocols [5].

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
Commitments
A commitment is a tool that allows to delay the disclosure of some information.
It works basically as follows:
Alice chooses some message M and computes a commitment C = Comm(M, r), where
r, the randomness is used to hide the information of M. When the context is clear we
will write C = Comm(M) instead of C = Comm(M, r).
Alice sends C to Bob.
Then Bob can tell Alice to open the commitment C.
Alice will give the message M and r to Bob
Bob can check that indeed C = Comm(M, r).
There are two main security properties for commitments
Given only C = Comm(M, r) one does not learn anything about M.
It’s impossible for Alice to open the commitment C to another message M′
= M.
Commitments are useful to implement apparently contradictory requirements
where one needs to prove something about some value, but wants to keep this
value secret at the same time.
Some commitments [10] have interesting algebraic properties that we will exploit
for the protocol described in section 3 (see next slide).

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
Pedersen Commitments[10]
Their security relies on the discrete logarithm problem. Intuitively this means that given some group element X = gd where g is
some generator, it is hard to compute d, the discrete logarithm.
Operations
Setup: consider a group G and two random elements g, h ∈ G
Comm(M, r) = CM = gM hr where M is the message and r the randomness of the commitment.
Open(CM , M, r): returns (M, r).
Verify(CM , M, r): checks that CM = gM hr .
Security (intuition)
The commitment CM = Comm(M, r) does not leak any information about M as it’s indistinguishable from a random
message (due to the randomness r).
It’s hard to open CM = Comm(M, r) to (M′, r′) where M′ = M because due to the discrete logarithm problem the
messages in exponents M, r are somehow “locked” in their respective base g, h.
For rigorous deﬁnitions and proofs see http://bit.ly/1e4gSxu
Homomorphic property
Given CM = Comm(M, r) and CN = Comm(N, r′) whe have that
CM · CN = gM hr · gN hr′
= gM+N hr+r′
= Comm(M + N, r + r′)
Basically, multiplying the commitments relative to messages M, N one obtains the commitment of message M + N.
We use this trick in order to compute the sum of owed/owned amounts without disclosing these amounts.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
Proving two Commitments Encode the same Value with ZKPoK
In our construction we need to do the following: Given Comm(M, r) and
Comm(M′, r′) prove that M = M′ without opening the commitments.
For this we need another tool, Zero-Knowledge Proofs of Knowledge (ZKPoK).
This consists of letting the prover convince a veriﬁer that he knows (M, r) such
that CM = Comm(M, r) = gM hr .
Using ZKPoK proving our statement can be done as follows:
Compute V = Comm(M,r)
Comm(M,r′)
= gM−M
hr−r′
= hr−r′
Compute a ZKPoK of the discrete logarithm of V with respect to the base h.
See [4] for references on ZKPoK and techniques to prove more involved statements.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Merkle Trees
Commitments
Proving a Commitment Encodes a Value in a Specific Range
A simple technique [7] (see also [2] Section 1.2.1) does the trick:
Decompose the committed number in a product of k commitments where each
commitment corresponds to a bit.
Then prove each commitment encodes a bit.
Multiply these commitments together and check you obtain a commitment of the
number you want to test.
It’s not optimal but when the range is short, as in our case, it is efficient enough.
The size of the proof is proportional to the number of bits required to encode the
range (51 in our case). More sophisticated and efficient proofs have been
proposed [3].

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Preliminaries
All the information produced by FI is published on a secure broadcast channel
SBC. This information may be signed by FI in case the SBC is shared with other
participants.
We consider two types of protocols
Accounting Declaration protocols: the FI declares how much money it owes to its
customers.
Asset Declaration protocols: the FI declares how much money it owns.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Maxwell-Todd Protocol
Todd Privacy-Preserving Protocol
Improving the Privacy of Maxwell-Todd Protocol
Maxwell-Todd Protocol [12],[8]
Description1:
Periodically (once a day, week or month for example) the FI publishes a value that
represents the list of accounts with their respective balances for each client.
The value is computed by using a Merkle-Tree where
Each leaf contains a pair (id, X) where id is the identifier of the customer and X the current
balance for his account.
Each internal node value N is computed recursively as follows N = H(X + Y ||L||R) where X is
the amount of the left child, Y the amount of the right child, L the (hash) value of the left
child and R the (hash) value of the right child.
The hash value for the root node is the one that is published.
It is the responsibility of the Customer to check that his account balance belongs to the
tree by asking for the corresponding cryptographic proof (siblings node from the leaf to
the root) to the FI.
Discussion:
User must check his account for each update of the root value.
However it is risky in practice for the FI to try to lie on some user’s account balance as
it might be detected.
The amount in each node must be positive. It is the responsibility of the user to check
that as well.
The total amount owed is public.
The root hash value must be published in the SBC otherwise different hash values (and
thus user’s account declaration) could be published to different groups of people.
1
A more detailed description is available at [14].

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Privacy-Protecting Proof of Reserves without the Moon-Math and without
the backup angst [13]
Peter Todd addresses the problem of privacy (for user and FI) with the following
idea
The FI commits2
each deposit address to a domain name and the nonce relative to the
user
This technique allows to
Keep FI’s and user’s respective balance private
Avoid the key reuse attack (assign same bitcoin addresses to different users)
Some practical challenges arise
This solution forces a specific administration of bitcoin addresses for the FI.
Also this solution depends on the specific implementation of Bitcoin (in particular the
way Bitcoin addresses are computed).
2
In this case hash functions are used, not commitments.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Adding privacy to Maxwell-Todd’s protocol
One of the limitations of Maxwell-Todd’s protocol is that it forces the FI to reveal
the total amount it owes to its customers.
We show (see [11] for a generalization of this technique.) here how to allow this
amount to be kept private while at the same time enabling the users to check
that their account is present in the Merkle-Tree.
Idea:
Replace the amount X stored in each node by the commitment of this amount
Comm(X)
Instead of computing Z = X + Y the amount of the parent node, multiply the
commitments of the left child and right child. That is compute
Comm(Z) = Comm(X) · Comm(Y ).
The homomorphic property ensures that indeed Z = X + Y .
Check using ZKP that each amount is in the range [0, Z] where Z = 21 · 106
· 108
is
the total amount of satoshis.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Example
A = H(B||C||Comm(65));
Comm(65)
B = H(D||E||Comm(30));
Comm(30)
D = ID1||Comm(10) E = ID2||Comm(20)
C = H(F||G||Comm(35));
Comm(35)
F = ID3||Comm(15) G = ID4||Comm(20)
Figure 2 : Providing privacy to Maxwell-Todd’s tree using commitments: Here we replace the
amounts by the commitments of the amounts. For a node N, given the commitments
CL = Comm(X) and CR = Comm(Y ) of the left and right child respectively, computing the
commitment of the node consists of multiplying these commitments. That is
CN = CL · CR = Comm(X) · Comm(Y ) = Comm(X + Y ).

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Discussion
The commitments do not leak any information about the amounts.
Yet all the necessary relationships can be checked.
Now what do we do with this commitment?
We can compare it to another commitment that will contain for example the total asset
of the FI.
For example, in case of fiat money, the bank could compute another commitment
containing the FI’s balance in USD and sign it so that people can check the information
is legitimate. Then the FI can prove with ZKP that the two amounts included in each
commitment are equal.
In the case when the FI needs to prove the size of its assets in bitcoins we will use the
protocol described in section 2 to compute this commitment.
Compared to Todd’s solution [13] our solution allows to have two separate
protocols for Accounting and Asset declaration. This can be useful for example in
the case where assets are in fiat money. On the other side Todd’s solution offers
better privacy than our protocol related to asset declaration (see next: section 2).

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Basic Coin Ownership Protocol
Towards more privacy: random sampling
Coin Ownership Protocol
Already mentioned in the introduction. An implementation can be found at [6].
COIN OWNERSHIP
1 Pick the address you claim to own
2 Get a random (not controlled by you) message: data from the blockchain can
serve this purpose
3 Sign this message with the private key corresponding to your bitcoin address
4 The amount of BTC for this address is available in the Blockchain
By being able to compute a signature on a random message the owner of the bitcoin
address proves he is able to transfer funds from this address to another.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Adding privacy
How do you prove you have a given amount of bitcoins without leaking this
amount?
Initial Idea3
Use a private Maxwell-Todd tree where the leaves are composed by
The bitcoin addresses the FI claims to own.
The amount available at these addresses.
The Merkle-tree must be such that the addresses are ordered in ascending order so that
no address is duplicated (that would inflate artificially the total value of the assets).
Users must check that the neighbour leaf (can be on the left or on the right) satisfies the
condition.
This might create the need to compute two branches of the Merkle tree.
Again the FI could lie (by duplicating some bitcoin addresses) but it exposes itself to be
detected in case of fraud.
Choose a random leaf and ask the FI to open the commitment containing the address A
and the balance B at the leaf.
Run COIN OWNERSHIP on address A.
Check on the Blockchain that the amount B is correct.
3
This is only an idea. As mentioned next it needs to be refined in order to work.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Example
A = H(B||C||Comm(65));
Comm(65)
B = H(D||E||Comm(30));
Comm(30)
D = BTC1||Comm(10) E = BTC2||Comm(20)
C = H(F||G||Comm(35));
Comm(35)
F = BTC3||Comm(15) G = BTC4||Comm(20)
Figure 3 : Proving the size of assets with random sampling. This is the same construction as in
Figure 2 but we replace the user ID by the bitcoin address BTC1, BTC2, .... Note that we must
have BTC1 < BTC2 < BTC3 in order to avoid the duplication of bitcoin addresses.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Discussion
The main problem of this solution is that the more checks we do, the more we
reveal about the bitcoin addresses owned by FI and thus the total amount of
bitcoins owed. So we need somehow to choose between privacy (of the FI) and
increasing the odds to catch a malicious FI.
Some ideas for future research
Use zk-SNARKS as in Zerocash [1] to prove (without revealing it!) that a bitcoin
address is controlled by the FI.
The we also need to prove that this address has the right amount of BTC binded to it.
This could be done using accumulators that would store the list of pairs
(address,balance) of the blockchain and then checking in zero-knowledge that this
address belongs to the table represented by the accumulator.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Open problems
Privacy for asset declaration without imposing any condition on bitcoin address
management like in [13]. Our solution is only partial as it is based on statistical
sampling.
Key rental attack. In [13] is proposed a way to prevent reusing keys internally or
between institutions, yet nothing prevent anyone to rent addresses to others in
order to simulate solvency.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
Thank you!
Please send me feedback, questions at
philippe.camacho@gmail.com

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
[1] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza.
Zerocash: Decentralized Anonymous Payments from Bitcoin.
2014.
[2] Fabrice Boudot.
Efficient Proofs that a Committed Number Lies in an Interval.
In Bart Preneel, editor, EUROCRYPT, volume 1807 of Lecture Notes in Computer Science, Berlin, Heidelberg, May 2000. Springer
Berlin Heidelberg.
[3] Jan Camenisch, Rafik Chaabouni, and Abhi Shelat.
Efficient Protocols for Set Membership and Range Proofs.
In ASIACRYPT ’08: Proceedings of the 14th International Conference on the Theory and Application of Cryptology and Information
Security, pages 234–252, Berlin, Heidelberg, 2008. Springer-Verlag.
[4] Jan Camenisch and Markus Stadler.
Proof Systems for General Statements about Discrete Logarithms.
Technical report, 1997.
[5] Ronald Cramer, Rosario Gennaro, and Berry Schoenmakers.
A Secure and Optimally Efficient Multi-Authority Election Scheme.
In Walter Fumy, editor, EUROCRYPT, volume 1233 of LNCS, pages 103–118. Springer Berlin / Heidelberg, July 1997.
[6] Olivier Lalonde.
bitcoin-asset-proof.
https://github.com/olalonde/bitcoin-asset-proof, 2014.
[7] Wenbo Mao.
Guaranteed correct sharing of integer factorization with off-line shareholders.
In Hideki Imai and Yuliang Zheng, editors, Public Key Cryptography, volume 1431 of Lecture Notes in Computer Science,
Berlin/Heidelberg, 1998. Springer-Verlag.
[8] Greg Maxwell.
IRC transcript of gmaxwell describing his prove-how-(non)-fractional-your-Bitcoin-reserves-are scheme.
https://iwilcox.me.uk/2014/nofrac-orig, 2014.
[9] Ralph C. Merkle.
A Digital Signature Based on a Conventional Encryption Function.

Introduction
The Problem
Building blocks
Preliminaries
Open problems
Conclusion
In Carl Pomerance, editor, CRYPTO, volume 293 of LNCS, pages 369–378. Springer Berlin / Heidelberg, August 1987.
[10] Torben Pedersen.
Non-Interactive and Information-Theoretic Secure Veriﬁable Secret Sharing.
In J. Feigenbaum, editor, CRYPTO, volume 576 of LNCS, pages 129–140. Springer Berlin / Heidelberg, 1991.
[11] Brian Thompson, Stuart Haber, William G. Horne, Tomas Sander, and Danfeng Yao.
Privacy-Preserving Computation and Veriﬁcation of Aggregate Queries on Outsourced Databases.
In Ian Goldberg and Mikhail J. Atallah, editors, Privacy Enhancing Technologies, volume 5672 of Lecture Notes in Computer Science.
Springer Berlin Heidelberg, Berlin, Heidelberg, 2009.
[12] Peter Todd.
Peter Todd’s talk (Bitcoin Conference).
http://youtu.be/4d3LA8KpdMQ?t=6m33s, 2013.
[13] Peter Todd.
Privacy-Protecting Proof of Reserves without the Moon-Math and without the backup angst.
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/20140325220507.GB4846@tilt/,
2014.
[14] Zak Wilcox.
Proving your Bitcoin reserves.
https://iwilcox.me.uk/2014/proving-bitcoin-reserves, 2014.

Protocols for Provable Solvency

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Protocols for Provable Solvency

Similar to Protocols for Provable Solvency (20)

More from Philippe Camacho, Ph.D.

More from Philippe Camacho, Ph.D. (20)

Recently uploaded

Recently uploaded (20)

Protocols for Provable Solvency