Facebook Takes on ETF Giant Blackrock, with a Fixed Income ETF called Libra

Abstract: In a bold move, social networking giant Facebook, has challenged the traditional finance and ETF industry, with its “Libra coin”, or as we call it the “Libra ETF”. We note that there are many unanswered questions about Libra, which may lack transparency, when compared to traditional ETFs. Another key disadvantage of Libra is that unlike with legacy ETFs, investment income is not distributed to unit holders. We conclude that although Libra has significant disadvantages when compared to traditional ETF products, Facebook’s wide consumer reach with platforms such as Whatsapp and Instagram could give Libra a key commercial advantage.

(Facebook vs Blackrock – The battle for the ETFs)

Overview

The structure of Libra is analogous to the popular Exchange Traded Fund (ETF) model, where unit holders are entitled to the financial returns of a basket of financial assets. The units are tradable on exchanges and a select group of authorised participants are able to create and redeem units using the underlying assets.

As we pointed out in our February 2019 piece, the ETF industry has enjoyed considerable growth in the last decade or so, in particular in the area of fixed income (See figure 1 below). In June 2019, in a bombshell moment for the ETF industry and challenge for the established players such as Blackrock and Vanguard, social media and internet conglomerate Facebook, entered the game. In a direct challenge to Blackrocks’s “iShares Core U.S. Aggregate Bond ETF” (AGG), Facebook announced plans to launch a new ETF, the “Libra ETF”, also focused on fixed income and government bonds.

Figure 1 – Size of the Top Bond ETFs Targeting US Investors – US$ Billion

(Source: BitMEX Research, Bloomberg)

(Note: The chart represents the sum of the market capitalisations of the following bond ETFs: iShares Core U.S. Aggregate Bond ETF, Vanguard Total Bond Market ETF, iShares iBoxx $ Investment Grade Corporate Bond ETF, Vanguard Short-Term Corporate Bond ETF, Vanguard Short-Term Bond ETF, Vanguard Intermediate-Term Corporate Bond ETF, iShares J.P. Morgan USD Emerging Markets Bond ETF, Vanguard Total International Bond ETF, iShares MBS Bond ETF, iShares iBoxx $ High Yield Corporate Bond ETF, PIMCO Enhanced Short Maturity Strategy Fund, Vanguard Intermediate-Term Bond ETF, iShares Short-Term Corporate Bond ETF, SPDR Barclays High Yield Bond ETF, iShares Short Maturity Bond ETF)

Comparing the new ETF structure with the traditional space

In figure 2 below, we have analysed and compared the new innovative Libra ETF to a traditional ETF, Blackrock’s iShares Core US Aggregate Bond ETF (AGG). Our analysis shows that, although the Libra product is new, much of the relevant information, such as transparency of the holdings and frequency of the  publication of the NAV, has not yet been disclosed.

The analysis also highlights that Libra may suffer from unnecessary complexity with respect to portfolio management. The fund appears to be managed by the Libra Association, which consists of many entities in multiple industries across the globe. These same entities are responsible for issuing the ETF and the list of companies is set to expand further. At the same time, the investment mandate is unclear. In contrast Blackrock’s fixed income ETF product has a clear investment mandate, to track the Bloomberg Barclays U.S. Aggregate Bond Index, which is managed independently of the ETF issuer.

Perhaps the most significant disadvantage of the Libra product, is that unit holders do not appear to be entitled to receive the investment income. This contrasts unfavourably with Blackrock’s product, which focuses on an almost identical asset class and has an investment yield of around 2.6%. Defenders of Libra could point out that the expenses need to be covered from somewhere and that the Libra’s expense fee is not yet disclosed. However, the ETF industry is already highly competitive, with Blackrock charging an expense fee of just 0.05%. This expense fee is far lower than the expected investment yield of the product, at around 2.6% and therefore the Libra ETF may not be price competitive, a key potential disadvantage for potential investors.

Figure 2 – Libra ETF vs iShares Core U.S. Aggregate Bond ETF (AGG) – Detailed Comparison

  Libra ETF

iShares Core U.S. Aggregate Bond ETF (AGG)

Launch date June 2019 September 2003
IssuerThe Libra Association/Facebook Blackrock
AuM Unknown

US$63.5 billion

Asset class

Fixed Income

Bank deposits and government securities in currencies from stable and reputable central banks

Fixed income – Investment grade government and corporate bonds
Underlying Index Unknown/Not applicable Bloomberg Barclays U.S. Aggregate Bond Index

Portfolio managers

The Libra Association, based in Switzerland will manage the reserve. The investment mandate is not currently disclosed. The current members are as follows:
  • Mastercard
  • PayPal
  • PayU (Naspers’ fintech arm)
  • Stripe
  • Visa
  • Booking Holdings
  • eBay
  • Facebook/Calibra
  • Farfetch
  • Lyft
  • MercadoPago
  • Spotify
  • Uber
  • Iliad
  • Vodafone Group
  • Anchorage
  • Bison Trails
  • Coinbase
  • Xapo
  • Andreessen Horowitz
  • Breakthrough Initiatives
  • Ribbit Capital
  • Thrive Capital
  • Union Square Ventures
  • Creative Destruction Lab,
  • Kiva
  • Mercy Corps
  • Women’s World Banking

James Mauro and Scott Radell, with a clear constrained mandate to track the index

Fees

Unknown

0.05%

Investment yield

Unknown

2.6%

Use of investment income

Unit holders are not entitled to investment income Investment income will:

first go to support the operating expenses of the association — to fund investments in the growth and development of the ecosystem, grants to nonprofit and multilateral organizations, engineering research, etc. Once that is covered, part of the remaining returns will go to pay dividends to early investors in the Libra Investment Token for their initial contribution

Attributable to ETF unit holders

Available exchanges

Currently None

The Libra Association

will encourage the listing of Libra on multiple regulated electronic exchanges throughout the world

NYSE

Creation/redemption basket size

Unknown

100,000 units

Authorized Participants (entities able to create and redeem units)

Authorized resellers, not currently disclosed

Investment Banks

Fund auditor

Unknown

PwC

Information about holdings and Net Asset value (NAV)

Unknown

Full disclosure (Published daily)

(Sources: iShares, Libra)

We have also analysed the two alternatives from a technical perspective. As figure 3 below indicates, the key difference is that control of Libra tokens may in part be managed by digital signatures. As long as no whitelist of addresses is implemented, this may provide some advantages:

  • Pseudonymity
  • A limited amount of censorship resistance
  • Relatively easy integration with cryptocurrency exchanges

However, as we mentioned in our Tether report in February 2018, history has shown that these characteristics can cause platforms to ultimately face a choice between implementing KYC or face being shut down by the authorities. Facebook has already censored politically controversial figures on its main platform, therefore it may appear likely the extent to which Libra ETF units are managed by public private key cryptography is significantly constrained or eventually becomes phased out.

Figure 3 – Technical and cryptographic considerations

 

Libra ETF

iShares Core U.S. Aggregate Bond ETF (AGG)

Consensus system

Not applicable (An ETF does not require a consensus system)

Blockchain

Not relevant (Grouping records of ETF transactions into a chain of blocks linked together by hashing, is inconsequential for ETFs)

Control of units based on digital signature

Possibly:

The Libra Blockchain is pseudonymous and allows users to hold one or more addresses that are not linked to their real-world identity

No

(Sources: iShares, Libra)

Conclusion

Despite the key disadvantage, namely that Libra unit holders are not entitled to the investment income, many industry analysts are carefully examining the impact Libra could have on the traditional ETF industry and existing electronic payment systems.

While our comparison to ETFs is a bit tongue and cheek, it does highlight that the structure of the product has similar attributes to existing financial products. We therefore think it is an appropriate comparison, and if Libra wants to be competitive, it should emulate some of the governance and fee characteristics of traditional ETFs.

However, Libra could attract clients due to integration with platforms such as Facebook, Whatsapp and Instagram. If Libra does retain the property of allowing coins to be controlled by private keys, this is an interesting development and the coin is likely to gain share from tokens such as Tether. However, in our view, in the long run, it is likely Libra either disables this feature or makes it technically difficult, such that only a tiny minority of users have these “non-custodial” wallets. If that happens, Libra is nothing more than a high fee ETF.

