Protocols for Provable Solvency

IntroductionThe Problem

Building blocksPreliminaries

Protocols for Accounting DeclarationProtocols for Asset Declaration

Open problemsConclusion

Secure Protocols for Provable Solvency v0.5

Philippe Camacho ([email protected] )

Coin4ce.com

June 16th, 2014

Philippe Camacho Secure Protocols for Provable Solvency





Who am I?

PhD en Cryptology, University of Chile, Chile. Worked on cryptographic hashfunctions with special properties, in particular cryptographic accumulators.

Phd Thesis :http://users.dcc.uchile.cl/ ˜ pcamacho/papers/phdthesis.pdfList of publicationshttp://www.informatik.uni-trier.de/ ˜ ley/pers/hd/c/Camacho:PhilippeSlideshare presentations:http://www.slideshare.net/philippecamacho/presentat ions

CTO of Coin4ce.com since mid 2013.


http://users.dcc.uchile.cl/~pcamacho/papers/phdthesis.pdf

http://www.informatik.uni-trier.de/~ley/pers/hd/c/Camacho:Philippe

http://www.slideshare.net/philippecamacho/presentations

Coin4ce.com





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 fortheir support and feedback.


Coin4ce.com

Comprabitcoin.com





Motivation

Catastrophic events like the MtGox bankruptcy have raised the need for anautomated, fully transparent and externally verifiable way to check the solvencyof financial institutions.

This presentation introduces an overview of previously proposed protocols thatcan help to automate part of the process of auditing the solvency of financialinstitutions.

Our contribution: we show that it is possible in practice to maintain the businessdata (amounts owed/owned) private while still allowing to verify the solvency ofsome financial institution. For this purpose we use two main cryptographic tools:commitments and zero-knowledge proofs.

Feedback and questions welcome at [email protected] .






The Problem

A Financial Institution (FI) usually keeps its database private.

Its database might not reflect the reality of its assets anyway.

In this situation, manual auditing is the only option. However it’s slow andimplies trusting the entity performing the audit.






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 canserve 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.






Merkle TreesSecure Broadcast ChannelCommitments

Building Blocks

Merkle Trees

Secure Broadcast Channel

Commitments and Zero-Knowledge Proofs







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 Htakes 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 bythe 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 (seeFigure 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 thatdoes not belong to the sequence.







Secure Broadcast Channel

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-votingprotocols [5].







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), wherer , the randomness is used to hide the information of M. When the context is clear wewill 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 BobBob can check that indeed C = Comm(M, r).

There are two main security properties for commitmentsGiven 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′ 6= M.

Commitments are useful to implement apparently contradictory requirementswhere one needs to prove something about some value, but wants to keep thisvalue secret at the same time.

Some commitments [10] have interesting algebraic properties that we will exploitfor the protocol described in section 3 (see next slide).







Pedersen Commitments[10]

Their security relies on the discrete logarithm problem. Intuitively this means that given some group element X = gd where g issome 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 = gMhr 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 = gMhr .

Security (intuition)

The commitment CM = Comm(M, r) does not leak any information about M as it’s indistinguishable from a randommessage (due to the randomness r).

It’s hard to open CM = Comm(M, r) to (M′, r′) where M′ 6= 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 definitions 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 · g

Nhr′ = g

M+Nhr+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.


http://bit.ly/1e4gSxu‎






Proving two Commitments Encode the same Value with ZKPoK

