Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Fungibility on the blockchain

No description

Roeland Creve

on 5 April 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Fungibility on the blockchain

Ask me anything!
Contact details
Website: http://weuse.cash
e-mail: creveroeland@gmail.com
Twitter: @creveroeland
Bitcointalk: dnaleor
Reddit: dnale0r
Fungibility on the blockchain
Engineer Automation
Economist (thesis on BTC)
Libertarian activist

I own some monero
Who am I?
Roeland Creve
Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution. (wikipedia)

Crawfurd versus The Royal Bank of Scotland
Crawdfurd marks notes + records serial number
Crawdfurd publishes serial numbers in newspaper
Notes appear at RBS
Crawdfurd loses the case against RBS:
rule of "bona fide" acquisition of money
=> reliability of cash
You own the cash in your pocket
No fungibility, no money?
Can non-fungible money exist?
yes, but...
privacy issues
settlement issues
Is this how money is supposed to work?

Fungibility by law versus by protocol
Crawfurd case: law made cash fungible
Digital tokens aren't necessarily fungible by itself
Possibility to attach identities to addresses
Blockchain records transaction history
privacy needed (no identities)
plausible deniability needed (no history)

War on cash
Government wants to ban cash
increase goverment "oversight"
implement wealth taxes?
Block dissidents bank accounts?
eCash is needed to balance the scales

unlinkability is needed to protect your privacy. It's not desirable that others can see or guess your account balance.
When sending or receiving bitcoins,
you expose one of your addresses...

Which can lead to...
people guessing your account balance
people guessing your spending habits
people guessing your (source of) income

You don't want your local burglar to know this.
It can also lead to loss of fungibility
Hierarchical Deterministic (HD) wallets

New address every time you receive money
Stealth addresses (BIP63)

Money is received on different addresses
Only one private key needed
Not yet implemented
Unlinkability can be undone

Combining inputs leads to loss of privacy
Address A
Address B
Other people not using HD wallet, can lead to less privacy for you

they don't use a HD wallet =>
<= you (HD wallet)
Same codebase as BTC

Hierarchical Deterministic (HD) wallets
No plans for Stealth Addresses
Plans to have names attached to addresses in "DASH evolution" (bad for privacy!)
Same remarks in regard to privacy as in BTC because same codebase
2008: First decentralized blockchain cryptocurrency, biggest and strongest network; biggest adoption and market cap
2014: instamine; launched as XCoin; rebranded to DarkCoin and DASH; Bitcoin codebase; X11; darksend; instantX; masternodes; blockchain funding
2014: launched as bitmonero; fork of cryptonote codebase; stealth addresses; ring signatures; Community takeover; crowdfunded research and development; command line; (des)inflation
Stealth addresses
Bob has one address
No loss of privacy when he makes his address public
coins arrive on one-time addresses
Are coins linked when Bob decides to spend multiple outputs in on transaction?
To mask the amount transferred, outputs are split in amounts x*10^y
(for example 1, 20, 0.3, 0.04, 500, 6000, ...)
Another reason: to make it easier to "mix" with using ring signatures
Risk of using 2 outputs from same transaction in a new transaction?
Confidential Transactions (work in progress)
Work by Gregory Maxwell
Hide amounts in a transaction
=> usually only 2 outputs (payment and change)
=> No risk of using 2 outputs originating from same transaction

CT proves that X = Y1+Y2
Still doesn't solve the loss of privacy when spending multiple outputs
=> Ring Signatures solves this, see further
CT not "just a patch" that can be integrated with Ring Signatues
=> RingCT: Monero Research Lab: lab.getmonero.org MRL-5
2016: Will probably launch this summer; academic team working on it since 2012; zkSNARK; "fully anonymous"; hidden coin generation bug; trusted setup; 10% to investors
I'm no zerocash/zerocoin/zcash expert

ZCash will use stealth addresses for receiving anonymous payments
No viewkey (yet)

