Trade the new Stellar contracts at BitMEX and you could win up to $25K

BitMEX is thrilled to announce a new $100K lottery giveaway for Stellar (XLMF18) contracts! To win one of the 15 lottery prizes, simply trade the new Stellar contract on BitMEX to collect tickets. Even with just one ticket, you have the chance to win the grand prize of $25K.

Start: Wednesday, Jan 17 2018 00:00 AM UTC
End: Friday, Jan 26 2018 12:00 PM UTC

Prizes:

1 Grand Prize of $25K USD
1 Second Prize of $10K USD
13 Third Prizes: $5K USD

Rules:

  • Any trader who trades 5,000 Stellar contracts earns a lottery ticket. Each trader can earn up to 10 lottery tickets.
  • Bonus tickets: any trader who trades a total volume of one million or more Stellar contracts receives an extra 10 lottery tickets, for a total of 20 lottery tickets.
  • Each lottery ticket has an equal chance of winning one of the fifteen prizes.
  • A trader cannot win more than one prize.

It’s simple to participate:

Cheers,
The BitMEX Team

Terms & Conditions:

  1.     BitMEX reserves the right to cancel or amend the giveaway or giveaway rules at our sole discretion.
  2.     Users who engage in market manipulation will be excluded from the contest. This determination will be made at the sole discretion of BitMEX.
  3.     Winner will be notified via email on Jan 31st 2018.
  4.     All awards are paid out in Bitcoin at the prevailing price of the .BXBT index at Jan 26th 2018 12:00PM UTC.

BitMEX Wishes You a Happy New Year with a $100K Giveaway!

 

Happy New Year! To celebrate, BitMEX is giving away $100K in prizes. To win, simply trade the new Cardano (ADAF18) contract on BitMEX, and you could win a grand prize of up to $50K. Even with just one trade, you could win one of five randomly selected $5K prizes!

Start: Monday, Jan 08 2018 08:00 AM UTC
End: Monday, Jan 15 2018 11:59 PM UTC

Prize Details
Volume Winner $50K The trader who trades the largest amount of Cardano (ADAF18) contracts will receive $50K USD.
Profit Winner $25K The trader who has the largest profit (in XBT) from trading the Cardano (ADAF18) contract will receive $25K USD.
Lucky $5K (5 winners) 5 x $5K Any trader who trades at least one Cardano (ADAF18) contract enters a random draw to win one of the five $5K USD prizes.

It’s simple to participate:

Cheers,

The BitMEX Team


Terms & Conditions:

  1.     BitMEX reserves the right to cancel or amend the giveaway or giveaway rules at our sole discretion.
  2.     Users who engage in market manipulation will be excluded from the contest. This determination will be made at the sole discretion of BitMEX.
  3.     Profit is defined as realized profit (in XBT terms) of all trades where the trade was opened and closed during the contest period window.
  4.     No user can win more than one prize. 
  5.     Winner will be notified via email on Jan 17 2018.
  6.     All awards are paid out in Bitcoin at the prevailing price of the .BXBT index at Jan 15 2018 11:59PM UTC.

Bitcoin Cash Sale Summary

BitMEX completed the sale of all Bitcoin Cash (BCH) held on behalf of our users. Bitcoin Cash sale details:

  • The amount of Bitcoin Cash a user is entitled to is determined by their Margin Balance at 1 August 2017 13:17 UTC, a few seconds after block 478,588.
  • Bitcoin Cash to Bitcoin (XBT) Ratio: 1 BCH to 0.1707 XBT
  • Users’ BitMEX Bitcoin wallets will be credited with the amount of Bitcoin they are entitled to.

The Insurance Fund was credited with 120.5321631 XBT due to its holdings of Bitcoin Cash.

A Complete History of Bitcoin’s Consensus Forks

Abstract: In this piece we list 19 Bitcoin consensus rule changes (or 18 as an accidental one “failed”), which represents what we believe to be almost every significant such event in Bitcoin’s history.  At least three of these incidents resulted in an identifiable chainsplit, lasting approximately 51, 24 and 6 blocks, in 2010, 2013 and 2015, respectively.

 

Source: gryb25

 

Terminology

Term Definition
 Chainsplit A split in the blockchain, resulting in two separate chains, with a common ancestor.  This can be caused by either a hardfork, a softfork or neither.
 Consensus rule changes
 Hardfork

A loosening of the consensus rules on block validity, such that some blocks previously considered as invalid are now considered valid.

Existing nodes are required to upgrade to follow the new hardforked chain.

 Softfork

A tightening of the consensus rules on block validity, such that some blocks previously considered as valid are now considered invalid.

Existing nodes do not necessarily need to upgrade to follow the new softforked chain.

Note: These terms are believed to have originated in April 2012 and formalized in BIP99 and BIP123

 

List of Bitcoin consensus forks

Date Activation Block Number BIP Number or Software Version Description Type Outcome
28 July 2010 n/a1 0.3.5 OP_RETURN disabled.  Fixing a critical bug which enabled anyone to spend any Bitcoin Softfork No evidence of any issues during this upgrade
31 July 2010 n/a1 0.3.6 OP_VER and OP_VERIF disabled3 Softfork Some users had trouble upgrading and it was recommended that nodes should be shutdown if they could not be upgraded2
The addition of the OP_NOP functions, although perhaps there was no usage of OP_NOP prior to this point Hardfork
01 Aug 2010  n/a1 0.3.7 Separation of the evaluation of the scriptSig and scriptPubKey.  Fixing a critical bug which enabled anyone to spend any Bitcoin Potentially a non-deterministic hardfork No evidence of any issues during this upgrade
15 Aug 2010 74,638 0.3.10 Output value overflow bug fix following a 184.5 billion Bitcoin spend incident.  The 0.5BTC which was the input to the transaction remains unspent to this day. Softfork A chainsplit occurred.  Around 5 hours after the incident, a fix was released, client 0.3.10. It is believed that 51 blocks were generated on the “bad chain” before the “good” chain re-took the PoW lead
Disabling OP_CAT, which removed a DoS vector, along with the disabling of 14 other functions Softfork
07 Sept 2010 n/a1 0.3.12 Adding the 20,000 signature operation limit, in an incorrect way.  This incorrect limit still exists today. Softfork No evidence of any issues during this upgrade
12 Sept 2010 79,400 n/a

Adding the 1MB blocksize limit.

The “MAX_BLOCK_SIZE = 1000000” commit occurred on 15 July 2010, which was released in the 0.3.1 rc1 version of the software on 19 July 2010.  The commit enforcing the 1MB rule occurred on 7 September 2010, activating at block 79,400.  On 20 September 2010, Satoshi removed this activation logic, but kept the 1MB limit.

Softfork No evidence of any issues during this upgrade
15 March 2012 171,193 BIP30 Disallow transactions with the same TXID, unless the older one was fully spent. In September 2012 the rule was applied to all blocks, apart 91,842 and 91,880, which violate the rule Softfork This was a flag day softfork, there is no evidence of any issues
1 April 2012 173,805 BIP16 Pay to Script Hash (P2SH) – This allows transactions to be sent to a script hash (address starting with 3) instead of a public key hash (addresses starting with 1) Softfork 55% activation threshold, over blocks in the 7 days prior to 1 February 2012. Miners did not upgrade fast enough, so the evaluation point was delayed until 15 March.  Users running 0.6.0rc1 who did not upgrade for the delay, activated the softfork early and got stuck on block 170,060 when an invalid transaction according to their nodes was mined.  After activation problems were then caused by the remaining 45% of miners producing invalid blocks for several months after the softfork
24 Mar 2013  227,835 BIP34 Requires the coinbase transaction to include the block height Softfork 95% activation threshold. A successful rollout occurred
11 Mar 2013 225,430 0.8.0 This was an unplanned hardfork caused by the migration from Berkeley DB to LevelDB, which accidentally removed an unknown 10,000 BDB database lock limit.  This caused a chainsplit which occurred on 11 March 2013, although the software which caused the error was released 20 days earlier on 20 February 2013. The change was reverted as the Bitcoin economy and miners switched back to 0.7.2 rules No change in the consensus rules occurred A chainsplit of at least 24 blocks occurred, with the 0.8.0 chain having a maximum lead of 13 blocks. A successful double spend also occurred. The original rules chain eventually re-took the PoW lead
18 Mar 2013 n/a1 0.8.1 This was a temporary softfork, introducing a new rule requiring that no more than 4,500 TXIDs are referenced by inputs in a block, this rule is stricter  than the 10,000 BDB lock limit.  The rule expired on 15 May 2013, a flag day hardfork. Softfork There is no evidence of any issues
15 May 2013 or 16 Aug 2013  252,451 or earlier BIP50 In August 2013 a block may have been produced which violated the original 10,000 BDB lock limit rule, which was relaxed on 15 May 2013. Hardfork There is no evidence of any issues
04 July 2015  363,731 BIP66 Strict DER Signature – This upgrade means Bitcoin is no longer dependent on OpenSSL’s signature parsing Softfork 95% threshold over a 1,000 block period. A chainsplit occurred, lasting 6 blocks, as some miners signaled support for BIP66 but had not upgraded and were SPY mining.  The new softfork rules chain eventually took the lead.
14 Dec 2015  388,380 BIP65 Check Lock Time Verify – This enables funds to be locked until a specific time in the future.  This is Bitcoin’s first new function Softfork Successful rollout using a 95% threshold
04 July 2016  419,328 BIP68
BIP112
BIP113

Relative lock time

Remove the incentive to use a future timestamp to grab transaction
Median past time

Softfork Successful rollout using 95% versionbits signaling
23 July 2017   477,800 BIP91 This temporary softfork makes signaling for the SegWit upgrade mandatory Softfork Softfork successfully activated with an 80% miner threshold over a 336 block period, although only a tiny minority of users enforced BIP91 rules, which have since expired.  Therefore the risk of a chainsplit was elevated in this period.
01 Aug 2017  478,479 BIP148 This temporary softfork makes signaling for the SegWit upgrade mandatory for a two week period following 1 August 2017 Softfork Flag day softfork appeared to succeed with no issues, although only a minority of users enforced BIP148 rules, which have since expired. Therefore the risk of a chainsplit was elevated in this period.
24 Aug 2017  481,824 BIP141
BIP143
BIP147
The Segregated Witness upgrade Softfork Rollout using 95% versionbits signaling
The year 2262  13,440,000 BIP42 Fixed a 21 million coin supply cap bug.  The software was upgraded in April 2014 to fix this bug, however the new rule does not apply until the 23rd century. Softfork The softfork is not applicable yet

Sources: BitMEX Research, Github, Bitcoin Blockchain

Notes:

  1. With the exception of the 1MB blocksize limit, prior to the 2012 BIP16 softfork, there was no activation methodology, therefore if the fork occurred smoothly without a chainsplit, there is not necessarily a specific block height or date on which the consensus fork occurred.
  2. “If you can’t upgrade to 0.3.6 right away, it’s best to shut down your Bitcoin node until you do” – Satoshi Nakamoto (Source)
  3. Prior to the removal of OP_VER, each software upgrade could potentially be considered as a non-deterministic hardfork and these have been excluded from this list.  Although if the definition of hardforks include this, then its a somewhat pedantic definition.
  4. There are no consistent definitions used in the above table, because for example, a different definition of the date on which the fork occurred may be more relevant in each incident, depending on the circumstances.
  5. Others have also mentioned that changes to the P2P protocol can also be considered hardforks, if they make previous software releases unusable since they can no longer connect to the network.  However, strictly speaking these do not relax the rules on block validity, and one could sync old nodes by setting up a relay of intermediary versions of the software.  These changes are excluded from the above list.
  6. Some consider BIP90 as a hardfork, however since it only relaxed rules related to softfork activations which happened in the past, it does not share many of the characteristics or risks normally related to consensus forks.  Using the same logic, the block checkpoint scheme can also be considered softforks.
  7. In July 2010 the chain selection rule was altered to shift to most accumulated work from the number of blocks. Technically this is not a change to block validity rules, however this change does share some of the risks associated with consensus rule changes.

 

Was the 2013 incident a hardfork?

In our view, on balance, the increase in the BDB lock limit, a few months after the 11 March 2013 chainfork, was a hardfork.  The rule in question was a 10,000 BDB lock limit, which was increased. The rule was relaxed on 15 May 2013 in the sofware version 0.8.1, which was released on 18 March 2013.  A block exceeding this limit may finally have been produced on 16 August 2013.  Therefore the date of the hardfork could either be 15 May 2013 or 16 August 2013, depending on how you define it.

Although some have argued that this may not have been a hardfork, for a variety of reasons, including that this rule was “quasi-non-deterministic” or that one could manually change the BDB config settings.  Indeed, due to the non-deterministic nature of the lock limit, perhaps it is theoretically possible one could have a local system setup, such that the old BDB lock limit has never been breached.  Therefore, one could declare that there has “never been a hardfork” in Bitcoin, due to a very strict definition, requiring a hardfork to be deterministic or perhaps even directly related to Bitcoin data such as transactions or the block header.

When discussing this incident, Bitcoin developer Gregory Maxwell said the following:

Sort of a mixed bag there, you can actually take a pre BIP-50 node and fully sync the blockchain, I last did this with 0.3.24 a few months ago. It just will not reliably handle reorgs involving large blocks unless you change the BDB config too. So it’s debatable if this is a hard fork either, since it’s quasi-non-deterministic. There were prior bugs fixed where older versions would get stuck and stop syncing the chain before that too… So I think by a really strong definition of creating a blockchain which violates the rules mandated by prior versions we have never had a hardfork.

Source: https://bitcointalk.org/index.php?topic=702755.msg8116032#msg8116032

 

Chainsplit incident of July 2015

In the above list of consensus rules changes, there are three incidents which caused identifiable chainsplits.  The most recent of there occurred on 4 July 2015, during the BIP66 softfork upgrade.

Immediately after the activation of BIP66 there was a 6 block orphan chain created because a miner produced an invalid block that was not recognised as invalid by some other mining pools, because they were not validating new blocks.

In this case some miners were signaling support for BIP66 soft fork but hadn’t actually upgraded their nodes to validate, one could say miners were “false flagging”. If the miners had been validating blocks, they would have discovered the block was invalid and rejected it, however some miners built on top of the invalid block and a chainsplit occurred.

A diagram illustrating these 6 blocks and the chainfork is displayed below.

 

Graphical illustration of July 2015 chainsplit

