anonymity for crypto currencies - sjtu

99
Anonymity for crypto- currencies Past, present, and future Ian Miers

Upload: others

Post on 07-Feb-2022

8 views

Category:

Documents


0 download

TRANSCRIPT

Anonymity for crypto-currenciesPast, present, and future

Ian Miers

What do we mean by Anonymity?

Pseudonumity

Pseudonyonmous Anonymous

Anonymity is quantitative : anonymity sets

Long term intersection attacks

Anonymity system

attacker

Repeated action you want to hide

Defense by scale

Anonymity system

attacker

Repeated action you want to hide

Defense by scale

Is Bitcoin anonymous?What’s it’s anonymity set?

“ Bitcoin is a secure and anonymous digital

currency ”

— WikiLeaks donations page

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

An example: buying two ebooks

An example: buying two ebooks

who learns you bought those two books

1. Everyone

2. Merchant + payment processor

3. Merchant

4. No one ( aka “anonymous”)

Address1

$3.1415

$2.718

Address1

Address1

Address2

Address3

Address1

Address2

Address3

$8

$7

$6

$2

Address1

Address2

Address3

Addressc$7

$6

$2

$8

Addressc

Addressa

AddressbAddress0

20

Employees can learn salaries

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

Commercial companies doing analysis

Should we have anonymous money• Money laundering

• Extortion

• Other evils

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

MixingThe simplest way to a little anonymity for Bitcoin

(Slides borrowed from EMİN GÜ N SİRER)

Trying to break the link

Mix

Can get coins back to yourself

Requires Trust

Mix can steal funds

Mix can log transactions

Chain mixes to increase privacy

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

Decentralized MixingMaking theft and identity

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

Finding peers

Use an untrusted server

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)

Larger problem: small anonymity set

Chain mixes to increase privacy:theory

Chain mixes to increase privacy: practice

Long term intersectional attacks are very powerful

Chain mixes to increase privacy: practice

Long term intersectional attacks are very powerful

Adding anonymity to Bitcoin:

Cryptographic toolsFor building more private blockchains

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

π

Hiding coin valuesConfidential Transactions

Transaction in abstract

Transaction

input1

input2

output1

output2

Input1 + input2- output1 - output2 =0

Confidential Transactions

Transaction

Comm1

Comm2

Comm3

Comm4

Greg Maxwel 2015

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.

Confidential Transactions

Transaction

Comm1

Comm2

Comm3

Comm4

π

π

π

π

π

Anonymous altcoins

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

Centralized Anonymous e-cash

via blind signatures

Spent coins

……

Block chain

π42π

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

Anonymous payment channels

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

Open problems

• Zcash without trusted setup

• Private Payment channel networks

• Other applications of blockchians to privacy• Decentralized Anonymous Credentials ( Garman, Green,

Miers NDSS ‘14)

• Anonymous messaging