Transparent bitcoin-style addresses also used for non-anonymous payments

Multisig not (yet?) using stealth addresses

Same issues exist when combining 2 outputs in one new transparent transaction.

untraceability is needed to 'encrypt' the transaction history. It's not desirable that others can see or guess where coins came from or going to.
Blockchain analysis
every transaction recorded in the blockchain
History of "coins" visible
addresses can be linked to users or (darknet) services
Lots of companies trying to analyze the blockchain
taint analysis

Cooperation with payment processors, exchanges, centralized wallet services, ...
sharing customer data to help deanonymizing
blocking/confiscating payments by customer based on taint analysis
blocking/confiscating outgoing transactions based on taint analysis
shutting down accounts
notifying law enforcement
Cooperation with mining pools/companies
Mining censorship: blocking payments based on taint analysis
majority of hashing power needed...
Loss of fungibility
Some examples

guilt by association ?
=> plausible deniability / invisible transaction history needed
Coinbase blocking accounts of people receiving coins from satoshidice
Coinbase informing law enforcement about possible darknet market user
Bitpay sharing data and telling company to not accept a certain customer again
BTC-e not accepting coins from the "evolution exit scam"
Centralized mixer


Bitcoin mixing

Service is anonymous for obvious reasons
potential honeypot?
Service can close down and take your coins
You get coins back from unknown origine
people sign one transaction with multiple inputs and outputs
Can be sybil attacked
Requires centralized server(s) which can lead to deanonymization
can be unmasked based on the amounts (coinjoinsudoku.com)
You spread taint across participants
tinder on the blockchain
Incentive to help mixing
no need to trust centralized server(s)
private "one on one" mixing, can still be sybil attacked
You spread taint across participants
obfuscated transaction history
plausible deniability on which address is yours
no plausible deniability on whether coins are spent or unspent
Satoshi Nakamoto can't deny he used his coins using mixing
taint spreads across participants (coinjoin/joinmarket)
Mixing can be unmasked by the counterparty
centralized mixer: the service
coinjoin: the server(s)
joinmarket: the counterparty
Risk of guilt by association (especially with a centralized mixer)
Masternode mixing + "DarkSend"

Coinjoin integrated in DASH GUI
Mixing happens on "masternodes"
Low liquidity (less than joinmarket)
takes a long time to mix
DASH pays 5 "liquidity providers"
Worse system than joinmarket
liquidity providers can deanonymize
masternodes have mixing logs
lot of masternodes use cloudhosting
NSA-access + gag order = bad

=> With DASH, you heavily rely on the OpSec of others in the system
Ring signatures
Bob wants to send a transaction

He grabs some outputs (minimum of 2!) of the same denomination from the blockchain (A&C)

Bob signs the ring signatures (A, B & C)

Everybody can verify someone owned the input, but Bob has plausible deniability

Passive mixing
In this example the sender sends 1000 XMR and ownes one of the 6 inputs
The other 5 'fake' inputs are randomly chosen from the blockchain
The owners of these 5 inputs sign nothing, passive mixing
Some of these 5 inputs can ben spent or unspent, no way to know
Some of these 5 inputs can even be in cold storage
For these 5 people, fungibility increased while doing nothing
Key image prevents double spends, which leads to not 100% prunable blockchain
Fixing the unlinkability issue
When 2 (or more) transaction outputs are combined, usually these addresses are related (same owner)
With Monero, once an output is used in a transaction, you have plausible deniability on whether your coins are spent or unspent
This results in the impossibility to prove that (one time) addresses are related when they are combined in the same transaction
RingCT will improve the anonimity set
At the moment, you can only mix outputs with the same denomination
RingCT will hide the amount, so you can mix every output with every random output on the blockchain
This improves the anonimity set a lot
This will also improve fungibility, certainly for "weird" denominations
I'm no zerocash/zerocoin/zcash expert

ZCash uses brand-new cryptography called "zkSNARK" to make untraceable payments.

You need to "pour" your coins in the "liquidity pool". Once in this pool, there is no link between payments.
However, this anonymous transaction takes 3 minutes and 4 GB RM.

This "pouring" is an action the owner need to take. So if he doesn't do it, his transactions are public. It is expected that due to the RAM requirements, a lot of ZCash transactions will be transparent.

No plausible deniability on whether (mined or transparent) coins were spent/poured or not

Should unlinkability and untraceability be enforced on a cryptocurrency network at protocol level to be fungible?
People are lazy
Sybil attack
If mixing is not default, the anonimity set is greatly reduced
This results in weak points to deanonymize people
This is dangerous:
if you assume to be anonymous, but you are being targeted, the consequences can be bad
Regulation and fungibility
If only a few are mixing, and you participate,
this is suspicious behaviour (f.e. Tor is suspicious)
To be able to "fly under the radar",
everybody should be mixing all the time (if everybody used Tor...)
Due to the default transparent nature of some cryptocurrencies, regulation is made possible. Note that companies can be foreced by law to cooperate
Blacklisting: blocking/confiscation of (partially)tainted coins
Whitelisting: requiring ID to be able to use your coins at regulated payment processors or sell at regulated exchanges
Transaction filtering / Miner censorship: (50+ % needed)
blocking of suspicious (or blacklisted) transactions
enforcing a whitelist of "verified coins"
enforcing 1 input -> multiple outputs & multiple inputs -> 1 output
Is Bitcoin Fungible?
Privacy/unlinkability features are weak
Untraceability features are being improved, but not default
No plausible deniability on spent or unspent
No passive mixing
Current situation
What is -theoretically- possible?
Everything! It's just code. But... consensus
Maybe adding Confidential Transactions at protocol level using SegWit

Sidechain with default joinmarket + CT
Sidechain with RingCT and stealth addresses (Monero)
Sidechain with zkSNARK (ZCash)
These solutions will behave as mixers
Will that be sufficient? Time will tell.
Is DASH Fungible?
DASH evolution will make privacy worse
Untraceability features are worse than on Bitcoin
Current situation
What is -theoretically- possible?
Everything! It's just code.
Consensus issues are almost zero on DASH, the majority seems to follow what Evan Duffield (lead dev) decides
So in theory they could adopt Ring Signatures or zkSNARKs,
but this depends on what the devs are able to copy from other developers and researchers.

NOTE: The shady history of this coin will most likely not result in
widespread adoption
Is Monero fungible?
Current situation:

unlinkable payments using stealth addresses
Passive mixing: the longer monero exists, the bigger the anonimity set
Mixing enforced at protocol level (minimum Ring Size of 3)
Default private, optionally transparent (using the viewkey)
Somewhat less anonymous, but after a few transaction the "trail" is lost
and anonimity comparable with ZCash

What will be implemented:
RingCT will anonymize the amounts and make the anonimity set even bigger
I2P integration for IP obfuscation

Due to the default private nature, regulation of all Monero in general is nearly impossible
This could lead to banning of Monero (banning encryption is difficult however)
However, the viewkey provides possible compliance with (friendly) regulation
Is ZCash fungible?
Current situation:

ZCash is still on testnet
Fully anonymous mixer
Mixing will likely not be enforced, because that would make it unusable
The high RAM requirements will slow down adoption (exchanges, mobile wallets, ...)
Transparent transactions are expected to be a big percent of the total

What will be implemented:
Zooko mentioned a viewkey will probably be implemented
There are probably some optimizations possible regarding the RAM requirements

ZCash will be transparent by default, for now at least
This results in loss of fungibility
privacy can be achieved, but users need to be very careful

Bitcoin has fungibility issues. Will not likely be solved at protocol level

DASH is worse on fungibility and privacy than Bitcoin

Monero is default fungible, but not fully anonymous.

ZCash has fully anonymous transactions, but not by default
Monero + ZCash,
best of both worlds?
Full transcript