WebSocket API Feed Interruption, 27 June 2019

Between 07:50 and 07:58 UTC on 27 June 2019, the following websocket API feeds were interrupted due to a complication during a planned upgrade of our market data distribution services:

  • Account, affiliate, execution, funds, instrument, margin, order, position, trade, transact, wallet

Users of the BitMEX website may have noticed some data not updating during this period e.g. in the Recent Trades panel, Open Orders panel, Fills panel, and Position panel.

The following public feeds were unaffected during this period:

  • Funding, insurance, liquidation, settlement, impactQuote, impactQuoteBin1m, quote, quoteBin1m, quoteBin5m, quoteBin1h, quoteBin1d, tradeBin1m, tradeBin5m, tradeBin1h, tradeBin1d, orderBookL2_25, orderBook10, orderBookL2

During this period we continued to process order instructions and the trading engine was unaffected.

Due to this issue, data in a subset of data mirrors which service user REST API requests was left in an incomplete state. A side-effect of this was that some users observed stale open orders on the BitMEX website for orders which were already cancelled for a period of 90 minutes whilst data was being restored. Any API users that may be missing updates for this period can now backfill data via the REST API.

If you are experiencing order cancellation issues via the website, please refresh your web browser.  We apologise for any inconvenience this interruption may have caused. If you have any further questions please contact Support via our contact form: https://www.bitmex.com/app/support/contact.

WebSocket Rate Limiting Issue, 25 June 2019

At 21:09:00 UTC 25 June, we released an update to our API layer that inadvertently started to count WebSocket subscriptions to certain tables against the request rate limit that had otherwise been exempt. This update may have impacted customers who heavily utilise the WebSocket API. Once the issue was identified at 00:19 UTC 26 June, we immediately rolled back the update to bring systems back to normal.

We apologise for any inconvenience this may have caused. To read more about which subscriptions are exempt from the request rate limiter, see our previous blog post for details. 

ETHUSD Orderbook Feed Issues, 24 June 2019

Between 09:25:54 UTC and 09:44:30 UTC 24 June 2019 the orderBookL2, orderBookL2_25, orderBook10, and quote realtime websocket feeds for ETHUSD were in a degraded state. During this period, the state of the ETHUSD orderbook on these feeds was incorrect.

We were able to identify and resolve the root cause of the issue within a minute of detection. The issue was caused by a rare sequence of order events that triggered a bug in an optimisation of the orderBookL2 calculation which had been deployed to the production environment several hours earlier. This change has since been reverted.

There was no impact to orders in the trading engine itself – just the presentation of the calculated orderbook for ETHUSD downstream of the trading engine.

We have deployed additional automated feed validators to detect potential similar issues in the future and to alert us earlier.

We apologise for the inconvenience this may have caused. If you have any further questions, please contact Support via our contact form: https://www.bitmex.com/app/support/contact.

Q3 2019 Quarterly Futures Listings

On 14 June 2019 at 08:30 UTC, BitMEX will list new quarterly futures.

Please see the following tables for listings and settlements for current and upcoming futures contracts for Q3 2019. Bolded rows are the new contracts.

Code Pair Listing Settlement
ADAM19 Cardano / Bitcoin 15 Mar 2019 28 Jun 2019
ADAU19 Cardano / Bitcoin 14 Jun 2019 27 Sep 2019
BCHM19 Bitcoin Cash / Bitcoin 15 Mar 2019 28 Jun 2019
BCHU19 Bitcoin Cash / Bitcoin 14 Jun 2019 27 Sep 2019
EOSM19 EOS Token / Bitcoin 15 Mar 2019 28 Jun 2019
EOSU19 EOS Token / Bitcoin 14 Jun 2019 27 Sep 2019
ETHM19 Ether / Bitcoin 15 Mar 2019 28 Jun 2019
ETHU19 Ether / Bitcoin 14 Jun 2019 27 Sep 2019
LTCM19 Litecoin / Bitcoin 15 Mar 2019 28 Jun 2019
LTCU19 Litecoin / Bitcoin 14 Jun 2019 27 Sep 2019
TRXM19 Tron / Bitcoin 15 Mar 2019 28 Jun 2019
TRXU19 Tron / Bitcoin 14 Jun 2019 27 Sep 2019
XRPM19 Ripple Token (XRP) / Bitcoin 15 Mar 2019 28 Jun 2019
XRPU19 Ripple Token (XRP) / Bitcoin 14 Jun 2019 27 Sep 2019
XBTM19 Bitcoin / USD 17 Dec 2018 28 Jun 2019
XBTU19 Bitcoin / USD 15 Mar 2019 27 Sep 2019
XBTZ19 Bitcoin / USD 14 Jun 2019 27 Dec 2019

