Launch of Bitcoin Futures Trading Crashes CBOE Site (thestreet.com)

"5PM CT is the start of Bitcoin futures trading and the $CBOE website appears to be down," one market watcher posted on Twitter (and his observation was quickly confirmed by other cryptocurrency-watching accounts and confirmed by CBOE). "I'm guessing watching Bitcoin futures start trading is a more popular spectator sport than anticipated."

Bitcoin futures will also begin trading on the Chicago Mercantile Exchange in eight days. The Street report that the anticipation of that "has triggered wild swings in bitcoin prices over the last week." Overall, trading bitcoin futures is a positive development for the cryptocurrency says the research team at Fundstrat... The introduction of derivatives lays the necessary market structure for institutions to allocate cash towards cryptocurrencies, points out Fundstrat... Short sellers may now express negative views on bitcoin, which could lead to short-term pricing pressure. But the ability for short sellers to hate on bitcoin could be viewed as a longer term positive, Fundstrat says. Shorting essentially creates true price discovery and means that hedge funds could take bitcoin more seriously. This should improve the long-term prospects of bitcoin as it broadens sponsorship, Fundstrat believes.

Comments

Close

[Orgasmatron]

Not all shorts help with price discovery. Covered shorts do, but naked shorts are just plain fraud, no matter what excuses the clearinghouses come up with.

Re:Future issues? Scalability?

[ChumpusRex2003]

Yes. There are several problems.

The first, and most fundamental is that blockchain technology is inherently non-scalable. It is, effectively an ultra-redundant database system, operating on diverse hardware, in diverse regions, and which has a monotonically growing, non-prunable dataset. It is estimated that there are around 100k nodes in the bitcoin network maintaining a copy of the dataset, and participating in peer-to-peer replication. The total quantity of storage required for each database entry and the network traffic to replicate it are non-negligible.

The proximate problem is an artificial limit on transaction capacity implemented several years ago. At present, the system is designed so that the dataset cannot grow by more than 1 MB every 10 minutes. This limit was put in place to avoid spam attacks resulting in a DDOS of the network. There is a non-trivial computational cost to validate each entry cryptographically. Even my quad core i7 CPU can take 10-15 seconds to validate a 1 MB database update message. Lesser nodes, like ARM devices which wish to maintain a full copy of the dataset may need to dedicate 10-25% of CPU time just to handling incoming updates (i.e. each message incoming at 600 second intervals may require 60-150 seconds of CPU time).

The problem is that demand for transactions exceeds the hard limit. As a result, there is a queue of pending transactions, which currently stands at about 200 MB (or about 30 hours), with transactions removed from the queue in order of the amount they wish to pay as fees. This has led to spiralling fees as users try to outbid each other, in order to have their transactions accepted. Transactions with low fees have recently been timing out after 2 weeks in the queue and have been discarded unprocessed.

There has been an attempt to increase the transaction limit. However, because the bitcoin system is decentralised and based on consensus, such an upgrade would require 100% participation. Anyone that fails to upgrade would find their software completely broken, possibly silently so, such that they could spend bitcoins, but they would not be received, with no warning to this effect. A very complex solution has been developed which permits an increase in the limit with backwards compatibility (as well as fixing some minor security bugs), but as yet the reference node implementation has no GUI or meaningful CLI/API access to it; the network and accounting implementation is fully featured, but there is no practical way to use it, short of developing your own transaction bitstream generator, using some sort of middleware or a 3rd party library with its own low-level API, or a non-reference implementation of the software. As a result, use of this new format has been very limited, and only about 10% of the achievable capacity uplift has been realised.

This has seriously fractured the community. The incumbent developers take the view that the inherent inscalability of the blockchain concept means that development efforts should be focused on layered solutions. Transactions in the main bitcoin blockchain should be large value clearing transactions, which serve to aggregate large numbers of lower value transactions made at a second layer, with potentially microtransactions at a 3rd layer begin aggregated into 2nd layer transactions. Additionally, breaking changes should be avoided unless there is no other credible option, as not all participants run the reference code, and some may have made custom modifications which may require significant development time to implement new mandatory features.

Other groups have taken the view that convenience and capacity available immediately are more important, and have proposed breaking changes. One group, calling themselves bitcoin cash, changed the transaction limit to an 8 MB soft limit, based upon the a configuration option settable in the node options, hence the network can be upgraded to a larger capacity, simply by the majority of participants increasing the soft limit on the