On 27 June 2019, we set a new record for crypto: >$1B open interest on XBTUSD, >$13B traded on XBTUSD, >$16B on all BitMEX products. Yet, Nouriel Roubini still believes that cryptocurrencies are a farce. Watch him face-to-face next week in Taipei’s Asia Blockchain Summit vs our CEO, Arthur Hayes.
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)
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
iShares Core U.S. Aggregate Bond ETF (AGG)
The Libra Association/Facebook
Bank deposits and government securities in currencies from stable and reputable central banks
Fixed income – Investment grade government and corporate bonds
Bloomberg Barclays U.S. Aggregate Bond Index
The Libra Association, based in Switzerland will manage the reserve. The investment mandate is not currently disclosed. The current members are as follows:
PayU (Naspers’ fintech arm)
Union Square Ventures
Creative Destruction Lab,
Women’s World Banking
James Mauro and Scott Radell, with a clear constrained mandate to track the index
Use of investment income
Unit holders are not entitled to investment incomeInvestment 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
The Libra Association
will encourage the listing of Libra on multiple regulated electronic exchanges throughout the world
Creation/redemption basket size
Authorized Participants (entities able to create and redeem units)
Authorized resellers, not currently disclosed
Information about holdings and Net Asset value (NAV)
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:
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
iShares Core U.S. Aggregate Bond ETF (AGG)
Not applicable (An ETF does not require a consensus system)
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
The Libra Blockchain is pseudonymous and allows users to hold one or more addresses that are not linked to their real-world identity
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.
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.
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.
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.
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:
Customers can no longer disable login notification emails. The login notification emails will now be sent regardless of existing notification preferences.
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:
Password reuse, or use of trivially guessed passwords on the BitMEX platform and on customer personal email accounts.
Compromised personal email accounts leading to account theft via password recovery flows.
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:
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.
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!
Assess your existing risk
Check to see if your password has been leaked in a third-party breach via services like HIBP.
Check your trading accounts on a regular basis to ensure that you know what the balances are or should be.
Regular reconciliation of your accounts would be a useful way for you to ensure all transactions in your accounts are with your authorisation.
Add email@example.com to your contacts list and ensure our emails are not landing in your SPAM folder
Ensure that you are not filtering official communications from bitmex.com. These communications include login and withdrawal notifications.
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.
The scheduled system update has successfully concluded. The BitMEX platform is now back to full functionality. The update was performed from 01:00 UTC to 02:58 UTC today, 04 June 2019. No trading activity was affected.
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
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.
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.
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.
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
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.
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.
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.