Source: Blockchain.info (http://archive.is/WqGRphttp://archive.is/LHlF7)

 

Disclaimer

Whilst many claims made in this piece are cited, we do not guarantee accuracy.  We may have made errors or accidentally omitted consensus rule changes from the list.  We welcome corrections.

 

Note

After the publication of this piece, an alternative list of consensus versions was published on the Bitcoin Wiki.

XBTH18, The Main Event

The launch of the new Bitcoin quarterly contract is always an exciting time. The basis or lack thereof points to trader excitement or apathy. As Bitcoin nears $20,000 and with the CBOE and CME now on board, the basis gyrations of the BitMEX Bitcoin / USD 30 March 2018 futures will fascinate traders.

The leading factor in the basis movements will be the CBOE and more so the CME Bitcoin futures contracts.

The CME contract launches Monday morning Asia time. As a betting man, I predict the basis will move up and to the right in an aggressive fashion. This will carry XBTH18 basis higher as well. Therefore for those who cannot trade the CME contract, using XBTH18 is a great way to play the most anticipated launch of a crypto related product to date.

Strategy 1: Bullish on price and basis

For those who believe the price and basis will rise together, go long XBTH18. This the highest risk strategy I will propose, but also has the largest profit potential.

Strategy 2: Bullish on price and basis, but delta neutral

For those who do not want to run naked Bitcoin delta, go long XBTH18 vs. short XBTUSD. You make money on basis expansion via the long XBTH18 position. If the price and futures basis are rising, the XBTUSD swap will also trade at a premium. That means that as a short, you will receive funding.

This strategy is predicated on your view that the price will rise. The FOMO will invite buyers to pay a premium for the 100x leverage. This is what drives the futures basis and swap funding higher.

Strategy 3: Bullish on basis, and delta neutral

This strategy is for those who believe that buyers will exert extreme pressure on the CME futures basis, but are not exactly sure whether the price will go up or down.

Traders should go long XBTH18 and short spot Bitcoin. This trade only makes money if the XBTH18 basis increases.

Timing

Bitcoin moves are exaggerated over weekends when flat cash ceases to travel between exchanges. The FOMO before the CME launch will be legendary, thus it behooves traders to put these trades on as early as possible.

You don’t want to wake up Saturday morning, after a Volar session, to the XBTH18 basis trading a few percentage points higher. The time to buy is now.

Bitcoin Gold (BTG) – Investment flow data

Abstract: A few weeks ago, we published a piece on Bitcoin Cash and how one can analyse transaction data on the two blockchains involved in the split, to try to draw conclusions about the potential investment flows between the two chains. In this piece we provide a similar analysis, with respect to Bitcoin Gold (BTG).

 

Bitcoin Gold overview

Bitcoin Gold (BTG) is a Bitcoin chainsplit token, similar to Bitcoin Cash. Anyone who held Bitcoin on block 491,406, (which occurred on 24th October 2017) was allocated an identical amount of Bitcoin Gold. Some exchanges allowed customers to trade their Bitcoin Gold from this date, based on customer balances at the time of the fork. However, the Bitcoin Gold blockchain itself, did not appear to become usable until 14 November 2017, 21 days after the snapshot point.

The aim of Bitcoin Gold appears to be to improve mining centralization, by switching the hashing algorithm to Equihash from SHA256, which is currently more GPU-friendly than the ASIC-dominated SHA256.

 

Allocation of Bitcoin Gold to the coin founders

Although the Bitcoin Gold project team does not always appear to want to make this fact well-known, 100,000 coins were created and then allocated to the Bitcoin Gold team members. This consists of the block reward for 8,000 blocks, which with a block reward of 12.5 BTG, amounts to 100,000 coins.

Based on the current spot price of Bitcoin Gold of US$450 per coin, this balance is worth approximately US$45 million. In the eyes of many, this seemingly unnecessary allocation is likely to damage the integrity of Bitcoin Gold. Bitcoin Cash, for example, did not have such an allocation. One could argue that Bitcoin Cash’s initial difficulty adjustment mechanism also allowed an unusually large number of coins to be created in the initial period following the fork, although this seems somewhat fairer than what Bitcoin Gold did, as anyone could have mined the Bitcoin Cash tokens and they were not directly allocated.

 

Total coins spent

As at 20th December 2017, 2.61 million Bitcoin Gold tokens have been spent at least once. This compares to 4.7 million and 2.4 million Bitcoin spent, since the snapshot point and the point at which Bitcoin Gold transactions became possible, respectively. This also compares to 4.1 million Bitcoin Cash, which was spent after an equivalent number of days following the Bitcoin Cash fork point.

The 2.61 million Bitcoin Gold which has been spent represents c15.8% of all the Bitcoin Gold. In our view, this is likely to be related to the level of divestment from Bitcoin Gold, mainly because this 2.61 million coin figure is higher than a comparable first time spend in Bitcoin over the same period.

 

Figure 1 – Bitcoin Gold (BTG) vs Bitcoin (BTC) – Number of coins spent at least once since the chain split compared to the BTG price – million

Source: BitMEX research, Bitcoin blockchain, Bitcoin Gold blockchain, Bitfinex (Price data)

 

Daily Bitcoin Cash spend for the first time

The average daily spend for the first time on Bitcoin Gold is falling slightly, compared to the initial period after the launch. In the last 10 days the average daily spend for the first time was 44,000, compared to around 110,000 in the first 10 days.

 

Figure 2 – Bitcoin Gold coins spent for the first time since the split (daily millions) compared to the BTG price

Source: BitMEX research, Bitcoin Gold blockchain, Bitfinex (Price data)

 

Security Incident

For a 4.5 day period, from 21 November 2017 to 25 November 2017, the official Bitcoin Gold Github repository may have been hacked, and the official website pointed to a malicious wallet. According to an announcement from the Bitcoin Gold team, the malicious wallet allowed the malicious entity to access funds sent to new Bitcoin Gold addresses provided by the wallet, and therefore Bitcoin was not affected, as existing private keys were not compromised. It is not clear exactly what happened, but the Bitcoin Gold team claims that at least 80 BTG were stolen. Given the severity of this incident, the impact could have been far worse, in our view.

This illustrates why it’s important to handle these new fork tokens with caution. In particular, we would strongly advise you not to import your Bitcoin private key into these new fork token wallets, without first spending the Bitcoin to a new output with a different private key associated with it, after the token snapshot point, so that your Bitcoin is not at risk.