Bitcoin Transaction Malleability & MtGox [C.Decker, R.Wattenhofer] Sagi Kedmi Advanced Bitcoin Seminar The Selim and Rachel Benin School of Computer Science & Engineering The Hebrew University of Jerusalem 

agenda • Motivation • Brief overview: Network, Crypto • Deep drill-down Bitcoin focus on transactions • Transaction Malleability attack • Measurements and graphs Lots and lots Of Demos :) 

terminology Malleability – ת

motivation 

motivation • Jan. 2007, Jed McCaleb, built mtgox.com • MtGox = Magic the Gathering Online eXchance • July 2010 – MtGox was transformed to a bitcoin exchance site. (31/10/2008 Satoshi's paper) • By 2013 MtGox was handling 70% of all Bitcoin transactions. • February 2014 – closed and filed for bankruptcy claiming attackers used malleability attacks to drain its accounts https://en.bitcoin.it/wiki/History 

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But... 

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But... *A plausible inference from to this research 

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But... • This research have shown that barely 386 bitcoins could have been stolen (prior to its bankruptcy) using malleability attacks from MtGox 

Network 

p2p_network • 2 p2p networks: mainnet(tcp/8333), testnet(tcp/18333) 2 different blockchains • UPnP is used to dynamically open ports • Peer discovery – DNS seeds (Demo) • Process is susceptible to MitM attacks therefore client shouldn't rely on DNS seeds exclusively • The nodes on the network exchange transactions, blocks, and addresses of other peers with each other 

Crypto. 

cryptographic_hash_functions • Deterministic, efficiently computable & fixed output length • Collision resistance; hard to find m1!=m2 such that h(m1)=h(m2) • Appear random & hide info. (1st / 2nd pre-image resistance) • Hence, if two strings have the same digest, one can be very confident that they are identical • Usage: storing password in DB, Linux PRNG, Bitcoin, etc. 

public_key_cryptography • Requires two separate keys: private key and public key. • Everything encrypted with the public key can only be decrypted using the private key. • Everything 'encrypted' with the private key can only be decrypted using the public key. • RSA → N=p*q, ECC/ECDSA → n*P=Q • Bitcoin uses the secp256k1 curve: • In ECC keys are much smaller: 224 → 2048 (https://www.nsa.gov/business/programs/elliptic_curve.shtml) y2=x3+7 

digital_signature 

digital_signature 1. Authentication 2. Non-repudiation 3. Data Integrity 

Bitcoin 

Bitcoin meet Dorian Satoshi Nakamoto "Newsweek terrorized Mr. Nakamoto," Kirschner told Ars. "Goodman showed up at his house, scared his elderly mother, obtained his e-mail address by deception, and misquoted or invented quotes from both him and his brothers. They published his health, financial, and employment history recklessly. They need to account for what they did." Bitcoin community raised about $23,000 to help Dorian 

bitcoin_keys Android SecureRandom Vulnerability - https:/bitcoin.org/en/alert/2013-08-11-android They moved to /dev/urandom (paper: Attacking the Linux PRNG on Android) https://en.bitcoin.it/wiki/WIF 

bitcoin_address • Base64={a-z,A-Z,0-9,+,/} • Base58=Base64\{0,O,I, l,+,/} • Base64 demo 

bitcoin_address • Important: The public key is not revealed until a transaction is signed, unlike most systems where the public key is made public. 

bitcoin_address • Important: The public key is not revealed until a transaction is signed, unlike most systems where the public key is made public. • provides security against unanticipated problems which might allow reconstruction of private keys from public key data at some later point. • Example: Paper - Mining your Ps and Qs – Heninger et al. https://factorable.net/weakkeys12.extended.pdf • * d ≡ e−1 (mod φ(n)), φ(n) = φ(p)φ(q) = (p − 1)(q − 1) 

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") 

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time 

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh? 

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh? NOT!! (Another demo) 

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh? NOT!! (Another demo) • The first rule of Security is: You do not trust user input. • The second rule of Security is: You DO NOT trust user input. *Rainbow-table *Space-time t.o *Bots *A5.1-kraken 

P2PKH_transaction • 1 BTC = 108 Satoshis → 1 Satoshi = 10-8BTC • Moves bitcoins between one or more inputs and outputs (each tx has at least one i/o) • Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it • Each input used must be entirely spent in a transaction. 

P2PKH_transaction • Say Alice wants to send Bob BTC. Alice knows Bob's bitcoin address • She creates a standard P2PKH transaction output containing instructions which allow anyone to spend that output if they can prove they control the private key corresponding to Bob’s hashed public key. These instructions are called scriptPubKey. • Alice broadcasts the transaction and it is added to the block chain. The network categorizes it as an Unspent Transaction Output (UTXO), and Bob's wallet software displays it as a spendable balance. 

P2PKH_transaction • Bob decides to spend the UTXO • Creates an input which references the transaction Alice created by its hash – txid, and the specific output she used by its index number (output index). • He must then create a signature script— called scriptSig – which contains his own public key and a signature of the transaction with its private key. • Bob's input scriptSig must satisfy the conditions of Alice's scriptPubKey . 

P2PKH_transaction Demo [Transaction on testnet3] 

blockchain_treasures Demo 

blockchain_treasures Nelson Mandela (1918-2013) "I am fundamentally an optimist. Whether that comes from nature or nurture, I cannot say. Part of being optimistic is keeping one’s head pointed toward the sun, one’s feet moving forward. There were many dark moments when my faith in humanity was sorely tested, but I would not and could not give myself up to despair. That way lays defeat and death." "I learned that courage was not the absence of fear, but the triumph over it. The brave man is not he who does not feel afraid, but he who conquers that fear." "Difficulties break some men but make others. No axe is sharp enough to cut the soul of a sinner who keeps on trying, one armed with the hope that he will rise even in the end." "It always seems impossible until it’s done." "When a man has done what he considers to be his duty to his people and his country, he can rest in peace." "Real leaders must be ready to sacrifice all for the freedom of their "Everyone can rise above their circumstances and achieve success if they are dedicated to and passionate about what they do." "Education is the most powerful weapon which you can use to change the world." "For to be free is not merely to cast off one’s chains, but to live in a way that respects and enhances the freedom of others." "There is no passion to be found playing small – in settling for a life that is less than the one you are capable of living." “There is nothing like returning to a place that remains unchanged to find the ways in which you yourself have altered.” -Nelson Mandela 

blockchain_treasures • XSS Payload! (Demo) [*SQLinjection] https://blockchain.info/tx/59bd7b2cff5d a929581fc9fef31a2fba14508f1477e366befb1 eb42a8810a000 • Prayers from miners • Tribute to cryptographer Len Sassaman • by Dan Kaminsky and Travis Goodspeed(Demo) • Prayers from miners (Demo) • The original bitcoin paper, Wikileaks data Firmware private keys Oh shit," he mumbled. "I just broke the Internet." 

blockchain_treasures LETS MAKE OUR OWN BLOCKCHAIN GRAFITIY (DEMO) 

P2PKH_transaction_verification 

P2PKH_transaction_verification 

P2PKH_transaction_verification 

P2PKH_transaction_id 

P2PKH_transaction_signing SIGHASH_ALL - "sign all of the outputs." - Default behaviour 

P2PKH_transaction_signing "sign none of the outputs-- I don't care where the bitcoins go." 

P2PKH_transaction_signing "sign one of the outputs-- I don't care where the other outputs go" 

P2PKH_transaction_signing "Let other people add inputs to this transaction.” 

P2PKH_transaction_signing Ouroboros Nietzsche's Eternal Recurrence A signature may not sign a data structure containing itself → circular dependency 

P2PKH_transaction_signing Ouroboros Nietzsche's Eternal Recurrence A signature may not sign a data structure containing itself → circular dependency SOURCE OF TX MALLEABILITY 

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? transaction_malleability_OP_PUSHDATA2 

transaction_malleability_OP_PUSHDATA2 4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] 

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? transaction_malleability_OP_PUSHDATA2 

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? Different txid ! transaction_malleability_OP_PUSHDATA2 

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig: What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? Different txid ! [bcz we change data in the transaction] transaction_malleability_OP_PUSHDATA2 

classical_double_spending_attack Payer Payee#2 Payee#1 • Attacker creates two transactions • A tx that transfers some of its funds to Payee#1 {say Amazon} • A tx that transfers the same funds back to himself • Goal: convince Payee#1 that it received the funds, triggering a transfer of goods from Payee#1 to the Attacker. • Bitcoin 'solves' it with its confirmation system [6 confirmations = pretty good security] https://en.bitcoin.it/wiki/Weaknesses - haven't read; no time Sends a laptop 

transaction_malleability_attack Payer Payee#1 • Attacker(Payee) causes victim(Payer) to send to send him funds • Attacker waits for tx1 to be broadcast in the network • Attacker received tx1, broadcasts tx2=f(tx1) – tx1 with modified scriptSig • Either tx1 or tx2 may be confirmed, if tx2 is confirmed mal. Atk. is successful • If the Payer's client rely solely on the txid to track and verify its balance, it will see tx1 as unconf., and send tx3 tx2=f(tx1) tx1 tx3 Payer thinks that the funds Didnt reach payee bcz the tx1_id was unconfirmed (he thinks it was unconfirmed) 

transaction_malleability_attack Payer Payee#1 • Note: the reference client (BitcoinCore) is not susceptible to this attack – it tracks the UTXO and verifies it tx2=f(tx1) tx1 tx3 Payer thinks that the funds Didnt reach payee bcz the tx1_id was unconfirmed 

mtgox_incident_timeline Period3 Period1 Period2 January 2013 1st Press Release Suspension of Bitcoin Withdrawals February 7 2014 February 8 2014 February 9 2014 February 28 2014 February 10 2013 2nd Press Release Blamed tx malleability For unconf. tx ??th Press Release Filing for bankruptcy in Japan and USA February 23 2014 Collection of Transaction Begins Collection of Transaction Stops Mtgox.com returned blank page; trading halt Period1: Over a year of measurements until the closure of withdrawals from MtGox Period2: Withdrawals are stopped but no details about the attack known to public Period3: time following the press release blaming tx malleability as the root cause of missing bitcoins until MtGox filed for bankruptcy 

have_a_snack_buy_with_bitcoins_bamert_et_al 

have_a_snack_buy_with_bitcoin_bamert_et_al 

measurements_gear • Def: if an output is claimed by two or more transactions, these transactions are said to conflict • As soon of one of the two conflicting transactions(d.spend, m.atk) is considered to be confirmed the nodes will drop all other conflicting transactions. • They created specialized nodes that would trace and dump all transactions from the Bitcoin network (mainnet) • Each node was connected to 992 on average (recall Balmert et al.) [w.p. ~1 the node see every tx on the net] 

measurements_data • Getting malleable'd txs: remove the scriptSig/scriptSigLength from all the txs, [?and hash it?] will result in a unique key • The unique key group txs together into conflict sets • During the measurement period a total of 35,002 conflict sets were identified. • Out of these conflict setts 29,139 contained a transaction that would later be confirmed by a block. Remaining 6,603 were invalid bcz they claimed non-existent output, had an incorrect signature ... 

measurements_data • Def: conflict set value = sum of out values of one of the tx in the conflict set (each tx in the conflict is identical minus the scriptSig ). • Summing the value of all the conflict sets result in a total of 302,700 BTC that were involved in malleability attacks • There exists other tx mal. Atks other than OP_PUSHDATA2 [in the signature of the e.g. Inherent ECDSA signature malleability – more at BIP-0062] • 28,595 out of the 29,139 confirmed attacks had the OP_PUSHDATA2 modification • For the remaining 544 they were unable to identify the original transaction. All of them had original opcodes. ???? ... 

measurements_data • Def: conflict set value = sum of out values of one of the tx in the conflict set (each tx in the conflict is identical minus the scriptSig ). • Summing the value of all the conflict sets result in a total of 302,700 BTC that were involved in malleability attacks • There exists other tx mal. Atks other than OP_PUSHDATA2 [in the signature of the e.g. Inherent ECDSA signature malleability – more at BIP-0062] • 28,595 out of the 29,139 confirmed attacks had the OP_PUSHDATA2 modification • For the remaining 544 they were unable to identify the original transaction. All of them had original opcodes. ???? ... “DEMO” 

measurements_data • For tx mal. Atk. We need two things: ● 1. the modified tx has to be confirmed ● 2. the system issuing the tx must rely solely on the txid to track its confirmation ● • 1. can be easily reconstructed from the blockchain • 2. “can't”. “It is not possible to determine if two payments with the same value to the same address were intended as two separate payments or an automated system issued the second one believing the first to be invalid.” ?? • Out of the 28,595 tx mal. Atk.s only 5,670 were sucessful. i.e. 19.46%. ... 

measurements_data • Out of the 28,595 tx mal. Atk.s only 5,670 were sucessful. i.e. 19.46%. • [ Val{28,595}/Val{5,760} ]*100 = 21.36% • This reducess the total profit of the successful attacks from 302,700 to 64,564 • Strong bias towards the original tx. Why ? ... 

the_mtgox_incident ● The loss was later detailed as amounting to over 850,000 BTC out of which 750,000 BTC are customer-owned. ● At the time of the first press release bitcoins were trading at $827 i.e. ~ $700,000,000 were lost. ● But... As we've seen the total conflict set value of our dataset is 302,700 BTC. {lie?} ● More than that 

mtgox_incident_timeline Period3 Period1 Period2 January 2013 1st Press Release Suspension of Bitcoin Withdrawals February 7 2014 February 8 2014 February 9 2014 February 28 2014 February 10 2013 2nd Press Release Blamed tx malleability For unconf. tx ??th Press Release Filing for bankruptcy in Japan and USA February 23 2014 Collection of Transaction Begins Collection of Transaction Stops Mtgox.com returned blank page; trading halt Period1: Over a year of measurements until the closure of withdrawals from MtGox Period2: Withdrawals are stopped but no details about the attack known to public Period3: time following the press release blaming tx malleability as the root cause of missing bitcoins until MtGox filed for bankruptcy Malleability attacks in period 2 and 3 could not Contribute to the losses declared by MtGox since They happened after withdrawals have been stopped 

the_mtgox_incident ● During period 1 – a total of 421 conflict sets were identified for a total value of 1,811.53 BTC ● In combination with the ~20% success rate we conclude that malleability attacks did not have any substantial influence in the loss of bitcoins incurred by MtGox. (around 380 BTC could have been stolen from MtGox or from other businesses) 

the_mtgox_incident ● During period 2, they gathered 1,062 conflict sets, totalling 5,470 BTC ● A noticeable increase of attacks at 17:00 UTC on February 9, from 0.15 attacks per hour to 132 attacks per hour ● The sudden increase suggests that immediately following the second press release other attackers started imitating the attack. ● During period 3 – After the second press release between Feb. 10 and 11 they identified 25,752 individual attacks totalling 286,076 BTC. 

the_mtgox_incident 

what_really_happend ? ● Aside from MtGox, No one really knows. [Maybe the courts handling the bankruptcy ?] ● A speculation: it was an inside job/hackers at MtGox {using bots named by the community Willy and Markus}. ● More information: http://willyreport.wordpress.com/ 

what_really_happend ? ● Aside from MtGox, No one really knows..[Maybe the courts handling the bankruptcy ?] ● A speculation: it was an inside job/hackers at MtGox {using bots named by the community Willy and Markus}. ● More information: http://willyreport.wordpress.com/ PLEASE FIND A WAY TO HARNESS BITCOIN “PROOF-OF-WORK” TO SOLVE SOME OF HUMANITIES PROBLEMS. E.G: EBOLA. 

? Thank you Thanks Nadja Kahan for the illustrations ! http://www.nadjakahan.com If you're interested in the “Attacking the Linux PRNG on Android” talk We're presenting it again at DC9723 on 18/11 At Checkpoint offices 

? Thank you Thanks Nadja Kahan for the illustrations ! http://www.nadjakahan.com PROOF OF WORK