Bitcoin 101 and Beyond Jonathan Levin VP Business Development, Chainalysis GmbH

Bitcoin’s design primitives Every transaction is public to prevent double spending Interactions are done using throwaway pseudonyms Fees were not initially considered in November 2008 but were a later addition Directed Acyclic Graph – Append only ledger Proof of work used to help new nodes that are entering the network quickly choose the correct global state The Blockchain was designed to minimize bloat Keeps track of checksums rather than tokens

New Privacy Model Party Transactions Trusted Third Party Counterparty Public Pseudonyms Traditional Privacy Model Party Transactions Public New Privacy Model Counterparty Pseudonyms are cryptographic keys that are used to sign transactions in Bitcoin

Bitcoin Transaction JSON { "hash":"a6d9c176ecb041c b f a7a8e61b041343efc3bcb6e", "ver":1, "vin_sz":1, "vout_sz":2, "lock_time":0, "size":257, "in":[ { "prev_out":{ "hash":"b5045e7daad205d1a204b544414af74fe66b eae5423e325", "n":0 }, "scriptSig":" e3d e9b2be11728cc7e44a f75ebc71375f0a6dd080d02202ef b3ecddddb0bed77960adccac5bbe317dfb0ce149eeee76498c19b101 04a36b5d3b4caa05aec80752f2e2805e4401fbdbe21be1011dc60c358c5fc4d3bedd1e03161fb4b 3a021c3764da57fee0d73570f3570f1b3dd92a1b06aae968846" } ], "out":[ { "value":" ", "scriptPubKey":"OP_DUP OP_HASH e bc11ecf f a10 OP_EQUALVERIFY OP_CHECKSIG" }, { "value":" ", "scriptPubKey":"OP_DUP OP_HASH d739ae983d8c75a0cb82958e94b7ae81e OP_EQUALVERIFY OP_CHECKSIG" } ] } Note the amount of inputs not present!!!

Bitcoin: Plumbing Analogy Each transaction is dependent on a previous transaction output Outputs can be combined and split up with ability to have 749 inputs and outputs Wallet implementations prioritized lower fees rather than privacy Transaction graph grows in complexity but can be looked at in a time series since it is append only There is no mapping from inputs to outputs However Bitcoin is far from anonymous

Proof of work: Anonymous consensus

Proof of work: Reality Check

Engineering the base layer Decentralised Trust minimization between parties Decentralised Trust minimization between parties Centralised Cost minimization Centralised Cost minimization Anonymous Authenticated identities Untraceable Traceable Bitcoin Coinbase Blockchain.info Circle Zerocash Bitcoin Paypal Bitcoin Circle Ripple Colored coins Onename Stellar? Traditional Banking Traditional Banking 2009 Bitcoin Zerocash

Model of Innovation  Open source community with baked in incentives to form a new currency drives competition  Development on the Bitcoin protocol is slow due to the amounts of money at stake  Lock-in drivers e.g. number of users, number of developers, VC money, security of the ledger, trust in the system.  The security of the Bitcoin ledger and the creation of digital scarcity is perhaps the most important characteristic of these ledgers and might ensure its survival with additional functionality being added e.g. Side-chains 3 Components to look for: Economic model Scripting ability Security model

Litmus test for a killer app  Does the use case require trust minimization between parties?  Does it not require every participant to identify themselves when participating? Put another way do we need to give participants the ability to maintain a level of privacy?  Do we need auditability in several directions?  How time sensitive is the underlying application? Will latency matter?  Could the system achieve an efficient outcome with a rigid rule that governs provable digital scarcity?  Do you need a purely fungible commodity at core? (digital currency, storage, elec, etc)  Do you need fragmented supply?  What is our current solution to the requirements above? How much does it depend on a single player and what is the cost of the system?

Contact Twitter: