Stellar Giveaway winners announcement

Thanks to all of the participants for helping to make the giveaway a success, and congratulations to all the winners! Please see the email you received for prize details.

A total of 1,993 participants entered the giveaway with a total of 4,403 tickets earned.

All 15 lucky winners were selected randomly from the 4,403 tickets. Any trader, big or small, can win a lucky draw, so make sure your name is in the hat for our upcoming giveaways.

To see the giveaway details, click here.

*Trader has agreed to show his/her real username in the winner announcement.

Wishing you a prosperous 2018!

The BitMEX Team




The art of making softforks: Protection by policy rule

Abstract: In this article, following on from our piece on the history of consensus forks, guest writer Dr. Johnson Lau explains the distinction between policy rules and consensus forks. He explains why it may be safer to introduce new softforks when the proposed rule is already covered by policy rules (non-standard behaviour), as this may mitigate or reduce some of the risks normally associated with changing the consensus rules.

(Source: gryb25)

Softforks are the primary way to fix and introduce new Bitcoin consensus rules. The following series of articles will describe how Bitcoin softforks are engineered.

Consensus rules and softforks

Consensus rules determine whether a transaction or a block is valid or not. Every user and miner on the Bitcoin network is expected to adhere to the same set of consensus rules, so they will all agree to a single ledger.

A softfork is an event when the majority of users and/or miners decide to adopt a stricter set of consensus rules, which makes some previously valid transactions/blocks invalid, but not the opposite. If the majority enforces the new rule set, any violating fork would (statistically) never catch up to the stricter fork in terms of total proof of work. The minority with the old rules set will always follow the longer and stricter fork, so everyone on the network would still agree to a single ledger.

Policy rules and consensus rules

While consensus rules are the only criteria for determining transaction validity, relaying or mining nodes may prefer some kinds of transactions over others. For example:

  • As spam control, transactions with very low fees or “sand outputs” (outputs with very low value) are rejected.
  • Some miners refused to include “on-chain casino” transactions, considering them spammy.
  • Transactions with an unknown version are rejected (currently only version 1 and 2 are “known”).
  • Transactions with exotic scripts (i.e., not P2PKH, P2SH, v0 segwit, or a few other cases) and unknown NOPx codes (currently only OP_NOP2 and OP_NOP3 are known) are rejected.
  • “Replace by fee” and “child pay for parent” are also policy rules, as they determine which transactions are preferred by miners.

By definition, policy rules MUST be at least as strict as consensus rules. Obviously, no miners would like to include invalid transactions in a block (which will lead to a loss of mining reward) or to relay them (which will get them banned by peers).

While policy rules could be stricter than consensus rules, it is important to note that policy rules do not determine the validity of transactions. Once a transaction is included in a valid block, all network nodes will accept it even if it violates some policy rules.

It is also important to note that policy rules are local, while consensus rules are universal. That means different network nodes might have different policy rules but they will still agree to the same blockchain ledger as long as they are running the same consensus rules.

Transactions that violate a policy rule are sometimes called “non-standard transactions”, distinguishing them from “invalid transactions”.

Policy rules and softforks

Ideally, all miners should have upgraded to the new, stricter rule sets on or before the activation of a softfork. Financially, they have a strong incentive to do this, as mining an invalid block (in terms of the new rules) would lead to significant monetary loss. However, in a decentralized system like Bitcoin, this is not guaranteed.

Although miners are expected to pay attention to any proposed rule changes and take timely action, miners who build invalid blockchain might lead to market disruption and monetary loss for ordinary users. Therefore, any well-planned softforks should bear this in mind and minimize the risks.

The trick is to make a softfork only if it is covered by existing, widely adopted policy rules. Miners with the policy rules who are unaware of the new consensus rules would refuse to include such transactions by default, so they would never include transactions that are invalid in terms of the new consensus rules. Some cases in Bitcoin history illustrate this.

A worker is adding a “Road Closed” sign to a route that is not being used due to an obstruction that existed before the sign was placed. The new traffic rules only prevent behaviour that was already “non-standard” and disruption is therefore minimal.

Case Study Description
BIP65: Check lock-time verify OP_NOP1 to OP_NOP10 originally had no meaning in the Bitcoin script language. While they are counted as one operation (there is a limitation of 201 operations in a script), practically, they are skipped during transaction validation. However, a policy rule has been included in Bitcoin Core since version 0.10 to reject OP_NOPx by default. BIP65 is a softfork introduced in Bitcoin Core 0.12 to redefine OP_NOP2 as OP_CHECKLOCKTIMEVERIFY (OP_CLTV). OP_CLTV checks if the top stack value is greater than the transaction’s nLockTime field (along with a few more conditions). If any of the conditions are matched, the transaction is considered as invalid. Otherwise, OP_CLTV is skipped like OP_NOP2.

New nodes would always enforce the new consensus rules after softfork activation. Yet even before the softfork was activated, the original OP_NOP2 policy rule was replaced by the OP_CLTV rules (which is okay, since OP_CLTV rules are stricter than the original OP_NOP2 consensus rules).

Legacy mining nodes would not perform the nLockTime check. However, as long as they were running version 0.10 or above, the default OP_NOP2 policy rule would prevent them from including ANY transactions with OP_CLTV, valid or not. As a result, legacy mining nodes of 0.10 or above would never actively produce an invalid block with respect to the new OP_CLTV consensus rules.

BIP68: Relative lock-time using sequence numbers nSequence is a field in Bitcoin transactions, which was essentially unused. The idea of BIP68 was to use the nSequence field for the purpose of relative lock-time, which is a very important building block of advanced transactions such as payment channels and the Lightning NetworkHowever, the nSequence field has been ignored since the very first version of Bitcoin, and miners would accept any transaction with any nSequence value. There was no policy rule governing nSequence value, therefore a safe softfork could not be done as simply as OP_CLTV.

The trick was to use the transaction-version field (nVersion). Since version 0.7, non-version-1 transactions are rejected by a policy rule. To leverage this, BIP68 requires that the new rules for nSequence are enforced ONLY if the transaction version is 2 or above (or below 0, to be precise). Therefore, legacy mining nodes would not produce any BIP68-violating block, since they won’t include any non-version-1 transactions by default.

An attacker could not “turn off” BIP68 by simply changing the transaction version, since the version is covered by signature. This is also the only instance in which the transaction version is associated with consensus rules.

BIP141: Segregated witness Segregated witness (segwit) is a softfork to fix transaction malleability by redefining a certain script pattern. In BIP141, the pattern is an output script (or P2SH redeemscript) which starts with a single OP_x (x = 0 to 16), followed by a canonical data push between 2 and 40 bytes. However, this is not what it was originally proposed. In the first draft, the witness-program pattern was a single push between 2 and 41 bytes.

A policy has been implemented since v0.6 to reject transactions that spend exotic scripts (i.e. not P2PKH, P2SH, and a few more types). The first draft of the witness program was indeed non-standard in this regards.

The problem is with the witness program when wrapped in P2SH. Before v0.10, the policy rules would also reject any exotic P2SH scripts. This rule was greatly relaxed in v0.10, and the original witness-program design was not covered.

A few alternative proposals were considered:

  • A new transaction nVersion (like BIP68) does not work. If the new consensus rule is “segwit rules are enforced only if nVersion is larger than 2”, an attacker could steal all money stored in segwit outputs by changing the nVersion (since the nVersion is covered only by the segwit signature, which is not checked when nVersion is 2 or below).
  • An OP_NOPx might be used to label a witness program. However, this would make all witness programs 1 byte bigger, and also occupy the limited OP_NOPx space.

The final version made use of the so-called “clean stack” policy rule from BIP62. Although BIP62 is now withdrawn, its rules are still enforced as policy. “Clean stack” requires that script evaluation must end with one and only one stack item. The final witness-program design, however, leaves two item on the stack. This is valid by consensus but violates “clean stack” policy.

Failing example: BIP16 and pay-to-script hash (P2SH) BIP16 was the first planned softfork on Bitcoin. It was activated when 55% of hash power signalled readiness (compared with the 80% to 95% currently in use). Before P2SH was introduced, there was no policy rule for checking the form of spending output. As a result, a significant number of miners kept creating invalid blocks, occasionally long chains, months after softfork activation.
Failing example: Segregated witness on Litecoin Not long after the Bitcoin segwit implementation was finalized, Litecoin started to integrate the segwit code. However, while segwit was released in Bitcoin Core 0.13.1, the last Litecoin version at that time was 0.10.4, which did not include the “clean stack” rule. Litecoin developers tried to fix the problem by adding an extra consensus rule to segwit that required the block version to be at least 0x20000000, hoping that would force miners to upgrade. It turned out that all miners upgraded right before the activation (with the last large miner upgrading a few hours before), and no fork was created due to the lack of “clean stack” in the last release.

Should a large mining pool have failed to upgrade at the last minute, the extra-block version rule would have provided little or no protection. This will be discussed in a future article.

Policy protection is not a panacea

At this point, a reader might find that the policy-protection trick described above would only prevent un-upgraded miners from actively making the first invalid block after softfork activation. However, should such an invalid block be somehow created, un-upgraded miners would still accept it and extend such a blockchain if it had more proof of work. So this is a way to only reduce but not eliminate the chance of an accidental chain split at softfork activation. This issue is also particularly problematic if a significant number of miners are using different full-node implementations, which might not have the same policy rules.

Dr. Johnson Lau, Bitcoin Protocol Developer

CC BY-SA 4.0

BitMEX Stellar Giveaway leaderboard 25 January 2018

Check your user name here:

Or follow these steps:

  1. Go to the BitMEX platform.
  2. Click on Contracts from top menu bar.
  3. Click on Leaderboard from left navigation bar.

As a reminder, 15 randomly selected Stellar contract traders will be rewarded one of the 15 prizes:

1 Grand Prize of 25,000 USD
1 Second Prize of 10,000 USD
13 Third Prizes of 5,000 USD

Good luck to all participants!

The BitMEX Team

BitMEX Stellar Giveaway leaderboard 24 January 2018

Check your user name here:

Or follow these steps:

  1. Go to the BitMEX platform.
  2. Click on Contracts from top menu bar.
  3. Click on Leaderboard from left navigation bar.

As a reminder, 15 randomly selected Stellar contract traders will be rewarded one of the 15 prizes:

1 Grand Prize of 25,000 USD
1 Second Prize of 10,000 USD
13 Third Prizes of 5,000 USD

Good luck to all participants!

The BitMEX Team

The Lightning Network

Abstract: In this piece, we explain the motivation behind the creation of the Lightning Network and why its scaling characteristics are superior to what we have today, potentially resulting in a transformational improvement. We describe some of the basic technical building blocks that make Lightning possible. We then examine some of its limitations, including the downsides of inferior security compared to transacting on-chain and why this makes Lightning potentially unsuitable for larger-value payments.


The motivation behind the Lightning Network

Blockchain-based payment systems typically work in a “broadcast to everyone” mode, in that when one makes a payment, one needs to broadcast the transaction to all participants in the network.

Nodes in such a system must:

  • store the transaction indefinitely,
  • verify the transaction, and
  • relay the transaction.

Miners, meanwhile, are required to engage in an energy-intensive competitive process to determine if the transaction makes it into the ledger, just in case a conflicting transaction occurs.

There isn’t even special treatment for the recipient of the payment. For example, if one buys a coffee using Bitcoin, the transaction is broadcast to the entire Bitcoin network without prioritising propagation of the transaction data to the coffee shop or the coffee shop’s payment processor. Many consider this process to be inefficient. If the objective is to build a payment system used by millions of people across the globe, this method does not seem logical.

The old “broadcast to everyone” announcement method at sporting events, during Arsenal’s 3-3 draw at home to Sheffield Wednesday in May 2000. Prior to the widespread adoption of mobile phones, stadium announcers broadcast messages for individuals over the public-address system to all those in attendance. Mobile phones have made this process faster and more efficient, as messages can be sent directly to the intended recipient.

The Lightning Network represents an improvement in efficiency and uses a more logical payment-network structure. Instead of broadcasting a transaction to everyone, the transaction can be sent more directly to the payment recipient. Only when parties to the transaction are dishonest does one need to resort to the cumbersome process, which distributed censorship-resistant systems require to maintain consensus. In this way, one can achieve performance and efficiency almost equivalent to that of direct communication between the parties over the Internet, while retaining some of the security characteristics of Bitcoin’s blockchain.

However, building such a payment system, in which all parties can always revert to the blockchain and reclaim their funds if there is a problem, is complex and has some significant risks and limitations.

Lightning’s basic technical building blocks

Unidirectional micropayment channel. (Source: BitMEX Research)

The diagram above depicts the traditional way to set up a basic unidirectional payment channel. Although setting up the channel involves broadcasting a transaction to everyone, once the channel is set up, multiple payments from Bob to Alice can occur by simply sending data from Bob to Alice, avoiding a broadcast to the entire network. The payment process can be repeated again and again until the funds in the channel, in this case 1 BTC, have been exhausted.

In theory, the above channel is secure for the following reasons:

  • If Bob tries to renege on his payment, all Alice needs to do is sign and broadcast to the network transaction P1, which Bob signed when he initially made the payment. As long as this gets confirmed before the one-week locktime in transaction B, Alice safety receives her 0.1 BTC regardless of what Bob does.
  • If Alice refuses to sign anything in order to frustrate Bob, all Bob needs to do is wait one week for transaction B to become valid, and he is then able to move the money from the channel to himself by broadcasting transaction B, which Alice has already signed.

This process is more secure if transaction A cannot be malleated by a third party (the TXID changing), otherwise Bob could have created transaction B only for it to become invalid as transaction A changes, thereby enabling Alice to hold the funds hostage indefinitely.

According to an e-mail that Satoshi sent to Bitcoin developer Mike Hearn, this basic structure was Satoshi’s idea:

One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement.  The party giving money would be the first to sign the next version.  If one party stops agreeing to changes, then the last state will be recorded at nLockTime.  If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out.  Intermediate transactions do not need to be broadcast.  Only the final outcome gets recorded by the network.  Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.


How the Lightning Network actually works

This micropayment construction can be considered the core building block for the Lightning Network, which is essentially a network of these payment-channel-like constructions. Payments find a path along channels which are already directly connected to each other until they reach the final recipient.

The channel construction used in Lightning builds on this basic structure with more advanced and complex technologies. The above construction is unidirectional, while in order to be useful, payments need to be made in both directions. For example, one can think of making payment channels bidirectional by constructing two channels between Alice and Bob, each in the opposite direction. More precisely, Lightning uses Poon-Dryja channel construction. This has lower liquidity requirements than simply setting up a network of unidirectional payment channels in opposite directions, which would require twice the amount of funds to be locked up inside the channel. However, Poon-Dryja channel construction has significant weaknesses compared to the other approach. Poon-Dryja channels require each party to sign a new transaction every time the channel is updated (a payment is made) while a unidirectional channel only requires the sender to sign when the channel is updated.

The old locktime feature can be replaced with more advanced functions:

  • Check locktime verify (BIP65) can prove that the output cannot be spent until a certain date rather than ensuring a particular spend of the output is invalid until a certain date, which is what locktime does.
  • Relative locktime (BIP68) can replace a specific end date with a date relative to the corresponding output. This can allow payment channels to remain open for indefinite periods, with a closure transaction triggering a time window during which the other party has a finite period of time (e.g., two weeks) to broadcast their reclaim transaction and recover the funds.
  • Hashed timelock contracts (HTLC) can require the receiver of a payment to provide a string that hashes to a certain value by a certain date or returns the funds to the payer. This same hash can be used to trigger other payments in the channel network, enabling payments to be made across a chain of channels.

The resulting Lightning Network and its advantages

The Lightning Network should then, in theory, allow all participants in the network to make near instant and cheap transactions in all directions by finding a path among the nodes. This therefore avoids broadcasts to the Bitcoin network, as long as there are no problems, and results in a scalable network. The architecture even allows microtransactions and improves the privacy of payments.

Channels can stay open indefinitely due to the relative-locktime feature and there should be no counterparty risk; if anyone tries to steal funds through a hostile channel closure, the other participants to the transaction will have a significant time window in which to issue their own redemption transaction and get their money back.

Network functionality and user experience

A big unknown is how people and businesses will actually use the network, and commentators have different visions. Some see the Lightning Network as eventually being ubiquitous for small payments, with complexities handled in an automated way. Others more sceptical of Lightning typically envision the various components of the network requiring more of a manual construction when the system is used and a poor user experience plagued by unexpected channel closures and periods of Lightning Network downtime.

Sceptical view of Lightning Ambitious view of Lightning
Channel setup In order to set up a Lightning channel, a user must manually create a new expensive on-chain transaction. Setting up a Lightning channel will be a seamless process built into existing wallets and systems. When receiving a payment or purchasing Bitcoin, the funds need to go somewhere. Funds could immediately go into a Lightning channel as they are received and therefore setting up the channel requires no additional steps or costs.
Channel closure Once the payment is complete, one needs to close the channel, with a manually created, expensive on-chain transaction. There may be no need to close the channel and users can keep their wallet funds in channels indefinitely or for long periods of time.
Network routing Routing is likely to be a significant problem, since finding a short path between parties is a difficult problem to solve algorithmically. If no route is found, the user and merchant will have to engage in the cumbersome process of selecting an on-chain transaction by manually changing the payment process.

1. The existing P2P network already requires a network topology and the relaying of messages, with nodes typically having eight connections. The Lightning Network topology is simply an extension of that.

2. Routing is not a significant problem, since even in massive networks the average number of steps in a path between users is small.

3. Even if there is a problem with routing, a payment could simply be made on-chain without the user even noticing the difference.

4. A small number of large channel operators can prevent routing problems.

Centralisation of payment channels The network will centralise around a few large hubs as this is the most efficient model. This centralisation increases the risk of systemic channel failure, which is when a few large channels fail, resulting in a simultaneous mass exodus from payment channels and on-chain congestion, ensuring that some are unable to exit the channels before expiry.

Economic incentives act against centralisation; anyone can set up a node as there are low barriers of entry. In addition, there is an incentive to undercut other nodes by charging lower fees.

Even if the network does centralise around a few large hubs, the Lightning Network still provides a useful and interesting system. Bitcoin already has a few large entities such as Coinbase that take custody of a large amount of funds.

Under Lightning, the entities do not have custody of funds and merely act to relay data used for payments.

Liquidity Payment channels will have insufficient liquidity and therefore the scope of payments will be limited. Payments of any reasonable size can almost instantly drain the liquidity of an entire channel, such that Lightning payments will need to be suspended. Users will be incentivised to run Lightning nodes and provide liquidity in order to receive fees. The network will be used for small payments, far smaller in value than the maximum channel capacity, ensuring sufficient liquidity.
Requirement to be online when receiving a payment With an on-chain transaction, all a sender needs is a payment address to make a payment; the recipient does not need to be online. In contrast to this, as explained above, a recipient in Lightning will need to sign a reclaim transaction before receiving a payment. This significant limitation means that recipients are required to keep their private keys exposed in a hot wallet. This makes Lightning impractical in many scenarios, such as making high-value payments, at ATMs, at in store PoS systems, or paying those with limited Internet connectivity. Although a recipient is required to be online to receive a payment, this does not result in significantly different dynamics to most on-chain payments, since if the recipient is not online, they don’t know about or cannot verify the payment anyway. It is also not necessary that the user or device directly receiving the payment needs to store the private keys. For example, an in-store PoS terminal or a crypto ATM machine could receive the signed redemption transaction over the Internet from the firm’s HQ prior to receiving payments, communication that is necessary when making payments anyway.
Potential requirement to monitor the channel Lightning Network participants may be required to monitor payment channels and then take action by a certain deadline in order to safeguard their funds. For example, a hostile reclaim transaction could trigger the start of a period in which the other party must also issue a reclaim transaction to protect their funds, before a certain deadline. This is a significant burden on users. Channels do not need to be monitored at all times, as this depends on the window provided by the relative locktime. Channel-monitoring services (watchtowers) could mitigate this risk by monitoring channels on behalf of users: these services could either warn users in the event of a hostile reclaim transaction or could issue reclaim transactions themselves, if they were pre-signed and supplied beforehand by the users.

In reality, the truth may lie somewhere between these two visions, with the network potentially moving to the more ambitious vision over time. What this disagreement appears to come down to is that Lightning sceptics see it as a complex, incomplete, and impractical payment system based on the channel-construction system alone. Proponents see Lightning more as a scalable building block for a second layer on top of Bitcoin’s blockchain, which will eventually be supplemented by wallets, payment protocol systems. and channel-servicing companies, resulting in a simple and seamless user experience. Ultimately, wallets may be able to communicate with each other and then automatically, dynamically decide which payment methodology is best, on-chain or the most practical method via Lightning, without the user even knowing or caring.

The increased security risks of Lightning

  • Requirement to be online when receiving a payment: As explained above, before receiving a payment, the recipient needs to sign a reclaim transaction so that the sender knows they can reclaim their funds in the event of hostile channel closure or a refusal to sign. Therefore, to receive money requires a hot wallet, meaning that private keys are potentially exposed if a security incident occurs.
  • Requirement to monitor the channel: Lightning Network participants or watchtowers may be required to actively monitor the payment channels. This could place a burden on users or watchtowers and potentially reduces the security of funds inside a channel relative to Bitcoin stored on-chain. There is a risk of missing a reclaim-transaction deadline, either due to a failure to appropriately monitor the channel or perhaps because of on-chain network congestion.
  • Miners could censor channel-closing transactions: 51% of the hashrate may have the ability to steal funds from Lightning users by censoring a channel-closure transaction, in which the miner is the other party. Although the potential consequences of this type of attack are already devastating without Lightning, the Lightning Network potentially offers hostile miners a slightly larger attack surface.

While each of these three factors alone may not be significant, the need to potentially expose one’s private keys to the Internet when receiving payments, the risk of a hostile channel closure, and the risk of miners censoring channel-redemption transactions combined result in significantly inferior security — although all these risks can be managed to some extent.

There is a risk that lazy or poorly informed users keep too much money in a channel and funds are lost or stolen due to one of these failure scenarios. There is also the risk that price volatility results in users keeping more funds in payment channels than they would otherwise have intended.


The Lightning Network does appear to potentially offer significant and transformational improvements with respect to scalability. As a result, transaction speeds and transaction fee rates should dramatically improve, without impacting the underlying security of the core protocol. Crucially, however, the inferior security properties of Lightning payments may make the Lightning Network unsuitable for larger payments (or, at least, it may be irresponsible to use it for larger payments). Speculation and investment flows, which require these larger payments, currently appear to be the major driving force in the cryptocurrency space, with the volume of retail payments being relatively small in comparison. Because of that, Lightning may not be as big a game changer as some imagine, at least in the medium term. While enthusiasts appear likely to adopt this technology quickly, widespread adoption may take considerable time.

BitMEX Stellar Giveaway leaderboard 23 January 2018

Check your user name here:

Or follow these steps:

  1. Go to the BitMEX platform.
  2. Click on Contracts from top menu bar.
  3. Click on Leaderboard from left navigation bar.

As a reminder, 15 randomly selected Stellar contract traders will be rewarded one of the 15 prizes:

1 Grand Prize of 25,000 USD
1 Second Prize of 10,000 USD
13 Third Prizes of 5,000 USD

Good luck to all participants!

The BitMEX Team

Bitcoin ain’t a stock

The most common criticism of Bitcoin is that it has no intrinsic value. That is entirely true, but neither does the US dollar or a bar of gold. These same critics then begin to buttress their argument by comparing Bitcoin’s market cap against the equity value of some large blue-chip companies. Surely Bitcoin is in a bubble if it is worth $250 billion and company X is worth slightly less.

A share of stock in a company is the net present value of all future dividends, which implies that stocks have intrinsic value. It is intellectually lazy to compare Bitcoin, which possesses no income stream, against a stock that does.

This leads me to believe that most financial journalists do not fundamentally understand any of the financial assets they write about daily. The mischaracterisation of Bitcoin and its value proposition further illustrates their ignorance.

The second facet of Bitcoin in the market that pains me is that many people don’t understand exchange rates. If Bitcoin has no intrinsic value, its value comes from the market’s perception of its moneyness — which means that Bitcoin has a price only versus another asset, crypto coin, or fiat currency. Therefore, either Bitcoin can be in a bubble now or the asset it is valued against was previously.

Take the above weekly log graph of the Bitstamp USD/Bitcoin price since 2012. Viewing this chart would lead you to believe that the dollar was in a bubble, which then burst. Hard-money folks have been labelled modern-day Cassandras because the hyperinflationary fiat doomsday collapse has yet to manifest itself. The inflation, which government statistics expertly conceal, rears its ugly head through crypto-coin pumps and Hong Kong cage homes worth millions of USD.

My pet peeves do not prove that Bitcoin deserves its current market-clearing price against fiat currencies. Rather, if one wants to dismiss Bitcoin as a fad for the young’uns and financially stupid, the arguments used must make financial sense.


January historically has been a great month to pick up cheap Bitcoin. Over the past five years, Bitcoin has turned bearish during this month and has, eventually, recovered from its drop (although it took a little longer in 2014 and 2015).

Creative traders who believe that Bitcoin will indeed again recover from this current market slump can look at ways to increase their alpha while holding Bitcoin using BitMEX products.

At the time of writing, XBTH18 and XBTM18 are trading at $100 and $800 premiums over a spot price of $10,950, which translate to 4.6% and 16.5% annualised premiums, respectively.

Historically, the basis on the fixed-date products trade on average around 25% to 30% annualised basis levels and thus these trades could be an extremely cheap way to pick up cheap Bitcoin.

For example, consider if the basis reverts back to its historical average immediately at the current price levels: we should see a premium on XBTH18 and XBTM18 of $640 and $1,450 respectively.

Hence, a trader looking to BTFD on Bitcoin, who believes that the basis should revert to its historical average, could then see additional gains of $540 to $650 on the fixed-date products. Happy trading!

XBT/USD curve structure

Due to the increased liquidity on BitMEX’s Bitcoin/USD contracts, a six-month fixed-date contract can finally be listed! This new contract is XBTM18, and it expires 29 June 2018. Now we have the beginnings of a Bitcoin/USD contract-interest-rate term structure. Valuable insights can be gleaned into the market’s perception of the future value of Bitcoin from the premium or discount of these contracts.

The above chart illustrates the annualised percentage premium of XBTH18 (March 2018) and XBTM18 (June 2018) on 4 January 2018 and 16 January 2018.

Looking at the 4 January observations, I am immediately struck by how flat the curve is. Given the explosive Bitcoin price volatility in December, I would expect XBTM18 to trade significantly lower or higher than XBTH18 in annualised percentage terms.

If we time-travel back to 4 January, I would advise one of two strategies:

Bullish: Sell XBTH18 vs. buy XBTM18

If you believe that the price of Bitcoin will rise, this is a price-neutral way to express that view. Why not just go naked long? If your prognosis is incorrect, your absolute losses will be much less using a 3m versus 6m basis trade.

If the spot price were to continue upwards over the next few weeks, XBTM18 would outperform XBTH18. That is due to traders purchasing the long end of the curve in anticipation of much higher prices come June. This outperformance manifests itself by the XBTM18 annualised premium rising much higher than XBTH18’s.

Bearish: Buy XBTH18 vs. sell XBTM18

If you believe the price of Bitcoin will fall, this is a price-neutral way to express that view. Again, in case you are wrong, you want to limit the absolute losses via a basis trade.

If the spot price were to continue downwards over the next few weeks, XBTM18 would underperform XBTH18. That is due to traders selling the long end of the curve in anticipation of much lower prices come June.

What actually happened

Spot prices fell, and the curve parallel-shifted lower. In addition, XBTM18 underperformed XBTH18 over the 12-day time period.

In annualised percentage terms on 4 January and 16 January, XBTM18 was 0.59% and 1.92% cheaper than XBTH18, respectively. The change in average spot price between both days was down 8.19%. The XBTM18 basis held up quite well, all things considered.

That indicates that there is a strong bid under XBTM18. The market does not expect the Bitcoin spot armageddon to continue into the summer. Or, said another way, hope springs eternal. And hope plus 100x leverage is a strong cocktail.

Trade idea: Sell XBTH18 vs. buy XBTM18

This bout of weaker prices allows an excellent entry point into this trade. If you believe the price will soon test $10,000 and maybe $8,000, wait for the dip. During the despair, traders will short the bottom and push the whole curve close to flat premium. If the market is super bearish, XBTM18 might even trade at a discount. Then you back up the truck, and go all in.

Otherwise, the current curve structure still affords an excellent entry point. My base case is that the curve will parallel-shift upwards to an annualised 40%, and XBTM18 will move to flat vs. XBTH18. In the bullish case, XBTM18’s premium will continue to outperform and hit 50% to 60% annualised.

Daily theta

Theta is the daily income earned or lost due to the passage of time:

theta = (outright % premium) / (days until expiry)

For the trade described above, you earn theta by being short XBTH18 and pay theta by being long XBTM18. This is because both contracts trade at a premium. Currently the net theta is +0.0053% per day. A positive theta means the trade pays for itself. Said another way, the trade has positive carry.

One caveat: your positive XBTH18 theta position evaporates in 73 days once it expires. The clock is ticking. The trade must move into your favour before XBTH18 expires. If you roll into another 3m versus 6m calendar spread in late March, the levels may not be attractive and/or you may lock in a loss.

Ode to speculators

As a good friend of mine says, “Everyone hates bankers until it’s time to pay the bill.”

The same can be said for crypto speculators. The common rejoinder amongst those who wish they were crypto rich, but who are too scared or lazy to jump in, is that crypto won’t last because the only use case is speculation.

It is true that the number-one use case for crypto is speculation. However, without these unwashed speculators, would anyone outside of a few technologists really care a fig about this industry?

Building infrastructure

