A Deep Dive into the Recent BCH Hard Fork Incident

I. Double Spends on BCH

Twice a year, the Bitcoin Cash (BCH) network hard forks as part of scheduled protocol upgrades. The most recent upgrade occurred on Wednesday, May 15 at 5:00am PT (12pm GMT) and included the following two main changes:

• Enable Schnorr signatures. Schnorr signatures are a cryptographic signature system that enables scaling solutions that are part of the BCH roadmap.

• Allow Segwit recovery. Segwit is an address format that is valid on the BTC network and invalid on the BCH network. BCH coins are occasionally sent to segwit addresses, which, prior to this upgrade, resulted in these coins being unspendable. This upgrade changed the status of these coins from being unspendable to, in certain cases, being claimable by BCH miners. Part II provides more information on this.

Timeline of Events

The BCH upgrade occurred at 5:00am PT, which caused miners to produce blocks under the new consensus rules beginning with block 582680 as the first block under the post-upgrade ruleset. Between 5:20am and 9:05am PT, a vulnerability in the main BCH implementation, Bitcoin ABC, was exploited that caused miners to produce empty blocks, resulting in a backlog of transactions in the BCH mempool. During this time, the non-upgraded BCH chain was extended with a new block 582680.

Shortly after a patch for the ABC vulnerability was implemented, two blocks 582698 and 582699 were mined by two separate miners identified by “unknown” and “Prohashing” strings in the respective blocks’ coinbase transactions. The “unknown” miner mined Block 582698 which included transactions that spent BCH from more than 1000 segwit addresses.

At 9:10 am PT, Coinbase observed a 2-block chain reorganization, where blocks at height 582698 and 582699 were orphaned by a longer chain with blocks at heights 582698 through 582701, mined by BTC.top and BTC.com. Block 582701 contained a single double spend transaction of a transaction contained in orphaned block 582699. The double spending transaction appears to be a replay from the BSV network, did not spend from a segwit address, and does not appear to be related to the other double spends observed.

At 10:05 am PT, block 582705 was mined by BTC.top. This block contained 1278 transactions (1451 inputs, 1278 outputs, 3655 BCH) that double spent most of the inputs to 28 segwit-spending transactions (1387 inputs, 28 outputs, 3792 BCH) contained in orphaned block 582698. However, 56 of the orphaned transactions’ inputs were not included in the double spending transactions, and 120 of the inputs in the double spending transactions were not in the orphaned transactions’ inputs. As we will show further down, all of these double spends were sent to their equivalent valid BCH addresses.

At 12:53pm PT, block 582715 was mined by another unknown miner. This block contained 13 transactions (620 inputs, 13 outputs, 216 BCH) that double spent inputs to 25 of the previous 28 segwit-spending transactions (1237 inputs, 25 outputs, 3442 BCH) contained in orphaned block 582698. 1181 of the orphaned transactions’ inputs were not included in the double spending transactions, as many of them had been spent in block 582705, and 564 of the inputs in the double spending transactions were not in the original orphaned transactions’ inputs. This is an example of a transaction whose 6th input was double spent by the 30th input of a transaction included in block 582715. These double spends were sent to 13 BCH addresses, which are provided in Appendix A. Based on blockchain analysis, we believe all addresses have already moved their funds to Bitfinex and HitBtc exchanges.

Double spend analysis

The total number of transactions that were double spent was 29, for a total of 3796 BCH. The double spending transactions were split into three groups:

• 1 in block 582701 (4 BCH), which does not appear to be related to the other double spends.

• 1278 in block 582705 (3655 BCH), which spent BCH at segwit addresses to the valid equivalent BCH addresses.

• 13 in block 582715 (216 BCH) that spent BCH at segwit addresses to BCH addresses likely controlled by the “unknown” miner. These transactions included inputs that were not included by BTC.top in block 582705.

Our examination concluded that the segwit inputs that were double spent in block 582705 were sent to their originally intended recipients. This means that the miner of block 582705, BTC.top, was able to derive the “valid BCH equivalent” to the invalid segwit addresses, and rather than sending the funds to an unrelated address as was done by the “unknown” miner of the orphaned block 582698 and main chain block 5827015, BTC.top decided instead to send those funds to the originally intended recipients.