Important Security Advisory Update, June 2019

Summary: We have observed an increased number of unauthorised attempts to access customer accounts. We would like to remind all customers and users to please protect your BitMEX and personal accounts by: using strong and unique passwords; enabling Two-Factor Authentication (2FA) for all your accounts; and using a password manager.

Security has always been the number one priority at BitMEX. This is why we were the first platform to adopt a manual multi-signature cold wallet setup to protect customer funds. We are consistently reviewing our security protocols and improving our standards. We remain committed to continual improvement of our platform security and the security of our customers.

In 2016, following a large botnet credential reuse attack, we published a blog post highlighting the importance of using unique passwords on BitMEX. In addition, we recommended enabling 2FA. 2FA, sometimes referred to as ‘two-step verification’ or ‘multi-factor authentication’, adds an additional layer of security to your account by requiring not only your username and password at login, but also the input of a unique, time-based token. Tokens can be stored on a cell phone within a software-based authenticator app such as Google Authenticator or Authy.

This message was as true and relevant then as it is now: to protect your account, you should always use strong unique passwords, in combination with a multi-factor authentication solution and password manager.

More recently, we have witnessed an increased number of attempts to compromise or obtain unauthorised access to customer accounts. Enabling 2FA on your account is the best and easiest way to protect yourself from these attacks.

Furthermore, we have observed a continued increase in the sophistication and tactics utilised by financially motivated criminals. One example of this: rather than the attacker immediately executing a withdrawal request, we have observed attackers trading funds out of accounts by deliberately making losses against another account which they also control. We have proactively identified a number of these attacks, and continue to eliminate this activity as it is detected.

Another recurring tactic observed in account takeovers is the disabling of BitMEX email login notifications following unauthorised account access. An attacker may also attempt to enable 2FA on a compromised customer account in order to create an API key with withdrawal permissions. A common thread in almost all cases is that customers may not have seen a withdrawal notification or other account related email notification; for example, a login notification.

While we review practices such as enforcing 2FA and other login access features, we have made the following changes:

  1. Customers can no longer disable login notification emails. The login notification emails will now be sent regardless of existing notification preferences.
  2. Withdrawal requests issued via the API must always complete an email verification step to confirm a withdrawal, unless the API key used was created before 8:00PM June 10, 2019 (UTC).

These changes are a step toward increasing account security for our customers, however it is important to realise that this is not the full solution. Enabling 2FA remains our strongest recommendation.

In addition to the above, BitMEX has reviewed each and every account takeover experienced by our customers and we have identified several common factors among compromised accounts:

  1. Password reuse, or use of trivially guessed passwords on the BitMEX platform and on customer personal email accounts.
  2. Compromised personal email accounts leading to account theft via password recovery flows.
  3. Malware on customer computers leading to secure password theft and subsequent login to the bitmex.com platform.

In order to combat these attacks, adopting a vigilant, disciplined approach to security is key. In all of the above scenarios, utilising 2FA greatly decreases the risk of account compromise. This is further highlighted by recent research by Google that has shown that 100% of attacks can be blocked if a security key has been used for 2FA.

While we consider mandatory enforcement of 2FA across our customer base, we will again stress the importance of adopting good security practices as outlined below.

Note that these steps should be taken not only on your BitMEX account but on personal accounts where you store any confidential information:

  1. Enable 2FA
      1. We recommend utilising one of the many available options, such as Google Authenticator or Authy.
  2. Use a strong unique password and utilise a Password Manager such as LastPass
      1. A strong password consists of at least ten characters (and the more characters, the stronger the password) that are a combination of letters, numbers and symbols (@, #, $, %, etc.). Passwords are typically case-sensitive, so a strong password contains letters in both uppercase and lowercase.
      2. Do NOT use the same passwords for your social media accounts such as Facebook, Spotify or Instagram accounts as you would for your BitMEX trading accounts or bank accounts. Use strong, unique and different passwords for each and every account!
  3. Assess your existing risk
      1. Check to see if your password has been leaked in a third-party breach via services like HIBP.
      2. Check your trading accounts on a regular basis to ensure that you know what the balances are or should be.  
      3. Regular reconciliation of your accounts would be a useful way for you to ensure all transactions in your accounts are with your authorisation.
  4. Add support@bitmex.com to your contacts list and ensure our emails are not landing in your SPAM folder
      1. Ensure that you are not filtering official communications from bitmex.com. These communications include login and withdrawal notifications.
  5. BitMEX support will NEVER ask for your account password

At BitMEX, we take security very seriously. Whilst we continue to evolve our security capabilities both externally and internally, security is ultimately everyone’s responsibility. If you have digital funds on your online accounts, it is critical that you take steps to ensure your account safety/security as above.

If you observe any unusual activity on your account, please contact our Support team immediately via our contact page.

Scheduled System Update, 04 June 2019

Please be advised that we will be performing a scheduled system update to our database service starting 01:00 UTC 04 June 2019 and it is expected to last 3 – 5 hours. Trading, logins, and other key API features will remain operational, however please note that the following features will be disabled during the update period:

  • New account signup
  • Email verification
  • Enable TFA
  • Disable TFA
  • Password reset
  • Withdrawal
  • Update preferences
  • Mute accounts on the Trollbox
  • Create API Key
  • Disable API Key
  • Enable API Key
  • Delete API Key

Once we have completed the system update we will make a further announcement.

We apologise for any inconvenience this may cause. Feel free to contact our Support with any concerns you may have about the scheduled update. You may reach us via our contact form: https://www.bitmex.com/app/support/contact

Websocket Latency, 30 May 2019

Between 16:00 and 17:00 UTC 30 May 2019 the websocket API experienced periods of substantial lag due to spikes of traffic generated by the trading engine during large market moves. During this period some websocket connections also experienced dropped market data updates as memory limits on an internal messaging layer were hit, forcing reconnections.

Our engineers are accelerating the development effort in an already-planned strategic upgrade of our market data distribution architecture to vastly increase its capacity and lower the overall latency of the websocket feed. This capacity upgrade is scheduled for Testnet release this week and we will update users once this has been released to the main platform.

If you have any further questions, please contact Support via our contact form: https://www.bitmex.com/app/support/contact.

HDR Global Trading Limited Donates to the Massachusetts Institute of Technology’s Digital Currency Initiative (MIT DCI) In Support of Cryptocurrency Research

We are delighted to announce HDR Global Trading Limited’s support of the MIT Digital Currency Initiative, which conducts research into the development and betterment of the global cryptocurrency ecosystem.

Sam Reed, CTO of HDR Global Trading and co-founder of the BitMEX trading platform, announced the sponsorship:

Our company has always been energized by the potential of cryptocurrency. Our donation into research and development is about ensuring that the network is more robust. A stronger Bitcoin network will be beneficial to all, and we are very excited to be able to aid in its progress.

HDR Global Trading owns and operates BitMEX, the world’s largest cryptocurrency trading platform by volume. HDR Global Trading is proud to support Bitcoin research and engineering that will make Bitcoin stronger, improving Bitcoin’s robustness, scalability and privacy.

In particular, HDR is keen to help support the work of Bitcoin Core developers Wladimir van der Laan and Cory Fields. Their roles have important implications on different parts of the Bitcoin protocol.

The donation is provided unconditionally and without restrictions.

The Bitcoin Cash Hardfork – Three Interrelated Incidents

Abstract: The 15 May 2019 Bitcoin Cash hardfork appears to have suffered from three significant interrelated problems. A weakness exploited by an “attack transaction”, which caused miners to produce empty blocks. The uncertainty surrounding the empty blocks may have caused concern among some miners, who may have tried to mine on the original non-hardfork chain, causing a consensus chainsplit. There appears to have been a plan by developers and miners to recover funds accidentally sent to SegWit addresses and the above weakness may have scuppered this plan. This failure may have resulted in a deliberate and coordinated 2 block chain re-organisation. Based on our calculations, around 3,392 BCH may have been successfully double spent in an orchestrated transaction reversal. However, the only victim with respect to these double spent coins could have been the original “thief”.

Illustration of the Bitcoin Cash network splits on 15 May 2019

(Source: BitMEX Research)
(Notes: Graphical illustration of the split)

The three Bitcoin Cash issues

Bitcoin Cash’s May 2019 hard fork upgrade was plagued by three significant issues, two of which may have been indirectly caused by a bug which resulted in empty blocks. The below image shows the potential relationships between these three incidents.

The relationships between the three issues faced by Bitcoin Cash during the hardfork upgrade

(Source: BitMEX Research)

The empty block problem

Bitcoin ABC, an important software implementation for Bitcoin Cash, appears to have had a bug, where the validity conditions for transactions to enter the memory pool may have been less onerous than the consensus validity conditions. This is the opposite to how Bitcoin (and presumably Bitcoin Cash) are expected to operate, consensus validity rules are supposed to be looser than memory pool ones. This is actually quite an important characteristic, since it prevents a malicious spender from creating a transaction which satisfies the conditions to be relayed across the network and get into a merchants memory pools, but fails the conditions necessary to get into valid blocks. This would make 0-confirmation double spend attacks relatively easy to pull off, without one needing to hope their original payment doesn’t make it into the blockchain. In these circumstances, an attacker can be reasonably certain that the maliciously constructed transaction never makes it into the blockchain.

An attacker appears to have spotted this bug in Bitcoin Cash ABC and then exploited it, just after the hardfork, perhaps in an attempt to cause chaos and confusion. This attack could have been executed at any time. The attacker merely had to broadcast transactions which met the mempool validity conditions but failed the consensus checks. When miners then attempted to produce blocks with these transactions, they failed. Rather than not making any blocks at all, as a fail safe, miners appear to have made empty blocks, at least in most of the cases.

Bitcoin Cash – Number of transactions per block – orange line is the hardfork

(Source: BitMEX Research)

The asymmetric chainspilt

At the height of the uncertainty surrounding the empty blocks, our pre-hardfork Bitcoin ABC 0.18.2 node received a new block, 582,680. At the time, many were concerned about the empty blocks and it is possible that some miners may have reverted back to a pre-hardfork client, thinking that the longer chain was in trouble and may revert back to before the hardfork. However, this is merely speculation on our part and the empty block bug may have had nothing to do with the chainsplit, which could have just been caused by a miner who was too slow to upgrade.

Bitcoin Cash consensus chainsplit

(Source: BitMEX Research)

The chainsplit did highlight an issue to us with respect to the structure of the hardfork. We tested whether our post hardfork client, ABC 0.19.0, would consider the non-hardfork side of the split as valid. In order for the break to be “clean”, each side of the split should consider the other as invalid.

In order to test the validity of the shorter pre-hardfork chain, from the perspective of the Bitcoin ABC 0.19.0 node, we had to invalidate the first hardfork block since the split. We then observed to see whether the node would follow the chainsplit or remain stuck at the hardfork point. To our surprise, as the below screenshot indicates, the node followed the other side of the split. Therefore the split was not clean, it was asymmetric, potentially providing further opportunities for attackers.

Screenshot of the command line from our Bitcoin ABC 0.19.0 node

(Source: BitMEX Research)

The coordinated two block re-organisation

A few blocks after the hardfork, on the hardfork side of the split, there was a block chain re-organisation of length 2. At the time, we thought this was caused by normal block propagation issues and did not think much of it. For example, Bitcoin SV experienced a re-organisation a few weeks prior to this, of 6 blocks in the length. When Bitcoin SV re-organised, all transactions in the orphaned chain eventually made it into the main winning chain (except the Coinbase transactions), based on our analysis. However, in this Bitcoin Cash re-organisation, we discovered that this what not the case.

The orphaned block, 582,698, contained 137 transactions (including the Coinbase), only 111 of which made it into the winning chain. Therefore a successful 2 block double spend appears to have occurred with respect to 25 transactions. The output value of these 25 transactions summed up to over 3,300 BCH, as the below table indicates.

List of transactions in the orphaned block (582,698) which did not make it into the main chain

Transaction ID

Output total (BCH)

1e7ed3efb7975c06ca46598808e17c6f42c66a085fcb65356dc090e3c434d874

Coinbase (not counted)

0cdd5afff40831199d78ac55116a94aaf4ea7d53e599ac44962c29861ef9f05e

79.9

1907e59313a5c2607f706e8439feb613ed3ff89530d17bd9deced7113928df79

358.9

27553ff15a9d58b10b33da69bef3ccd570c007fc0d695cf8b88817cfc4d49065

65.2

2ff74d9b244469dcd87f9c853b70f9bc72d4116c662ee12783a1c32a6825d45e

196.3

357e31bcf17b4d557954b2d69b7169559a64605a628c4bb9eb11adbd416967d1

117.4

3801dc4ee11ccaeda243ac287ee5e40afb0f07dc0ba26f534ea52f4bfde0d3da

161.2

83e6065dd31ef706f6a90669e460000741820c4dcb753290bd2b003a9f853211

71.2

8950cae069562893aa3583b75fd14f2aaef4f0db72292bd05e11f915ca38cd86

107.8

8e10f1f85d9707ca974ddabd9cb8188d0b890586781ef4161a9133dadefbe0e6

72.0

8fc0b3665f4734b56686ffec83f6b23000720af90102e20f39d9dddb5f1f5c25

183.0

99bd320fb7e3fc487b393c3b9afbc6a7bc765d7f9df5902201a70d3cb8fc5a63

57.8

a38b43f85cc592c4bd69b2b1f0f865df6d36f3b89dfa6119780197369e48192a

177.8

b091bf34d72444ff1669dd13b6c912d8801b94aad8a92d162a9680d46d4b727f

89.2

bd8ee13735dcbdad983fe9624c5b3fd3d257b15a62b269ddb40bb4be9d4a15cb

100.5

beae5bc9137beebddea6f5fbc6fe79b77f6d59f2aa2a5da675ccc39b2b2f8cb6

166.3

c47d1c18c39d28df21ce0e3c34021295658b56c7e669af3aebe685cea32462dc

210.3

c8031b2fd429d9e2838dccc7fa0631788139443a7609958c5d2ce195aec97f8a

85.7

cf3af954a7c3b327107aa42498ec31924075bd926a61428352695a696af8d6c4

114.8

cf8f47928c37bc24c88ff8ff8ea3c84419d4cedc907e74d113e681b055c566dc

162.0

dff4537328f2568db5b7f0fa81a57024fdeb9da23a432a893fb48eca1ab63079

115.9

e1398e628da1258db08f969efdade13e6daac6a53e5b43121dab3604c605af29

69.9

e926ce8ca0192b3ea7f971d93eec3f651e8a35839a76101512cb8c37f98caa89

126.8

e9e0482d61300d3b3d6a9340f9ee66bd6d098328cd7ced50416bb28eb8dc796e

307.4

ebc4392b27056b84a0337638f1257031172d842c148f9ffa10e80afc4080d8a1

           82.7

f81267d65855040bf08bb5291a87733555067041ab611cd4e874368c8c1a2c2a

111.9

Total

3,391.7

(Source: BitMEX Research)

As the above table shows, the total output value of these 25 double spent transactions is 3,391.7 BCH, an economically significant sum. Therefore, one may conclude that the re-organisation was an orchestrated event, rather than it having occurred by accident. If it occurred by accident, it is possible there would be no mismatch between the transactions on each side of the split. However, assuming coordination and a deliberate re-org is speculation on our part.

We have provided two examples of outputs which were double spent below:

Example of one of the double spent UTXOs – “0014”

(Source: BitMEX Research)

The above table illustrates what happened to a 5 BCH output during the re-organisation. The 5 BCH was first sent to address qzyj4lzdjjq0unuka59776tv4e6up23uhyk4tr2anm in block 582,698. This chain was orphaned and the same output was eventually sent to a different address, qq4whmrz4xm6ey6sgsj4umvptrpfkmd2rvk36dw97y, 7 block later.

Second example of one of the double spent UTXOs – “0020”

(Source: BitMEX Research)

What happened to the above outputs shares characteristics with almost all the funds in the 25 double spent transactions. Most of the outputs appear to have been double spent around block 582,705 on the main chain, around 7 blocks after the orphaned block.

The SigScript, used to redeem the transaction inputs, starts with “0020” or “0014”, highlighted in the above examples. These may relate to Segregated Witness. According to the specification in Segregated Witness, “0014” is pushed in P2WPKH (Pay to witness public key hash) and “0020” is pushed in P2WSH (Pay to witness script hash). Therefore the redemption of these inputs may have something to do with Segregated Witness, a Bitcoin upgrade, only part of which was adopted on Bitcoin Cash.

Indeed, based on our analysis, every single input in the 25 transactions in the orphaned block 582,698 was redeemed with a Sigscript starting “0014” or “0020”. Therefore it is possible that nobody lost funds related to this chain re-organisation, other than the “attacker” or “thief” who redeemed these SegWit outputs, which may have accidentally been sent to these outputs in the first place.

As part of the Bitcoin Cash May 2019 hardfork, there was a change to allow coins which were accidentally sent to a SegWit address, to be recovered. Therefore, this may have occurred in the incident.

Allow Segwit recovery

In the last upgrade, coins accidentally sent to Segwit P2SH addresses were made unspendable by the CLEANSTACK rule. This upgrade will make an exemption for these coins and return them to the previous situation, where they are spendable. This means that once the P2SH redeem script pre-image is revealed (for example by spending coins from the corresponding BTC address), any miner can take the coins.

(Source: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2019-05-15-upgrade.md)

It is possible that this 2 block re-organisation is unrelated to the empty block bug. However, the split appears to have occurred just one block after the resolution of the bug, therefore it may be related. Perhaps the “honest” miners were attempting to coordinate the spend of these outputs directly after the split, perhaps to return them to the original owners and the empty block bug messed up their timing, allowing the attacker to benefit and sweep the funds.

On the other hand, the attack is quite complex, therefore the attacker is likely to have a high degree of sophistication and needed to engage in extensive planning. Therefore, it is also possible this attack may have been effective even without the empty block bug.

Conclusion

There are many lessons to learn from the events surrounding the Bitcoin Cash hardfork upgrade. A hardfork appears to provide an opportunity for malicious actors to attack and create uncertainty and therefore careful planning and coordination of a hardfork is important. On the other hand, this empty block bug, which may be the root cause of the other 2 incidents, could have occurred at any time and trying to prevent bugs like this is critical whether one is attempting to harfork or not.

Another key lesson from these events is the need for transparency. During the incidents it was difficult to know what developers were planning, the nature of the bugs, or which chain the miners were supporting. Open communication in public channels about these issues could have been more helpful. In particular, many were unaware of an apparent plan developers and miners had to coordinate and recover lost funds sent to SegWit addresses. It may have been helpful if this plan was debated and discussed in the community more beforehand, as well as during the apparent deliberate and coordinated re-organisation. Assuming of course if there was time to disclose the latter. It may also be helpful if those involved disclose the details about these events after the fact.

The largest concern from all of this, in our view, is the deliberate and coordinated re-organisation. From one side of the argument, the funds were stolen, therefore the actions were justified in returning the funds to their “rightful owners”, even if it caused some short term disruption. However, the cash like transaction finality is seen by many, or perhaps by some, as the only unique characteristic of these blockchain systems. The ability to reverse transactions, and in this case economically significant transactions, undermines the whole premise of the system. Such behavior can remove incentives to appropriately secure funds and set a precedent or change expectations, making further reversals more likely.

For all those in the Bitcoin community who dislike Bitcoin Cash, this could be seen as an opportunity to laugh at the coin. However, although Bitcoin Cash has a much lower hashrate than Bitcoin, making this reversal easier, the success of this economically significant orchestrated transaction reversal on Bitcoin Cash is not positive news for Bitcoin in our view. In some ways, these incidents contribute to setting a dangerous precedent. It shows that it may be possible in Bitcoin. Alternatively, this could just illustrate the risks Bitcoin Cash faces while being the minority chain.