In our construction we need to do the following: Given Comm(M, r) andComm(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 verifier that he knows (M, r) suchthat CM = Comm(M, r) = gMhr .

Using ZKPoK proving our statement can be done as follows:

Compute V = Comm(M,r)

Comm(M,r′)= gM−Mhr−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.







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 eachcommitment corresponds to a bit.Then prove each commitment encodes a bit.Multiply these commitments together and check you obtain a commitment of thenumber 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 therange (51 in our case). More sophisticated and efficient proofs have beenproposed [3].






Preliminaries

All the information produced by FI is published on a secure broadcast channelSBC. This information may be signed by FI in case the SBC is shared with otherparticipants.

We consider two types of protocolsAccounting Declaration protocols: the FI declares how much money it owes to itscustomers.Asset Declaration protocols: the FI declares how much money it owns.






Maxwell-Todd ProtocolTodd Privacy-Preserving ProtocolImproving the Privacy of Maxwell-Todd Protocol

Maxwell-Todd Protocol [11],[8]

Description1:

Periodically (once a day, week or month for example) the FI publishes a value thatrepresents 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 currentbalance for his account.Each internal node value N is computed recursively as follows N = H(X + Y ||L||R) where X isthe amount of the left child, Y the amount of the right child, L the (hash) value of the leftchild 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 thetree by asking for the corresponding cryptographic proof (siblings node from the leaf tothe 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 asit might be detected.The amount in each node must be positive. It is the responsibility of the user to checkthat as well.The total amount owed is public.The root hash value must be published in the SBC otherwise different hash values (andthus user’s account declaration) could be published to different groups of people.

1A more detailed description is available at [13].







Privacy-Protecting Proof of Reserves without the Moon-Math and withoutthe backup angst [12]

Peter Todd addresses the problem of privacy (for user and FI) with the followingidea

The FI commits2 each deposit address to a domain name and the nonce relative to theuserThis technique allows to

Keep FI’s and user’s respective balance privateAvoid the key reuse attack (assign same bitcoin addresses to different users)

Some practical challenges ariseThis solution forces a specific administration of bitcoin addresses for the FI.Also this solution depends on the specific implementation of Bitcoin (in particular theway Bitcoin addresses are computed).

2In this case hash functions are used, not commitments.







Adding privacy to Maxwell-Todd’s protocol

One of the limitations of Maxwell-Todd’s protocol is that it forces the FI to revealthe total amount it owes to its customers.

We show here how to allow this amount to be kept private while at the sametime 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 amountComm(X )Instead of computing Z = X + Y the amount of the parent node, multiply thecommitments of the left child and right child. That is computeComm(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 isthe total amount of satoshis.







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 theamounts by the commitments of the amounts. For a node N , given the commitmentsCL = Comm(X ) and CR = Comm(Y ) of the left and right child respectively, computing thecommitment of the node consists of multiplying these commitments. That isCN = CL · CR = Comm(X ) · Comm(Y ) = Comm(X + Y ).







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 assetof the FI.For example, in case of fiat money, the bank could compute another commitmentcontaining the FI’s balance in USD and sign it so that people can check the informationis legitimate. Then the FI can prove with ZKP that the two amounts included in eachcommitment are equal.In the case when the FI needs to prove the size of its assets in bitcoins we will use theprotocol described in section 2 to compute this commitment.

Compared to Todd’s solution [12] our solution allows to have two separateprotocols for Accounting and Asset declaration. This can be useful for example inthe case where assets are in fiat money. On the other side Todd’s solution offersbetter privacy than our protocol related to asset declaration (see next: section 2).






Basic Coin Ownership ProtocolTowards 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 canserve 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 bitcoinaddress proves he is able to transfer funds from this address to another.







Adding privacy

How do you prove you have a given amount of bitcoins without leaking thisamount?

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 thatno 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 thecondition.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 bedetected in case of fraud.

Choose a random leaf and ask the FI to open the commitment containing the address Aand the balance B at the leaf.Run COIN OWNERSHIP on address A.Check on the Blockchain that the amount B is correct.

3This is only an idea. As mentioned next it needs to be refined in order to work.







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 inFigure 2 but we replace the user ID by the bitcoin address BTC1,BTC2, .... Note that we musthave BTC1 < BTC2 < BTC3 in order to avoid the duplication of bitcoin addresses.







Discussion

The main problem of this solution is that the more checks we do, the more wereveal about the bitcoin addresses owned by FI and thus the total amount ofbitcoins owed. So we need somehow to choose between privacy (of the FI) andincreasing the odds to catch a malicious FI.

Some ideas for future researchUse zk-SNARKS as in Zerocash [1] to prove (without revealing it!) that a bitcoinaddress 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 thisaddress belongs to the table represented by the accumulator.






Open problems

Privacy for asset declaration without imposing any condition on bitcoin addressmanagement like in [12]. Our solution is only partial as it is based on statisticalsampling.

Key rental attack. In [12] is proposed a way to prevent reusing keys internally orbetween institutions, yet nothing prevent anyone to rent addresses to others inorder to simulate solvency.






Thank you!

Please send me feedback, questions [email protected]

Check our webpage http://provablysolvent.com forupdates on this project and being involved.


http://provablysolvent.com





[1] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza.Zerocash: Decentralized Anonymous Payments from Bitcoin.

[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. SpringerBerlin 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.In Carl Pomerance, editor, CRYPTO, volume 293 of LNCS, pages 369–378. Springer Berlin / Heidelberg, August 1987.


https://github.com/olalonde/bitcoin-asset-proof

https://iwilcox.me.uk/2014/nofrac-orig





[10] Torben Pedersen.Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing.In J. Feigenbaum, editor, CRYPTO, volume 576 of LNCS, pages 129–140. Springer Berlin / Heidelberg, 1991.

[11] Peter Todd.Peter Todd’s talk (Bitcoin Conference).http://youtu.be/4d3LA8KpdMQ?t=6m33s , 2013.

[12] Peter Todd.Privacy-Protecting Proof of Reserves without the Moon-Math and without the backup angst.http://sourceforge.net/p/bitcoin/mailman/bitcoin-de velopment/thread/20140325220507.GB4846@tilt/ ,2014.

[13] Zak Wilcox.Proving your Bitcoin reserves.https://iwilcox.me.uk/2014/proving-bitcoin-reserves , 2014.


http://youtu.be/4d3LA8KpdMQ?t=6m33s

http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/20140325220507.GB4846@tilt/

https://iwilcox.me.uk/2014/proving-bitcoin-reserves