Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Bitcoin Transaction Malleability

Sagi Kedmi
November 20, 2014

Bitcoin Transaction Malleability

Low level bitcoin protocol talk. Explains the Transaction Malleability Attack on Bitcoin.

Sagi Kedmi

November 20, 2014
Tweet

More Decks by Sagi Kedmi

Other Decks in Technology

Transcript

  1. 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

    View Slide

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

    View Slide

  3. terminology
    Malleability – ת

    View Slide

  4. motivation

    View Slide

  5. 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

    View Slide

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

    View Slide

  7. 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

    View Slide

  8. 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

    View Slide

  9. Network

    View Slide

  10. 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

    View Slide

  11. Crypto.

    View Slide

  12. 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.

    View Slide

  13. 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

    View Slide

  14. digital_signature

    View Slide

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

    View Slide

  16. Bitcoin

    View Slide

  17. 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

    View Slide

  18. 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

    View Slide

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

    View Slide

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

    View Slide

  21. 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)

    View Slide

  22. 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")

    View Slide

  23. 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

    View Slide

  24. 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?

    View Slide

  25. 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)

    View Slide

  26. 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

    View Slide

  27. 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.

    View Slide

  28. 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.

    View Slide

  29. 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 .

    View Slide

  30. P2PKH_transaction
    Demo
    [Transaction on testnet3]

    View Slide

  31. blockchain_treasures
    Demo

    View Slide

  32. 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

    View Slide

  33. 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."

    View Slide

  34. blockchain_treasures
    LETS MAKE OUR OWN
    BLOCKCHAIN
    GRAFITIY
    (DEMO)

    View Slide

  35. P2PKH_transaction_verification

    View Slide

  36. P2PKH_transaction_verification

    View Slide

  37. P2PKH_transaction_verification

    View Slide

  38. P2PKH_transaction_id

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. 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

    View Slide

  46. 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]

    View Slide

  47. 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

    View Slide

  48. 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

    View Slide

  49. 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

    View Slide

  50. 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

    View Slide

  51. 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)

    View Slide

  52. 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

    View Slide

  53. 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

    View Slide

  54. have_a_snack_buy_with_bitcoins_bamert_et_al

    View Slide

  55. have_a_snack_buy_with_bitcoin_bamert_et_al

    View Slide

  56. 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]

    View Slide

  57. 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
    ...

    View Slide

  58. 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. ????
    ...

    View Slide

  59. 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”

    View Slide

  60. 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%.
    ...

    View Slide

  61. 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 ?
    ...

    View Slide

  62. 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

    View Slide

  63. 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

    View Slide

  64. 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)

    View Slide

  65. 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.

    View Slide

  66. the_mtgox_incident

    View Slide

  67. 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/

    View Slide

  68. 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.

    View Slide

  69. ?
    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

    View Slide

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

    View Slide