anonymity for crypto currencies - sjtu
TRANSCRIPT
Making Digital money
• Digital checks • Debit cards,
• wire transfers, etc.
• Is not anonymous
• Digital cash / coins• Value not dependent on external state.
• Anonymous
• Very challenging to build:
• Copying digital things is easy but must be prevented
Bitcoin as Digital checks• Backed by ledger that stores account balances
• Public keys are pseudonyms
• All payments are public because there is no “bank”
• You can have as many pseudonyms as you want
who learns you bought those two books
1. Everyone
2. Merchant + payment processor
3. Merchant
4. No one ( aka “anonymous”)
Pseudonyms' can be linked together
An Analysis of Anonymity
in the Bitcoin System
F. Reid and M. Harrigan
PASSAT 2011
A Fistful of Bitcoins:
Characterizing
Payments Among Men
with No Names
S. Meiklejohn et al.
IMC 2013
Network-layer de-anonymization
“The first node to
inform you of a
transaction is probably
the source of it”
Dan Kaminsky
Black Hat 2011 talk
Criminals already have anonymity
• You can hide what you are doing with cash
• Arguably Bitcoin is anonymous enough for criminal activity (if you are careful) but not private enough for everyone else who won’t be
• Hard part of money laundering isn’t anonymizing your money, its making it have legitimate sources on the other side
Why we need privacy and anonymity• Even if the government should know what you are
spending, everyone else shouldn’t
• Companies need confidentiality to conduct business (e.g. pay salaries)
• Fungibility is a necessary property of money in an economy
Fungibility
• If you loan your friend $20, do you care which $20 you get back?
• With bitcoin are you so sure?• Coins might be tied to you
• Coins might be tainted
• You might not know until you bring the coins to an exchange
Caution: Mixing services may themselves be
operating with anonymity. As such, if the mixing
output fails to be delivered or access to funds is
denied there is no recourse. Use at your own
discretion.
— Bitcoin Wiki
Why decentralized mixing?
• Theft is impossible
• Possibly better anonymity
• More philosophically aligned with Bitcoin
Coinjoin
Each signature is
entirely separate
This is 1 mixing round
Mixing principles from
before apply on top of
basic protocol
Single
transaction
Proposed by Greg Maxwell, Bitcoin core developer
Advantages: trustless
• No theft risk : Each party only signs the transaction and puts their funds in if the transaction also pays them
• No tracking: if peers anonymously exchange addresses, no one knows where the coins go.
Coinjoin algorithm
1. Find peers who want to mix
2. Exchange input/output addresses
3. Construct transaction
4. Send it around, collect signatures
(Before signing, each peer checks
if her output is present)
5. Broadcast the transaction
Coinjoin: remaining problems
• How to find peers
• Peers know your input-
output mapping
(This is a worse problem
than for centralized mixes)
• Denial of service
Peer anonymity
Strawman solution:
1. exchange inputs
2. disconnect and reconnect over Tor
3. exchange outputs
Better solution:
special-purpose anonymous routing mechanism
Problem: Denial of service
Proposed solutions:
• Proof of work
• Proof of burn
• Server kicks out malicious participant
• Cryptographic “blame” protocol
(CoinShuffle: Practical Decentralized Coin
Mixing for Bitcoin
T. Ruffing et al., PETS 2014)
Commitments
• Cryptographically opaque envelope
• Content cannot be read by anyone else
• Cannot be changed by anyone
Pedersen Commitments
• Information theoretically blinding
• hiding under discrete log assumption
• Homomorphic:
Zero—knowledge proofs
• Zero-knowledge [Goldwasser, Micali 1980s, and beyond]
• Prove knowledge of a witness satisfying a statement.
• E.g. I know X such that sha256(x) = y withoutrevealing X
• Specific variant: non-interactive proof of knowledge
• Formal notion:• Prove knowledge of a witness satisfying some relation in
NP
• Lets you make statements about the content of commitments
π
Transaction in abstract
Transaction
input1
input2
output1
output2
Input1 + input2- output1 - output2 =0
CT: Challenges
• Must prove the resulting commitment is to 0.
• Cannot reveal randomness
• Solution is to prove knowledge of r such that
• Done by treating it as a public key and signing with private key r
CT challenges
• Commitments hold approx. 256 bit numbers.
• Addition is done mod a 256 bit prime p.
• Have to avoid overflow/underflow from addition.
• Must prove each committed value is small enough
• This is done with a range proof proof based on ring signatures.
Beyond mixing
• Mixing ”my payment is one of these n”
• Problem: n is small
• What if n was all payments ever made ?• Maximal anonymity
• But everyone isn’t always online
• Need non-interactive “mixing”
• Need new solution to double spending
Anonymous digital coins
• Cannot make uncopyable digital cash/coins
• Can make single use cash• Get a unique serial number when you withdraw money
• Spend it by showing an unused serial number
• If the same serial number is spent twice, reject.
Anonymous digital cash
• Must hide unique serial number when coin is made
• Reveal it when coin is spent
• Must show coin is authentic
Naïve zero knowledge proof
• Given a list of coins C1,C2, … Cn proof• I know the commitment C to a serial number S
• The commitment is either C1, OR C2 OR …
• Proof hides which coin is being spent becuase it is zero-knowledge.
• Proof prefents coin forgery because it is sound.
∧
∨ ∨ ∨ ∨ … ∨ ∨ ∨C=
C=
Problem with OR Proof
• Size of the proof: O(n)
• Anonymity set of 1,000 would take at least 32KB
• Computational work : O(n)
• You need to know all of the coins every made to make it
Solution: make n smaller
• Instead of doing an OR proof over all of your coins, do it over e.g 10
• Used by Cryptonote protocol and implemented in ByteCoin, Monero
• Very limited anonymity set.
• Remember, you need a large anonymity set.
Better solution: don’t use ORs
• Zerocoin ( Miers, Garman, Green, Rubin IEEE S&P ‘13)
• Use a compact set membership proof to show that c ∈{ c1,c1,…cn}
• Trick is finding a set membership proof that is compact and works with efficient zero-knowledge proofs.
• Use an RSA accumulator.
Zerocoin
• Benifits• Size of the proof: O(1)• Computational work : O(m) • You need to know all m coins made after yours was to
spend• Anonymity set is entire set of coins
• Limitations• Constants matter: 25Kb for a proof
• Coins are fixed value.• Doesn’t readily provide for direct payments• Can’t do non interactive payments
A new hope: zk-SNARKs
• Zero-knowledge-Succinct Non-Interactive Arguments of Knowledge.
• Can prove arbitrary statements
• Constant size (288 byte) proof
• Fast to verify ( < 6ms)
SNARKs: limitations
• Statement is expressed as an boolean or arithmetic circuit
• Zerocoin math is not efficiently represented in a circuit
• Require trusted setup
Working with zkSNARKs
• Hash functions work better with circuit representations than 1024+ bit groups.
• Use hash based commitments comm=SHA256( value || randomness)
• Use merkle tree’s for membership proof instead of accumulator
From Zerocoin to Zerocash
• With more power, what could we do?
• Why store just serial number in commitment?
• Commitments are general purpose.
• Store coin value
• Address of recipient.
Zerocash Challenges
• We still need the serial number
• Serial number cannot be generated by the sender: they would see when the payment is spent
• Serial number cannot be generated only by the receiver: they could change it and double spend
• Need some notion of ownership
Solution:
• Create an address with a public key and private key.• Commitment includes public key• Must prove knowledge of private key to spend
funds• Serial number is a function of sender selected
randomness AND receiver private key
ZerocashEli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew
Green, Ian Miers, Eran Tromer, Madars Virza. IEEE S&P ‘14
Zcash
• Deployed in October 2016.
• TX is ~1kb ( with memo field)• ~40 seconds to create shielded transaction
• 3 GB of ram!!
• ~200ms to verify
• Maximal anonymity set: all transactions ever
Still to do
• Perf improvements
• Support for multi-signature transactions
• Windowing/ dealing with spent serial number list
Bitcoin has one advantage and three problems• All transactions are recorded in a public ledger
• You don’t need to trust anyone • All transactions are recorded in a public ledger
• All of your spending is public ZCash• All transactions are recorded in a public ledger
• You need space to store them• All transactions are recorded in a public ledger
• You need to wait for them to be stored
Payment channels/ Lightning • Two parties escrow funds om the blockchain
• Offchain, they exchange transactions updating the split of the escrowed funds
• Disputes are resolved via the block chain
• Can be chained to route payments
Payment channels aren’t private
• A single channel leaks that two parties have a relationship and can leak the amount of money involved• E.g. Alice has a channel with her doctor that closes every
month with a 5 BTC Balance to the doctor
• Hiding the particular payments and amounts doesn’t solve anything
• For chained payments, the intermediaries learn transaction details
Improved privacy
• Two kinds of privacy
• Hide identity from intermediaries • If you pay your doctor via a channel, no one else will know
• Hide identity from participants • Amazon does not learn you bought twilight
Tumblebit
• Ethan Heilman and Leen Alshenibr and FoteiniBaldimtsi and Alessandra Scafuro and Sharon Goldberg. (NDSS ’17)
• Hides channel payments from intermediates
• Does not hide party identies from each other:• Amazon still learns you bought Twilight
• Compatible with Bitcoin
BOLT: Blind Offchain Lightweight Transactions
• Anonymous payment channels for Zcash
• BOLT:盲链下轻型交易
• Blog post describing it. Translated to Chinese:https://z.cash/zh/blog/bolt-private-payment-channels.html
BOLT Basics
• A customer and a merchant escrow funds in the blockchain.
• Both parties sign a ticket (aka IOU) agreeing on how to split the funds.
• Parties can create a new ticket with a new split without :• Identifying the previous
ticket• Revealing current value of
the ticket
Bolt main challenges
• Need to atomically invalidate old ticket and generate new one
• Invalidate old ticket first• Merchant refuses to sign new ticket
• Customer cannot use old ticket
• Customer looses money
• Sign new ticket first• Customer can hold onto old ticket
• Spend with new ticket
• Close the channel using the old ticket
• Merchant looses money