Provisions Privacy-preserving proofs of solvency for Bitcoin exchanges Real World Crypto 2016 eprint.iacr.org/2015/1008.pdf github.com/bbuenz/provisions Jeremy Clark Dan Boneh Gaby Dagher Benedikt Bünz Joseph Bonneau
Many users use Bitcoin via exchanges EXCHANGE Bitcoin network Alice
Exchanges look a lot like online banks
Exchanges have a shaky track record Mt. Gox: lost roughly US$450M Subsequent price crash ~50% have failed! [Moore, Christin 2013]
Goal: prove solvency BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Charlie b C K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS Solvency ⇔ Total Liabilities ≤ Total Assets full reserve
Proofs of solvency have limitations ● Proof of solvency is a snapshot ● Proof of solvency ≠ willingness to pay
Approach #1: publish everything BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Charlie b C K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS
Approach #2: trusted auditor BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Charlie b C K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS Looks good to me!
Solution #3a: Maxwell protocol [2013] (total liabilities) h, b A + b B + b C + b D H, + h, b A + b B h, b A + b B Inclusion proof for Alice H, + H, + h, b A h, b B h, b C h, b D H H H H Alice: b A Bob: b B Carol: b C David: b D
Solution #3b: public proof of assets
Maxwell protocol considered too leaky “Maxwell’s proposal would have required bitcoin companies to reveal all of their balance-containing addresses. This method would result in the public knowledge of exchanges’ or wallet providers’ bitcoin wallets and total holdings, information that is commercially sensitive and presents potential security risks to companies and users.”
Improving on Maxwell’s privacy goals Maxwell protocol reveals: We reveal: •Total liabilities ∅ •Some info about account sizes ∅ •Total assets ∅ •Addresses in use ∅ Non-goal: completely conceal number of users
Provisions at a high level BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Anonymity Charlie b C set K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS Proof-of-liabilities Proof-of-assets commit(liabilities) commit(assets) Proof-of-solvency commit(assets - liabilities) = commit(0)
Provisions proof-of-liabilities Homomorphic ∑ i commit(b i )=commit(liabilities) Pedersen commitments · Public proof [commit(Alice),commit(b A )] [commit(Bob),commit(b B )] [commit(Carol),commit(b C )] Commit Commit Commit b B Alice b A Bob b C Carol Inclusion proof for Alice
Provisions proof-of-liabilities ∑ i commit(b i )=commit(liabilities) · Public proof Range proof: Range proof: Range proof: 0 ≤ b A ≤ 2 51 0 ≤ b B ≤ 2 51 0 ≤ b C ≤ 2 51 [commit(Alice),commit(b A )] [commit(Bob),commit(b B )] [commit(Carol),commit(b C )] Commit Commit Commit 2 256 - x b B Alice b A Nobody Bob b C Carol What if a fake user causes an overflow? ⟹ range proof needed for each committed balance
Size of proof-of-liabilities ● Proof size is Θ( m∙n ) for n users, m bits precision ● ∼ 9kB/user at 51 bits (31 bits should be enough) ● easily parallelizable ● incrementally updatable
Provisions at a high level BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Anonymity Charlie b C set K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS Proof-of-liabilities Proof-of-assets commit(liabilities) commit(assets) Proof-of-solvency commit(assets - liabilities) = commit(0)
Provisions proof-of-assets BITCOIN ADDRESSES K 1 b 1 K 2 b 2 Anonymity + = commit(assets) set K 3 b 3 Bitcoin network ... ( Z assets ) TOTAL b 1 + b 2 + b 3 +... ASSETS NIZKPK: -exchange knows private keys for a subset of Bitcoin addresses - total value at these addresses is committed to by Z assets
Provisions proof-of-assets private key address public balance k 1 K 1 b 1 ? K 2 b 2 k 3 K 3 b 3 Anonymity addresses ? K 4 b 4 ? K 5 b 5 k 6 K 6 b 6
Provisions proof-of-assets private key address public balance committed balance k 1 K 1 b 1 commit(b 1 ) ? K 2 commit(0) b 2 commitments to 0 k 3 K 3 b 3 commit(b 3 ) ? K 4 b 4 commit(0) ? K 5 b 5 commit(0) k 6 K 6 b 6 commit(b 6 )
Provisions proof-of-assets Public proof private key address public balance committed balance per-address proof k 1 K 1 b 1 p 1 =commit(b 1 ) ... ? K 2 p 2 =commit(0) ... b 2 k 3 K 3 b 3 p 3 =commit(b 3 ) ... ? K 4 b 4 p 4 =commit(0) ... “Either I know k i and p i is a commitment to b i ? K 5 b 5 p 5 =commit(0) ... OR p i is a commitment to 0” k 6 K 6 b 6 p 6 =commit(b 6 ) ... = commit(assets) ∑ i p i
Size of proof-of-assets ● Proof size is Θ( N ) for N addresses in anonymity set ● ∼ 350 bytes/address ○ 1 public key ○ 2 elements of G , ○ 8 elements of Z q ● easily parallelizable
Completing the proof of solvency BITCOIN ADDRESSES USERS Alice b A K 1 b 1 Bob b B K 2 b 2 Anonymity Charlie b C set K 3 b 3 Bitcoin network ... ... TOTAL b A + b b + b c +... TOTAL b 1 + b 2 + b 3 +... LIABILITIES ASSETS Proof-of-liabilities Proof-of-assets commit(liabilities) commit(assets) Proof-of-solvency commit(balance) = commit(assets)-commit(liabilities)
Finishing the proof of solvency in style Given: commit(balance) = commit(assets) - commit(liabilities) ● open commit(balance) ⟹ reveals surplus ● range proof that commit ⟹ proof that surplus exists (balance) is small
Extension: Valet keys Keys are stored offline Extension: ● replace g x for every key with g xr ● Prove knowledge of each g xr to the base g x ● xr is the valet key, safe to export
Provisions is practical ● 150 MB asset proof with maximal anonymity set ● 17 GB proof of liabilities for 2 Million users (Coinbase) ● Computes in ~ 1 hour on 1 machine ● Auditors check entire proof (~ 1 hour) ● Users verify inclusion (~ free)
Limitation: non-public public keys ● Provisions requires public keys for entire anonymity set ● Most bitcoin addresses are H(PubKey) ○ Public key revealed after first spend ○ Majority are one-time use... ● About 430k/1.3M addresses can be used in Provisions ⟹ SNARKs could be used to build a more powerful solvency proof.
Thanks! buenz@cs.stanford.edu Paper: eprint.iacr.org/2015/1008.pdf Reference implementation: github.com/bbuenz/provisions
Recommend
More recommend