What makes a coin valuable? At a fundamental level, most coins need some sort of usage. A coin with a dedicated community is able to attract users and talented developers to improve the protocol. The technology ideally will be useful, but that depends on the quality of work produced.

But if you are a developer, how do you decide which project to devote your time to? If you are a user, how do you first hear about a new coin or project?

Forums, IRC, Twitter, and eventually traditional technology-focused media outlets are the first to pick up on new trends. It is difficult to find a worthy project while wading through the Internet sewer of questionable content. The eureka moment occurs not when just one person discovers something new and useful, but when a group of like-minded folks are moving in the same direction on the path to enlightenment.

That is the slow approach. The faster and more popular approach is to use some objective measure to determine whether a group of people believe in a new coin or project a priori. The best objective measure is a market-determined price. One of the best facets of this industry is that most projects possess a tradable asset. The price, traded volume, and market cap reflect the market’s judgement of the value of a project.

When a price goes up and to the right, that validates those already working on the project. It also creates a desire for others to join the revolution for fear of missing out. This positive feedback loop lays a solid foundation for a project to scale and possibly realise its vision.

Fake news

Think back to how you first heard about Bitcoin. For me, it was a Zero Hedge article about how the price had shot up, to a then all-time high of $250 in April 2013. The sharp price rise intrigued me and prompted my further investigation. Only then did I read Satoshi’s white paper and become a believer.

I imagine that most readers have a similar story. The mainstream media’s most popular stories usually deal with someone making a lot of money in a short period of time. In our hyper-competitive and fast-paced world, everyone is trying to spot the next thing. They too want to discover the next Netscape, Google, Amazon, and Facebook. You too can sell books, give TED talks, go to Burning Man, and wear a puffy vest that shows off your mega biceps in your 50s.

Most people learned about Bitcoin through the media. Back in 2013, any major news outlet writing a story about Bitcoin could send the price up or down, depending on the content. Developers and punters use media outlets to determine what new skills to learn, and which new assets to HODL.

The media needs a constant stream of volatility for them to continue to write about an asset class. That is why you rarely see articles about the intricacies of the bond markets. It is boring because the volatility is low. Equities, however, are sexy. They have stories, and their prices at times move violently on new developments.

The media now loves crypto because the coins move. There is a constant flow of news. There are outrageous personalities who lead projects and own large stashes of coins. The crypto industry appeals to the emotions and greed of the public, and a new euphoria is palpable — a euphoria that central banks and regulators destroyed in the traditional asset markets.

Ode to speculators

Developers, users, and investors all depend on a horde of uncouth speculators to create a liquid market for crypto coins. I say uncouth, because many financial outlets regard retail investors as stupid. Retail investors don’t work at white-shoe investment banks, wear formal business costume, or read The Economist for pleasure on the weekend. Yet, the craze is led by these hooligans.

A new class of millionaires and billionaires were created from a stock of undesirables. The memes, language, and behaviour of many of the leading figures have no place at large banks and technology firms. But these people speculated that crypto could change the world.

Of course, the financial media and vaunted figures such as Jamie Dimon would pooh-pooh crypto as a cesspool filled with retail speculators. It would be unimaginable for them to endorse a market they don’t understand. However, there is also a disturbing trend of disdain toward said speculators even among even those who grew famous within the industry because they contributed to an asset class that has grown by hundreds of billions of dollars in one year.

Rather than complaining about the wild gyrations of the crypto markets, a more appropriate response is to express gratitude that crypto isn’t as boring as the S&P 500.

But what are they used for?

Bitcoin is the most mature crypto coin, and it is less than a decade old. Many of the coins that people love to hate are less than one year old. In another decade, it might be appropriate to ask, “Where’s the beef?”

Right now as a trader or HODLer. you want as much volatility as possible. That drives more smart engineers into the industry, more users to interact with the technology, more crypto media articles, and liquidity from new retail punters.

BitMEX Stellar Giveaway leaderboard 18 January 2018

Check your username here:

Or follow these steps:

  1. Go to the BitMEX platform.
  2. Click on Contracts in the top menu bar.
  3. Click on Leaderboard from the left navigation bar.

As a reminder, 15 randomly selected Stellar contract traders will be rewarded one of the 15 prizes:

1 Grand Prize of $25,000 US
1 Second Prize of $10,000 US
13 Third Prize of $5,000 US

Good luck to all participants!

The BitMEX Team