Based on these facts, it appears that there was a hashpower struggle to claim the BCH coins that had been sent to segwit addresses. Due to the fact that the ABC 0-day prevented BCH miners from including any transactions in blocks for several hours after the upgrade activated, this struggle occurred at the earliest possible moment. Block 582698 contained spends of BCH at segwit addresses to addresses associated with the “unknown” miner. The reorg removed those spends from the main chain, and later replaced them with spends to the valid BCH equivalent of the segwit addresses in block 582705. Block 582715 was then mined by the “unknown” miner that “collected the leftovers,” sending a smaller number of BCH still remaining at segwit addresses to an unknown address. Based on the coinbase data in the blocks, we believe that the miner of main chain block 582715 was the same actor as the miner of orphaned block 582698.

Sample Double Spend Transaction

Below is a sample transaction from the “unknown” miner of block 582698 which contained a number of transactions that spent BCH coins from segwit addresses. Prior to the upgrade, these coins were inaccessible.

Image 1: Sample orphaned segwit transaction

In the transaction ebc4… above, the “unknown” miner spends 46 inputs to a single address 1My1… What is unique about the inputs to this transaction is that they are all segwit addresses, such as 35hL… highlighted above.

Below is a transaction that appeared in block 582705 that double spent the sample shown above. Notice the same 35hL… segwit address is an input to this transaction, which is what makes the following transaction a double spend.

Image 2: Double spend transaction e872… in Block 582705

Instead of aggregating segwit inputs like the “Unknown” miner, BTC.top has double spent the same inputs to individual addresses. These individual addresses are in fact the valid BCH equivalents to the invalid segwit addresses. For example, all of the funds from the segwit address 35hL… were transferred to its valid BCH equivalent address 1EVW…

In order to understand how this was done, we need to dive in to the mechanics of segwit addresses.

II. Spending BCH from segwit addresses

As part of the May 15th upgrade, the BCH network made an exception to the clean stack rule to allow recovery of BCH at segwit addresses. The modification of the clean stack rule allows for the spending of coins at segwit addresses by anyone as long as the following two conditions are met:

1. The hash of the public key or the unlocking script associated with a segwit address are known. This information is not revealed when sending funds to a segwit address, but they are revealed in the process of sending funds from a segwit address. Thus, if a particular segwit address that has BCH on it also has received and later sent BTC on the Bitcoin chain, then enough information will be revealed to spend funds in the BCH network as well.

2. A miner must agree to mine the transaction. This is because the BCH transactions required to spend from a segwit address are “nonstandard transactions,” which means they are valid transactions but will not propagate across the network, because network nodes refuse to relay nonstandard transactions.

Recovering P2WPKH Segwit funds.

As we have previously mentioned, in order to spend funds accidentally sent to a P2WPKH(Pay-to-Witness-Public-Key-Hash) segwit address on the BCH network, a miner must know the hash of that address’s public key. The public key hash may be obtained directly from the owner of the address or, if the same segwit address has spent funds on the BTC blockchain, extracted from the transaction that spent the funds on the BTC blockchain.

For example, in the following transaction, BCH is sent to the segwit address 35hL… (Note that “pq4lq2sfvkyh3a9wvmkeqd8f2n5v8t07qg2hd6erum” is just a representation of the same address in the “Cashaddress” format.)

Image 3: Sending funds to a segwit address on the BCH network

A transfer was later made to the very same segwit address on the BTC network. This BTC was later spent from the segwit address, which revealed its public key hash.

Image 4: Spending a sample segwit address on the BTC network

The bottom transaction is when the BTC is deposited to the segwit address on the BTC network. The top transaction spends this BTC, one block later. The top transaction contains the public key hash to this segwit address as shown in its raw form below:

{“txid”:”3ffbf713629fcf66ae6e7155c1f931ad3e6108e47d557c247831c1b7f617a266",”hash”:”469395c9292e04f0b476b77d420d882ecf7bb67be01c0314b503802e26705d32",”version”:1,”size”:249,”vsize”:167,”weight”:666,”locktime”:0,”vin”:[{“txid”:”4065337e9f82c4a57aef23011185676077a7e6a96d606c27b01b28cc68b1886c”,”vout”:1,”scriptSig”:{“asm”:”001493fdaf42a7b8e82fede6fe0f6184536a11193cce”,”hex”:”16001493fdaf42a7b8e82fede6fe0f6184536a11193cce”},”txinwitness”:[“304502210097a74f034d5adb4ceec0b8617fa24ee9faf95736f188cdee22b60e824025ac8402205de42bef12a4752024368a08a83547effc6de60b78111faa9a1c8f4f89adf4d501”,”02f68ea65bb67b8552a9cc11a47c251943e64c4dad4963ae006e638de6921b54ff”],”sequence”:4294967295}],”vout”:[{“value”:0.01542272,”n”:0,”scriptPubKey”:{“asm”:”OP_DUP OP_HASH160 4aed1e7a21ee87a69be93dbeda198d65752ff73a OP_EQUALVERIFY OP_CHECKSIG”,”hex”:”76a9144aed1e7a21ee87a69be93dbeda198d65752ff73a88ac”,”reqSigs”:1,”type”:”pubkeyhash”,”addresses”:[“17qB4WvfbnNP4AVzkpGV1hsXHUpdu41FGU”]}},{“value”:0.00049692,”n”:1,”scriptPubKey”:{“asm”:”0 532b4f8533e6a0d51ee537ec48319228b374f4cb”,”hex”:”0014532b4f8533e6a0d51ee537ec48319228b374f4cb”,”reqSigs”:1,”type”:”witness_v0_keyhash”,”addresses”:[“bc1q2v45lpfnu6sd28h9xlkysvvj9zehfaxtkn2t65”]}}]}

Once the May 15 upgrade modified the clean stack rule, BCH miners can use the hash of the public key above to spend the funds at the segwit address. For example, the transaction below spends these funds:

Image 5: Spending a segwit address on the BCH network

Looking at the raw data, you can find the very same HASH160 of the public key from the transaction on the BTC network above was also used on the BCH network:

{“txid”:”e872243f11d82ee348b2ae736dccd6b432f719e88c778b5513489f890c19a56d”,”hash”:”e872243f11d82ee348b2ae736dccd6b432f719e88c778b5513489f890c19a56d”,”version”:1,”size”:108,”locktime”:0,”vin”:[{“txid”:”bad87c9a6feae56e07cbaf1d064611e43a0fab40fcef94a424d18713756be2f4",”vout”:0,”scriptSig”:{“asm”:”001493fdaf42a7b8e82fede6fe0f6184536a11193cce”,”hex”:”16001493fdaf42a7b8e82fede6fe0f6184536a11193cce”},”sequence”:4294967295}],”vout”:[{“value”:0.50752982,”n”:0,”scriptPubKey”:{“asm”:”OP_DUP OP_HASH160 93fdaf42a7b8e82fede6fe0f6184536a11193cce OP_EQUALVERIFY OP_CHECKSIG”,”hex”:”76a91493fdaf42a7b8e82fede6fe0f6184536a11193cce88ac”,”reqSigs”:1,”type”:”pubkeyhash”,”addresses”:[“bitcoincash:qzflmt6z57uwstldumlq7cvy2d4pzxfueckq7xg080”]}}]}

Thus, once the BCH clean stack rule was modified, the spending of funds from this address on the BTC network allowed any BCH miner to spend any BCH that might be at the address. In the case of the transactions in blocks 582698 and 582699, this BCH was spent to unknown addresses. However, in the case of the transactions in block 582705 that double spent these transactions, the BCH was spent to special addresses.

What makes segwit transactions mined by BTC.top special is that their destination addresses such as bitcoincash:qzfl… and its legacy equivalent 1EVWEWrvrjcpHXPtEvY3D4JfWLrzRVtMQc in the example above are actually controlled by the same private key as the original segwit address. It is quite simple to derive this address once the public key hash for the segwit address is known, which was a requirement to spend these coins in the first place. Generating this address uses the normal BTC/BCH address derivation algorithm, just skipping the HASH160 step, since we already have the output of that step from the public key hash:

$ echo ‘93fdaf42a7b8e82fede6fe0f6184536a11193cce’ | bx address-encode

1EVWEWrvrjcpHXPtEvY3D4JfWLrzRVtMQc

By sending funds to the address controlled by the same private key as the segwit address, the miner is effectively making previously unrecoverable funds accessible to the originally intended recipient.

Recovering P2WSH Segwit Funds

The example above only works for sends to segwit addresses that were of type P2WPKH, but there is a second type of segwit address — P2WSH (Pay-to-Witness-Script-Hash). Below is a sample transaction to recover funds mined by BTC.top illustrating such an address:

Image 6: Recovering funds from a P2WSH segwit address

Notice that funds in the segwit address 3G8Z…were sent to the P2SH address 35VG…instead of a P2PKH address which start with a “1”. The 3G8Z… address is actually a multi-signature P2SH script as defined in BIP-141 which makes things a bit more complicated for recovery.

Just like with P2WPKH the unlocking scriptSig can be obtained from a corresponding transaction on the BTC network:

{“txid”:”085685b104a6ee79d90546a27873d52fdf9cd252aa714d4f533a780bfe31dd88",”hash”:”300564866319ba006cfecea46b354c649c5f91fe778f5857091977efd11824c0",”version”:1,”size”:408,”vsize”:216,”weight”:864,”locktime”:0,”vin”:[{“txid”:”acc8ef9eca068e36062b050321fd8e4adf13bcad49718eb4f992e29c6426a512",”vout”:1,”scriptSig”:{“asm”:”0020883a730777b7119f563b84221abd5c742665f659d4c835ad771fb0bfb21064be”,”hex”:”220020883a730777b7119f563b84221abd5c742665f659d4c835ad771fb0bfb21064be”},”txinwitness”:[“”,”3045022100af15f05927517cfaa4978ab7d3ef1036664df44f47f6f1efeb0ae16bd358137902205fe531c37fab614d0e2cd802d8f481fcfb968901aed1e0d4c5771be4579626a501",”3045022100e229eabf5e2779453aff54544e657858eece5fcf528dedbb0bbfe413df7b37e00220694de848b5b7ca58f31483baff4a7f890d64256b10ebc5f38c2c8f6348f0be6401",”5221026965ff50ba461b7bc54ae88c5dd45f334db242d0bf63a5bd5a6158835784b8f82102f864ea0765243a045bf572b6f62bb2ccd0c736ffcda21442ecc252eb32c388262103e3f2e6c762fd7aeafcd390b492accf5cd1108cf1eff1b8f78f76a56442e8684e53ae”],”sequence”:4294967295}],”vout”:[{“value”:0.01848363,”n”:0,”scriptPubKey”:{“asm”:”OP_HASH160 c55c269abd40a8d21519d44b030c7d14e1ecd544 OP_EQUAL”,”hex”:”a914c55c269abd40a8d21519d44b030c7d14e1ecd54487",”reqSigs”:1,”type”:”scripthash”,”addresses”:[“3KgZS5q7KRh2eM1NKXhe3nVGAYgE7Bz3ic”]}},{“value”:0.0262,”n”:1,”scriptPubKey”:{“asm”:”OP_DUP OP_HASH160 89e5e15821fe9c9ec96b078c0e1ed72db3743589 OP_EQUALVERIFY OP_CHECKSIG”,”hex”:”76a91489e5e15821fe9c9ec96b078c0e1ed72db374358988ac”,”reqSigs”:1,”type”:”pubkeyhash”,”addresses”:[“1Da8xeA4Zr6tgnDAeDE52Q87qwRFT7RiCD”]}}]}

Taking the hash160 of the scriptSig confirms the original segwit address and can now be used to recover the transaction:

$ echo ‘0020883a730777b7119f563b84221abd5c742665f659d4c835ad771fb0bfb21064be’ | bx bitcoin160 | bx address-encode -v 5

3G8Z2tdL1GwC9NcjBC6Ycghnc84cJshN1f

However, in order to send those funds to the non-segwit equivalent on the BCH network we have to look at the unlock script in the segwit section of the BTC transaction. Notice the last txinwitness entry above, it defines a multi-signature script and can be decoded as follows:

$ echo ‘5221026965ff50ba461b7bc54ae88c5dd45f334db242d0bf63a5bd5a6158835784b8f82102f864ea0765243a045bf572b6f62bb2ccd0c736ffcda21442ecc252eb32c388262103e3f2e6c762fd7aeafcd390b492accf5cd1108cf1eff1b8f78f76a56442e8684e53ae’ | bx script-decode

2 [026965ff50ba461b7bc54ae88c5dd45f334db242d0bf63a5bd5a6158835784b8f8] [02f864ea0765243a045bf572b6f62bb2ccd0c736ffcda21442ecc252eb32c38826] [03e3f2e6c762fd7aeafcd390b492accf5cd1108cf1eff1b8f78f76a56442e8684e] 3 checkmultisig

In order to replicate the same behavior on the BCH network, we need to generate an equivalent P2SH address based on the full checkmultisig script above:

$ echo ‘5221026965ff50ba461b7bc54ae88c5dd45f334db242d0bf63a5bd5a6158835784b8f82102f864ea0765243a045bf572b6f62bb2ccd0c736ffcda21442ecc252eb32c388262103e3f2e6c762fd7aeafcd390b492accf5cd1108cf1eff1b8f78f76a56442e8684e53ae’ | bx bitcoin160 | bx address-encode -v 5

35VGQpXdATDdkArZpafKwCMJRsoFwi6Gab

This corresponds to the same address used in the recovery transaction by BTC.top and can be unlocked by the same intended recipients on the BCH network.

Conclusion

Coinbase’s investigation is ongoing. The scope of this analysis is limited to transactions that were double spent, however, it is possible that there were transactions spending BCH at segwit addresses that were not double spent, and thus would not have been included in this analysis. It is important to reach a full understanding of the total amount of BCH sent to segwit addresses, how much of that BCH is still at segwit addresses, how much has been sent to the valid BCH equivalents of those segwit addresses, and how much has been sent to unrelated BCH addresses.

The Segwit recovery mechanisms described above work by gleaning exposed public key or unlock script data recorded on the BTC blockchain. Since this information is publicly available, it created a race condition where the unknown miner tried to spend the segwit coins before the BTC.top mining pool had a chance to execute the segwit recovery process.

We find it remarkable that BTC.top derived the technical solution to recover BCH funds mistakenly lost by users, choosing to send the coins to their intended recipients rather than claiming the funds for themselves.

Appendix A

BCH addresses with recovered segwit funds mined in block 582715

qzgxrv03axyj43tlghez3lfx0w7qgzc4lupuuhn7rj

qreyu2fng05c8pu2dgt5qlrm4fnhqeqg4shqaetvqx

qr505me362r482zmztpf374trh0azme4xuwanu94l0

qrt28quv2ur4rk27mj5ts0c0z9akqgl9ss34xfpc9p

qpczrc2ueqc0lfp72u9fh08um8a3nqlgyclz3q00a6

qr586dnpnc9nysv4e00z8zzc5nanxamy8ggaanuktq

qrwertpzqn53xhhcy9r5rgl4qglzu64tgs6pxry5kh

qz2mjv4gurwxr2qm9yurke4le6tl7w9hsqzzjnc06r

qp8ap9hhuljhegylvqcg5t05a5tddzt565pdf83jxj

qp3y94tyrvjn5y38sh02mq87g2j7hrktyy2tnrut7k

qpxw8w8yh5xhq9w2hxzfse9qyq6u0yx3q57nzvh46n

qqtzhnu2th0f5u8ay3wrp8v7ugkmvp7ypuqc4lfyuu

qpu7jawy36a7cvamcyc2y4lgn7ckq0pwpg3r9tydc3

This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.

Unless otherwise noted, all images provided herein are by Coinbase.