Bitcoin’s Initial Block Download

Abstract: We test the performance of Bitcoin Core by successfully conducting 35 initial block downloads (IBDs) and recording the amount of time the node takes to synchronize with the network. We used software releases in the period spanning from 2012 to 2019. The results show a considerable and consistent improvement in the performance of the software, but also a high degree of variance. Even with the latest computer hardware, older versions of Bitcoin struggled to get past the pickup in transaction volume which occured in the 2015 to 2016 period. Therefore we conclude that without the software enhancements, an initial synchronization today could be almost impossible.

Figure 1 – Bitcoin Initial Block Download Time (Days) – Average Of 3 Attempts

(Source: BitMEX Research)
(Notes: Synchronization up to block 602,707. Further details in the notes below)

Overview

To test the performance of Bitcoin Core during the initial synchronization, we successfully conducted 35 initial block downloads (IBDs) and recorded the amount of time each attempt took. The results are shown in Figure 1 above and illustrate that there was a significant improvement in speed when Bitcoin Core 0.12.0 was released in February 2016, due to the upgrade from OpenSSL to libsecp256k1 for signature verification. Libsecp256k1 was built specifically for Bitcoin. Since then, the improvements in speed were much slower and due to the high variance in IBD times, the improvements are only clearly visible after multiple attempts. However, even after Bitcoin Core 0.12.0 was released in February 2016, a small gradual improvement in performance is still visible after each software release from Bitcoin Core 0.13.0 to Bitcoin Core 0.19.0.1.

Of course, IBD time is only one metric, and there are plenty of other angles and considerations that one can use to evaluate the performance and capabilities of Bitcoin Core. While the IBD time may not be the perfect or complete measure of overall software performance, it is highly resource-intensive and therefore potentially a good metric to benchmark.

This report follows on from two previous experiments: 

  • In November 2018 Jameson Lopp conducted a similar exercise, however that analysis focused on independent implementations, while this analysis focuses on older versions of Bitcoin Core (or just “Bitcoin”, as some of the older software pre-dates the name “Bitcoin Core”). 
  • Sjors Provoost also conducted this experiment in July 2017, although Sjors provided data for fewer synchronization attempts.

Full Results and Raw Data

Figure 2 – Bitcoin Initial Block Download Time (Days)

(Source: BitMEX Research)
(Notes: Synchronization up to block 602,707, further details in the notes below)

System Specification & Other Notes

 
MacBook Pro (64 bit)
Linux VPS (64 bit)
OS
macOS Mojave (10.14)
Ubuntu 18.04.3
Processor
6 Core Intel i9 2.9GHz 
8 Core Intel Xeon
Memory
32GB
32GB
Storage
1 TB Flash Storage
640GB Flash Storage
Internet Downstream Bandwidth
62Mb/s
2,000Mb/s
Internet Upstream Bandwidth
20Mb/s
400Mb/s
IBD ended at height
602,707
602,707
Bitcoin.conf settings
assumevalid=0
dbcache=24000
maxmempool=500

Full Table of Results

Client Client release date
Sync Time (Hours)
Machine
Bitcoin Core 0.19.0.1
24/11/2019
11.4
MacBook Pro
Bitcoin Core 0.18.1
20/07/2019
10.4
MacBook Pro
Bitcoin Core 0.17.0
03/10/2018
17.7
MacBook Pro
Bitcoin Core 0.16.0
28/02/2018
18.5
MacBook Pro
Bitcoin Core 0.15.0
14/07/2017
21.1
MacBook Pro
Bitcoin Core 0.14.0
08/03/2017
16.4
MacBook Pro
Bitcoin Core 0.13.0
17/08/2016
24.7
MacBook Pro
Bitcoin Core 0.12.0
17/02/2016
15.8
MacBook Pro
Bitcoin Core 0.11.2
10/11/2015
53.3
MacBook Pro
Bitcoin Core 0.10.0
12/02/2015
81.2
MacBook Pro
Bitcoin Core 0.9.0
18/03/2014
85.1
MacBook Pro
Bitcoin Core 0.8.6
09/12/2013
Abandoned
MacBook Pro
Bitcoin Core 0.19.0.1
24/11/2019
13.6
Linux
Bitcoin Core 0.18.1
20/07/2019
15.9
Linux
Bitcoin Core 0.17.0
03/10/2018
13.3
Linux
Bitcoin Core 0.16.0
28/02/2018
18.8
Linux
Bitcoin Core 0.15.0
14/07/2017
17.9
Linux
Bitcoin Core 0.14.0
08/03/2017
25.1
Linux
Bitcoin Core 0.13.0
17/08/2016
15.8
Linux
Bitcoin Core 0.12.0
17/02/2016
14.8
Linux
Bitcoin Core 0.11.2
10/11/2015
46.0
Linux
Bitcoin Core 0.10.0
12/02/2015
77.2
Linux
Bitcoin Core 0.9.0
18/03/2014
78.9
Linux
Bitcoin Core 0.8.6
09/12/2013
98.5
Linux
Bitcoin Core 0.19.0.1
24/11/2019
14.0
Linux
Bitcoin Core 0.18.1
20/07/2019
13.7
Linux
Bitcoin Core 0.17.0
03/10/2018
16.0
Linux
Bitcoin Core 0.16.0
28/02/2018
18.2
Linux
Bitcoin Core 0.15.0
14/07/2017
17.9
Linux
Bitcoin Core 0.14.0
08/03/2017
17.0
Linux
Bitcoin Core 0.13.0
17/08/2016
21.9
Linux
Bitcoin Core 0.12.0
17/02/2016
17.1
Linux
Bitcoin Core 0.11.2
10/11/2015
44.1
Linux
Bitcoin Core 0.10.0
12/02/2015
82.2
Linux
Bitcoin Core 0.9.0
18/03/2014
82.1
Linux
Bitcoin Core 0.8.6
09/12/2013
72.6
Linux

(Source: BitMEX Research)

Analysis of the Results

As Figure 2 above illustrates, even when conducting the IBD with the same software and with a machine with the same specification, there is considerable variance in the reported times. 

Figure 3 – IBD time vs Client Release Date (Days) – Average Time of 3 Attempts

(Source: BitMEX Research)
(Note: For the Bitcoin 0.8.6 client, the results above are an average of only 2 attempts)

Figure 3 above indicates that the performance of the software improved incrementally with each software release, with the exception of the strong performance of Bitcoin Core 0.12.0. However, despite the apparent clear trend in the above chart, the large variance and in IBD times on each attempt could indicate there is considerable uncertainty. One may need more sample data before drawing strong conclusions about improvements in performance since 2016. It is possible the variation is primarily caused by issues in the Bitcoin P2P network or the internet connection and therefore a good area of further study may be to compare the re-scan speed, the time taken to fully verify the blockchain once it has already been downloaded.

Bitcoin Core 0.12.0 performs well in the above analysis. This may be because Bitcoin Core 0.12.0 has libsecp256k enabled, but does not validate signatures for transaction inputs where the witness is segregated (Segregated Witness). Therefore Bitcoin Core 0.12.0 does not validate all the signatures in the blockchain post August 2017, giving the client somewhat of an “unfair advantage”. However this advantage may also apply to Bitcoin Core 0.13.0, despite this node not appearing to be an outlier. Of course all the versions prior to Bitcoin Core 0.12.0 have that same “unfair” advantage, but this is dwarfed by the disadvantages of using OpenSSL.

Syncing The Client Up To Its Release Date

The below chart (Figure 4) illustrates the time it takes to synchronize a client, up until the block height on the date the software was released.

Figure 4 – IBD Time Up To Client Release Date (Days)

(Source: BitMEX Research)
(Note: Data for the nodes running on Linux only. Bitcoin Core 0.19.0.1 only synced up to height 602,707)

The chart shows that the trend was reasonably flat from Bitcoin Core 0.8.6 to Bitcoin Core 0.14.0, at that point the scalability improvements could not match the impact of time progressing and the blockchain increasing in height, and the chart shows an upward trend. Unfortunately the rate of software improvement has been reduced in recent years, perhaps as the low-hanging fruit improvements have already been made. Higher transaction volume may have also contributed to this. Future scalability improvements may be a lot more challenging, and even if the 4 million unit blockweight limit is maintained, IBD times may continue to increase going forwards, despite further software upgrades and moderate increases in hardware performance.

The Failed IBD Attempts

We did successfully compile and run versions of Bitcoin prior to 0.8.6, however, the synchronization became slow when the node reached the 2015 to 2016 period. The pre-0.8.6 nodes, such as 0.7.0, did successfully get past the apparent hardfork in 2013, by manually changing the lock limit, however 2015 proved too challenging due to the increased transaction volume, and the node stopped processing blocks. We tried restarting the node, which did help push it forwards, but then it only got stuck again. We then even tried running Bitcoin Core 0.7.0 on our brand new local machine, with 64 GB of RAM and 8 Intel i9 processors, however the node was still unable to get past 2016. With many of the scaling parameters involved being non-linear, one cannot simply throw more hardware at the problem.

On occasions when the nodes got stuck on a block and we re-started, we abandoned the synchronization after 4 restart attempts. For Bitcoin Core 0.8.6 on the MacBook Pro, the synchronization was abandoned when the leading block was in 2016. Although this is slightly disappointing, no restarts were required for the remaining 35 successful synchronizations.

Conclusion

Other than the fact that the BitMEX IT department should be more cautious when issuing BitMEX Research with MacBook Pros, the data illustrates the significant scalability enhancements which have been delivered over the last seven years. The transition to libsecp256k being the most significant improvement. The large reductions in IBD times and the inability of old nodes to fully synchronize indicates that if it were not for these scalability enhancements, by now Bitcoin would be essentially dead, even if users had the highest specification hardware available. The data also shows that technological innovation is unlikely to keep up with the growing blockchain going forward and that IBD times will increase.

Benford’s Law & Cryptocurrency Trading Data

Abstract: In this report we examine Benford’s law, a mathematical rule which describes the frequency of the leading digit in various real world sequences of numbers. We look at various datasets from the cryptocurrency ecosystem, such as coin prices and trading volume data. We explain that this mathematical concept should not be looked at in isolation and that a strong understanding of the underlying economics is necessary to draw strong conclusions. We note that for a minority of trading platforms, notably OKEX and HitBTC, the reported trading volume figures appear to result in a distribution which does not follow Benford’s law. However, this pattern does not imply inappropriate manipulation of the data and there are many potential legitimate explanations for the unexpected distributions.

(Ben Affleck explaining to Anna Kendrick the abnormally high occurrence of the digit 3, potentially indicating financial fraud, in the 2016 Hollywood movie “The Accountant”. Screen captured 41 minutes and 40 seconds into the film)

Overview of Benford’s law

Benford’s law concerns the frequency distribution of the first digit from various real world sequences of numbers. One might think that the frequency distribution of the first digit in most scenarios would be 11.1% (i.e. 11.1% for 1, 11.1% for 2, 11.1% for 3, ect ) and this is indeed the case in many scenarios, for instance a random number generator should result in such a frequency distribution. However, there are some real world scenarios in physics, geology, biology, chemistry, architecture, demographics, finance, business or other fields, where a different frequency distribution is observed, one matching the chart below, where 1 is the most common (occurring 30.1% of the time), followed by 2, etc.

Frequency distribution of the first digit in an exponentially growing geometric series

(Source: BitMEX Research)
(Note: The geometric series starts at the number 1, grows by 2% each interaction and contains 5,000 numbers)

Justifying exactly why the above phenomenon is observed can be challenging and there does not appear to be a concise explanation applicable in all scenarios. The major characteristic necessary in order to observe Benford’s law appears to be that the data must span across several orders of magnitude.

In our view, good way of explaining the phenomenon is by considering a basic geometric series. For instance, consider a geometric series of numbers, growing by 10% each iteration. When the series has reached the level of 24 (40% of the way through the twenties), the next number in the series is 26.4, still well within the twenties, with 2 as the leading digit. If the geometric series is at 84 (40% of the way through the eighties), the next number in the sequence is 92.4 and the leading digit has changed from 8 to 9. This shows how some series, which could occur for instance in finance or nature, result in the observation where lower value leading digits are more common than higher value digits.

Applying Benford’s Law to Business and Finance

Before joining BitMEX Research, many of the team used to work as investment analysts or portfolio managers covering equities. Back in 2015, inspired by a paper from the Association of Certified Fraud Examiners, a colleague proposed that we could use Benford’s law as a tool to look for financial fraud in reported financial statements. The theory was that if corporate financials accurately reflected the real world, the numbers should follow Benford’s law, however if they had been nefariously manipulated or generated randomly, the numbers should deviate significantly from Benford’s law, which could be a flag for financial fraud. However, as the below scenarios illustrate, it may not be as simple as that.

Consider the following two somewhat contrived examples:

Example 1 – Analysing the sales of a high-growth American technology company – Google

The Amercian internet conglomerate Google [GOOGL US] generated sales of only around $200,000 in 1999. The company grew significantly over the last 20 years and today has sales of over $100 billion. Google’s sales therefore spanned many orders of magnitude and Benford’s law may be appropriate to analyse the group’s financial metrics.

Example 2 – Analysing the sales of a low-growth Japanese utility company – Hokkaido Electric

The Japanese hydroelectric, thermal and nuclear power generating company Hokkaido Electric Power [9509 JP] had sales Y752 billion in financial year ended March 2019. While 25 years ago, the company had sales of Y544 billion and at no point in the last 25 years did sales leave the Y500 billion to Y800 billion range. The leading digit of the company’s annual revenue figure was either 5, 6 or 7 in each of the last 25 years, certainly not following Benford’s law. This is not necessarily an indication of fraud or other financial impropriety, it may merely indicate the company’s conservative nature, low population growth in Japan, a low-growth economic backdrop and Japan’s relatively low inflation rate.

Frequency distribution of the leading digit

Leading Digit
Benford Model
Google Sales (1999 to 2019)
Hokkaido Electric Sales (1995 to 2019)
1
30.1%
33.3%
0.0%
2
17.6%
19.0%
0.0%
3
12.5%
9.5%
0.0%
4
9.7%
9.5%
0.0%
5
7.9%
4.8%
72.0%
6
6.7%
9.5%
12.0%
7
5.8%
4.8%
16.0%
8
5.1%
4.8%
0.0%
9
4.5%
4.8%
0.0%

(Source: BitMEX Research)
(Note: Google sales are in US$ while Hokkaido Electric’s sales are in Japanese yen)

The purpose of the above examples is to illustrate that one cannot blindly apply Benford’s Law to financial analysis. In order to conduct this analysis effectively, one may need both a strong understanding of mathematics and the underlying economics of the businesses in question. In our view, infering stong conclusions about the operations of financial markets based on statistical or mathematical analysis, without a strong enough understanding of the assumptions and principles behind the mathematics and how they apply to finance, is a mistake made too often, particularly by macro economists and econometricians. We are keen not to repeat this error in this report.

When we analysed our equity portfolios using Benford’s law, we were able to detect that stocks in certain sectors, such as technology, biotech or commodities often followed Benford’s law, while the picture was more mixed when looking at more stable sectors like food, utilities, retail or construction. When conducting a basic analysis of stocks, its possible Benford’s law is more a measure of volatility or growth than of any nefarious manipulation of the figures.

While Benford’s law may be considered a tool to flag potential fraud, it certainly does not provide proof of it. In this report, we will not to fall into the trap of overestimating the power of Benford’s law as a method of detecting fraud when evaluating the cryptocurrency space.

Cryptocurrency Prices

Below we have applied the Benford analysis to cryptocurrency prices. In general the results show that cryptocurrency price movements do follow Benford’s law.

Frequency Distribution of the Leading Digit of Coin Daily Percentage Price Changes – 12 Months ended November 2019

(Source: BitMEX Research, Coinmarketcap)

When looking at the square root at the sum of the squared differences from the Benford model, Stellar, Bitcoin Cash and Litecoin have the highest deviation, while Ethereum and Ripple have the lowest deviation. It should be considered highly unlikely that this is evidence of price manipulation in Stellar, Bitcoin Cash and Litecoin, for several reasons:

  • All the coins follow Benford’s model reasonably closely and some deviation is expected given randomness
  • A lower deviation may simply indicate the coin price is more volatile, therefore the percentage price changes are more likely to move across orders of magnitude, 
  • One year’s worth of price data may be too short to draw appropriate conclusions (for example, the longer the time horizon for the Bitcoin price, the more closely the distribution follows Benford’s law)
  • Other factors we have not considered could be driving the deviations

Cryptocurrency Trading Platforms

After looking at the coins, we moved our analysis on to cryptocurrency trading platforms, by looking at the daily trading volume of the USD vs BTC trading pair. The results here are more interesting and the deviations are more significant. Most of the platforms in our sample set follow Benford’s distribution reasonably closely, but with a few notable exceptions such as BitForex, HitBTC and OKEX.

Frequency Distribution of the Leading Digit of Cryptocurrency trading platform daily BTC vs USD daily trading volume

(Source: BitMEX Research, Investing.com)
(Notes: Daily trading volume since 12 December 2018.)

Results Table – Frequency Distribution of the Leading Digit of Cryptocurrency trading platform daily BTC vs USD daily trading volume

(Source: BitMEX Research, Investing.com)
(Notes: Daily trading volume since 12 December 2018.)

Square root of the sum of the square differences from the Benford distribution

(Source: BitMEX Research, Investing.com)
(Notes: Daily trading volume since 12 December 2018. BTC vs USD)

While the above deviations from Benford’s law do appear significant and potentially interesting, the same caveats apply as in the coin price section of this report. Namely, the distribution could be a measure of growth or volatility, the time periods may be too short or some other factors could be driving the deviations.

Conclusion

The conclusion to this piece is certainly not that Benford’s law proves that OKEX and HitBTC fake their trading volume numbers, or even that the analysis proves that Kraken and Bittrex don’t fake their numbers. As we explained above, there are many factors which could influence how closely the numbers follow the Benford distribution, many of which can be wholly legitimate, such as whether the platform was going through a period of strong growth or was in a more stable period. CryptoCompare’s exchange review takes a more holistic approach to evaluating exchanges, far more robust than merely applying one idiosyncratic mathematical concept. However, if one is already familiar with some of the economics and trends of the cryptocurrency trading platform space, this analysis may provide useful additional information.

Announcing txstats.com

BitMEX Research and Coin Metrics are happy to announce the release of txstats.com, the successor to P2SH.info, an independent project created by Coin Metrics’ Lead Data Engineer, Antoine Le Calvez.

Bitcoin stored by P2SH address type

(Screenshot from txstats.com)

Txstats.com is a collaboration between BitMEX Research and Coin Metrics with the aim of providing in-depth, high quality and timely information about how the Bitcoin network is used.

Txstats.com provides a series of dashboards centered around a specific element of Bitcoin transactions such as:

  • P2SH transaction statistics, 
  • Multi-signature usage data,
  • SegWit transaction statistics, 
  • Lightning Network channel data,
  • OP_Return statistics, 
  • Bech32 adoption,
  • Replace by Fee usage,
  • Data related to the Block Size Debate, 
  • Fee Estimation.

BitMEX Research and Coin Metrics intend for txstats.com to be dynamic and will add more statistics to the website based on community feedback. If you would like to see a new feature added to the site please feel free to let us know by emailing us at info@coinmetrics.io or by Tweeting @BitMEXResearch

If you’d like to learn more about Coin Metrics and BitMEX Research, check out Coin Metrics’ weekly newsletter, State of the Network, and BitMEX Research’s blog.

Bitcoin Cash’s October 2019 Hashrate Volatility Increase

Abstract: We look at the recent elevated level of hashrate volatility on the Bitcoin Cash network. We note that the apparent cyclical nature of the oscillations may indicate a form of manipulation, although we found no direct evidence of such behavior. We conclude that there are no easy solutions to Bitcoin Cash’s hashrate volatility issue, on the other hand the negative impact on the usability of the coin has been marginal so far. The best course of action in the short term may be to be patient and research possible solutions, unless a particular cause becomes more apparent. 

Bitcoin Cash Hashrate Estimate- (8 hour rolling average) – PH/s

(Source: BitMEX Research)
(Notes: Eight hour periods were chosen to maximise the visual impact of the apparent hashrate oscillations. Hashrate data calculated by using the difficulty and block timestamps)

Bitcoin Cash Hashrate Volatility Concerns

Recently some have expressed concerns about the apparent unusually high level of volatility in the Bitcoin Cash hashrate, causing larger than expected variances in block times. As the above chart indicates, the volatility in hashrate appears to have picked up at around the start of October 2019. It is important to consider that we calculated the hashrate based on block times, which is a random and volatile process anyway, therefore determining if short term changes in the hashrate are random or caused by actual changes can be challenging. However, in our view the data is reasonably compelling. This volatility may have made the network marginally less reliable for payments in some periods, although its not a major issue, in our view.

For the month of October 2019 we conducted a basic analysis of Bitcoin Cash’s difficulty, block timestamps and the times in which our node received the Bitcoin Cash blocks.

As the below chart illustrates, Bitcoin Cash does indeed appear to have more volatile time gaps between blocks when compared to Bitcoin. 

Time interval between blocks – 50 block rolling average (Minutes) – October 2019

(Source: BitMEX Research)
(Notes: The x-axis is block heights for Bitcoin Cash, while Bitcoin is added for the same 29 days ending 29th October 2019
)

Not only does the Bitcoin Cash time gap between blocks appear more volatile than Bitcoin, with higher peaks and lower troughs, but it also appears to be slightly less random, with more regular peaks and troughs. There may be some form of cyclicality in the data, which might imply manipulation, although we found no direct evidence of this. On the other hand, the random nature of the data means that the chart may look cyclical, but it could be an illusion. Please note, the Bitcoin Cash difficulty is adjusted on a per block basis and therefore the adjustment algorithm should not cause such cyclicality. Please also note that a 50 block rolling period was chosen to maximize the size of the peaks and troughs, therefore the chart may exaggerate the issue slightly.

The Inconclusive Hunt For Evidence Of Causation

In the table below, we analysed the average difficulty of each block for each mining pool, by calculating the difficulty at each block height. We were trying to determine if one mining pool had been successful in some strategy aimed at achieving a lower average difficulty than its peers. The analysis was inconclusive and the unknown miner(s) achieved an average difficulty reasonably close to the total average. However, it is possible a more detailed analysis of the data could find something more interesting.

Bitcoin Cash – October 2019 Mining Pool Statistics

Mining pool

Number of Blocks Mined

Mining Share

Average Difficulty When Each Block Was Mined

Average Time Gap Between Timestamp & Our Local Clock (Minutes)

Unknown

2,260

58.5%

346,505,954,955

0.48

BTC.TOP

394

10.2%

338,181,028,080

0.37

BTC.COM

374

9.7%

356,552,266,136

0.35

Bitcoin.com

266

6.9%

351,755,694,757

0.68

ViaBTC

234

6.1%

354,652,554,749

0.40

Antpool

210

5.4%

355,272,725,567

0.38

Huobi

118

3.1%

344,651,571,915

1.00

DPOOL

6

0.2%

360,262,982,821

0.31

Total

3,862

100.0%

347,926,146,858

0.48

(Source: BitMEX Research)

We also analysed the time gaps between the block timestamps and the time our local system clock says it received the block, again looking for discrepancies between pools for evidence of manipulation. Perhaps exploiting the potential 8.3% vulnerability we mentioned in yesterday’s piece. Again, no such direct evidence was found, with the unknown pool bang on the average, with the timestamp 0.48 minutes before our system clock.

The following charts continue to look at the timestamp gap to our local clock, and compare Bitcoin and Bitcoin Cash, in an attempt to visually identify any irregularities. What they appear to indicate is that Bitcoin timestamps are on average more consistent with our local clock and the time gaps are less volatile. This may merely suggest that Bitcoin has a stronger peer-to-peer network than Bitcoin Cash, with faster block propagation, rather than any nefarious manipulation of the timestamps.

Bitcoin Cash – Average Time Gap Between Timestamp & Our Local Node Clock (Minutes) – October 2019 – (Y-axis cut to compare with Bitcoin)

(Source: BitMEX Research)

(Notes: Orange line is 50 block moving average)

Bitcoin – Average Time Gap Between Timestamp & Our Local Node Clock (Minutes) – October 2019

(Source: BitMEX Research)

(Notes: Orange line is 50 block moving average. The x-axis is the month of October 2019)

We were unable to find any evidence of timestamp manipulation or other nefarious mining strategies. Bitcoin Cash is a minority hashrate coin and therefore this is likely to make the hashrate more volatile to some extent. Perhaps the apparent cyclicality is caused by lags in automated systems designed to mine the most profitable coins or some other more benign factor.

Conclusion

Fixing the potential problems with Bitcoin Cash’s hashrate volatility may require a hardfork and the coin is already scheduled to have a hardfork upgrade in a few days time, which does not include a fix for the above issue. Any fix is likely to require considerable development work and analysis/discussion before it is rolled out. Therefore a fix is unlikely in the short term. However, the issue may not be urgent.

As for how Bitcoin Cash may consider fixing the problem, we suggest consideration of the following proposals:

  1. Merged Mining – Enabling merge mining with Bitcoin, as we explained back in November 2017, could add stability to Bitcoin Cash mining, however some in the Bitcoin Cash the community may still be unwilling to adopt this due to the somewhat unfriendly attitude towards Bitcoin. In our view, this anger will dissipate over time.
  2. Adopt Bitcoin’s Two Week Adjustment Period – Bitcoin Cash could return to Bitcoin’s fixed two week window difficulty adjustment system. This is perhaps one of the more simple solutions, although it will not completely solve the problem.
  3. Reduce block times – Bitcoin Cash could re-enable the 1MB blocksize limit and reduce the block time to around 1 minute instead, although this may not fix hashrate volatility, due to the lower block time gaps, blocks would appear reasonably regularly anyway. This strategy more directly aligns with the Bitcoin Cash community’s objective of higher onchain throughput and improved usability without waiting so long for confirmations, than blocksize limit increases would, in our view.

As of now, the elevated hashrate volatility issue does not appear urgent and has only persisted for one month. The apparent sudden increase in volatility in October 2019 remains a mystery, at least to us. However, if this continues or a particular cause becomes apparent, in our view, a fix may be necessary. 

Bitcoin’s Block Timestamp Protection Rules

Abstract: We examine two of Bitcoin’s little-known rules, designed to stop nefarious miners from manipulating the block timestamps and achieving unfairly high mining rewards. We discuss why constants such as the two-hour MAX_FUTURE_BLOCK_TIME value may have been chosen and how this value may have particular implications for Bitcoin Cash. We conclude that Bitcoin’s time protection rules appear reasonably effective, an impressive feat, considering the lack of a functioning network when the rules were implemented. 

(Source: Pexels)

Bitcoin’s Time Problem

One might think that time is not an important consideration for the Bitcoin network, since the blocks already have a sequential order, as each block references the hash of the previous block. Bitcoin blocks also contain transactions (inputs, outputs and values), a Merkle tree leading to the block header and the block hash itself, used for proof of work. On the surface this may seem sufficient for a transaction and consensus system. However, there is the matter of the difficulty adjustment – if too many miners join the network, the block times could become too fast, or if too many miners leave, the block times could become too slow, making the network unreliable. To resolve this problem, every two weeks the mining difficulty adjusts to aim for a target time between blocks of ten minutes. Unfortunately, in order to calculate the two-week period, the concept of time needs to be introduced to the blockchain and be part of the consensus system. Therefore blocks are required to contain a timestamp, and one can think of Bitcoin as the world’s first distributed electronic clock.

Block Timestamp Security Rules

When a Bitcoin block is produced there are essentially two times involved:

  1. The timestamp in the block header, put there by the miner
  2. The actual time the block was produced.

Of course, these two times should be pretty much the same. After all, surely the miners have reasonably accurate clocks and why would they lie about the time?

As it happens, there are some incentives for miners to lie about the time. For instance, nefarious miners could add a timestamp which is in the future. For example, if a block took 10 minutes to produce, miners could claim it took them 15 minutes, by adding a timestamp 5 minutes into the future. If this pattern of adding 5 minutes is continued throughout a two week difficulty adjustment period, it would look like the average block time was 15 minutes, when in reality it was shorter than this. The difficulty could then adjust downwards in the next period, increasing mining revenue due to faster block times. Of course, the problem with this approach is that the Bitcoin clock continues to move further and further out of line with the real time.

To resolve or mitigate the above issue, Bitcoin has two mechanisms to protect against miners manipulating the timestamp:

  1. Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks. The median of eleven blocks implies six blocks could be re-organised and time would still not move backwards, which one can argue is reasonably consistent with the example, provided in Meni Rosenfeld’s 2012 paper, that six confirmations are necessary to decrease the probability of success below 0.1%, for an attacker with 10% of the network hashrate.
  2. Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard. It should be noted that unlike the MPT rule above, this is not a full consensus rule. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.

Rule number one ensures that the blockchain continues to move forwards in time and rule number two ensures that the chain does not move too far forwards. These time protection rules are not perfect, for example miners could still move the timestamps forward by producing timestamps in the future, within a two week period, however the impact of this would be limited.

As the above ratio illustrates, since two hours is only a small fraction of two weeks, the impact this manipulation has on network reliability and mining profitability may be limited. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 54 seconds, in the two weeks after the difficulty adjustment. In addition to this, it is only a one-off change, as once the two-hour time shift has occurred, it cannot occur again, without first going backwards. At the same time, the miner may want to include a margin of safety before shifting forwards two hours, to reduce the risk of the block being rejected by the network.

These rules have proven reasonably effective in preventing miners from manipulating Bitcoin’s timestamps in nefarious ways, as far as we can tell.

Bitcoin Cash’s Theoretical Block Time Problems

As we first mentioned back in September 2017, Bitcoin Cash is an alternative coin which split off from Bitcoin in August 2017, the primary objective of the coin was to increase the blocksize limit. One of the concerns the Bitcoin Cash developers had at the time was that not many miners would mine Bitcoin Cash, and therefore the time gap between blocks could be too large. As a result something called the Emergency Difficulty Adjustment (EDA) was implemented to alleviate this concern. We will not go into the details here, but suffice to say this mechanism was highly complex and turned out to be fundamentally flawed. This algorithm meant that if a certain number of blocks were not found within a certain time period, the difficulty would reduce. The policy was particularly aggressive, as it meant that the longer the time gaps between blocks, the larger the downward difficulty adjustment. Miners manipulated the network by leaving large time gaps on purpose, resulting in large difficulty changes, followed by low-difficulty periods with blocks being produced at a very high frequency. The network then became unreliable.

As a result of this flaw, more Bitcoin Cash blocks were produced than expected and miner revenue increased during this period. Bitcoin Cash built a c.5,000 block lead over Bitcoin, a lead it still maintains to this day. A couple of months later, in November 2017, a fix was eventually rolled out. The EDA was removed and replaced with a new difficulty adjustment system, a more simple rolling 24-hour system. However, this is still different to Bitcoin’s two-week window system. Bitcoin Cash’s system is more dynamic and faster to adjust. While this means Bitcoin Cash may have a more volatile difficulty in the short term, the coin is faster to adjust to any changes, while any block time discrepancies in Bitcoin may take longer to correct.

Overview of Bitcoin and Bitcoin Cash’s Difficulty Adjustment Systems

 Coin

Calculation period

Difficulty Adjustment

Comments

Bitcoin

2 weeks

Every 2 weeks

  • Less likely to suffer from block time discrepancies
  • Any discrepancies take longer to resolve

Bitcoin Cash

1 day

Each block

  • More likely to suffer from block time discrepancies
  • Any discrepancies are resolved faster

(Source: BitMEX Research)

One thing that many may have overlooked in Bitcoin Cash’s new difficulty adjustment algorithm is its interrelationship with the two-hour time protection rule. As far as we are aware, Bitcoin Cash has retained the 2 hour constant.

A two-hour period is now 8.3% of the calculation period. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 10 seconds. This does appear to be potentially significant and could result in changes to miner profitability, if exploited. Bitcoin Cash may therefore be somewhat vulnerable to miners manipulating timestamps, or at least more vulnerable than Bitcoin.

On the other hand, although Bitcoin Cash may be more vulnerable to miner timestamp manipulation attacks than Bitcoin, any issues will be resolved faster. 

Conclusion

The apparent vulnerability with Bitcoin Cash’s time protection rule, perhaps unexploited, illustrates how well thought out Bitcoin’s time protection rules were. As far as we know, these time protection rules existed since Bitcoin launched in 2009. When designing the system, Satoshi had to innovate at least three layers deep:

Proof of work system → Difficulty adjustment system → Robust time protection rules

While this may not seem especially ingenious to us now, we have had almost 11 years’ experience with such systems. That Satoshi had thought all this through before any such network existed is quite remarkable, in our view.

ForkMonitor: Unexpected Inflation Detection and Warning System

Abstract: ForkMonitor has now implemented unexpected inflation detection and warning systems for Bitcoin. The block reward is currently 12.5 bitcoin, which means that no more than 12.5 new bitcoin should be created each block. Some of the ForkMonitor nodes now calculate the total coin supply each block, using the gettxoutsetinfo RPC call. If the total coin supply increases by more than 12.5 bitcoin, warnings systems are initiated. This service potentially provides additional assurances to network participants about the supply of Bitcoin at any given time.

(Source: ForkMonitor.info)

Overview

ForkMonitor has recently added a new feature, unexpected inflation detection. This feature has been added for Bitcoin and Testnet Bitcoin. The system periodically checks the total coin supply by summing up all the UTXO values. If the value is unexpectedly large, warnings are activated. Bitcoin nodes are already supposed to check the coin supply, however this occurs by only checking that no unauthorised coins are created in each individual transaction and there is no macro total supply check. Therefore the ForkMonitor service could provide an additional layer of security and assurance for Bitcoin users, as well as an early warning system which could encourage people to run these checks on their own nodes if an issue is detected.

If the inflation is in line with expectations, a green tick is displayed on the website. However, if unexpected inflation occurs, a red cross is displayed alongside other warnings.

Illustration of unexpected inflation detected by Bitcoin Core 0.18.1

(Source: ForkMonitor.info)

Please subscribe to the feeds, to be altered in the event of unexpected Bitcoin inflation.

Coin Supply Checking Mechanisms

The systems plan to check the inflation using the following methods:

  • Coin supply change from the previous block –  After each Bitcoin block is produced, the system checks the total coin supply and stores the figure in a database. As each new block is produced, the summation is repeated and the total coin supply is subtracted from the previous figure. If the change is higher than the allowed block reward (12.5 bitcoins today, 6.25 bitcoins from around May 2020, etc.), then the warnings are initiated.
  • Consistency across multiple node versions In addition, the system will also check that the total bitcoin supply is consistent at each block height for all the nodes participating in the inflation check (which is illustrated on the ForkMonitor website).

Gettxoutsetinfo Issues

One of the main challenges we faced when implementing this inflation check feature was that it took considerable time for Bitcoin Core to run the gettxoutsetinfo call, typically around 2 minutes. This created several implementation challenges for ForkMonitor, such as what to display in this two minute period or what happens when a block is found while the calculation is occurring. For example, the maximum rate at which the inflation check can move forwards is one block every two minutes; if many blocks are found in a row, with smaller than two minute intervals between them, our check can be ineffective for a while.

Gettxoutsetinfo RPC call – Bitcoin’s supply of approximately 18 million is illustrated

 (Source: Output from Bitcoin Core 0.18.0 “Gettxoutsetinfo” call)

Others are aware of these issues, as Bitcoin developer Fabian Jahr recently put it:

[The gettxoutsetinfo call] does not have a sufficient user experience, you call it and it actually takes several minutes to respond and there is no feedback

 (Source: Fabian Jahr (Youtube))

In 2017 Bitcoin developer Pieter Wuille posted to the Bitcoin development mailing list, a potential improvement, which he says could make this Remote Procedure Call (RPC) call faster.

Replacement for Bitcoin Core’s gettxoutsetinfo RPC’s hash computation. This currently requires minutes of I/O and CPU, as it serializes and hashes the entire UTXO set. A rolling set hash would make this instant, making the whole RPC much more usable for sanity checking

 (Source: Pieter Wuille’s 2017 Rolling UTXO set hash email)

Based on the above idea, Fabian recently indicated he may work on implementing this potential fix, in an attempt to improve this RPC call. If this improvement is implemented, it would certainly be helpful for ForkMonitor.

Bitcoin’s 2018 Inflation Bug (CVE-2018-17144)

ForkMonitor was very much inspired by the events of September 2018, when it emerged that Bitcoin Core had a bug which would enable miners to create coins out of nowhere in addition to the normal block reward. This bug affected versions of Bitcoin Core spanning from 0.14.0 to 0.16.2, before the fixes were released. (0.14.X nodes merely crashed while later nodes would have accepted the blocks with the unexpected inflation).

A successful exploitation of this bug could have had catastrophic consequences for the network, for example Bitcoin’s supply could have inflated above 21 million or a large rollback may have occurred, undermining the security many users and businesses depend on.

ForkMonitor was launched to mitigate these risks. If such a bug existed today, our systems should be able to detect it in three ways:

  • ForkMonitor runs multiple versions of Bitcoin Core, spanning many years of development. If a newly-introduced bug results in unexpected inflation or an unauthorized spend, the older nodes should detect this and mark the block as invalid, triggering the warning systems.
  • The website also runs independent implementations of Bitcoin, such as bcoin, btcd and Libbitcoin. If Bitcoin Core has a bug which allows unexpected inflation or an unauthorized spend, as long as the same bug wasn’t independently implemented, these other clients should mark the block as invalid, triggering the warning systems.
  • As of October 2019, ForkMonitor also directly checks the total coin supply of each block. In the event of unexpected inflation, even in the unlikely scenario that all our nodes mark the block as valid, the warning systems will still be triggered. The inflation checking system is also helpful even if nodes do mark the block as invalid, as it can help users determine why this was the case in a timely manner.

Independent Implementations

As we explained in our October 2018 piece, Competing with Bitcoin Core, there are advantages and disadvantages of competing implementations and in particular independent implementations. One key advantage of independent implementations that we mentioned is that there could be a bug in Bitcoin Core or the reference implementation which is not present in the independent implementations.

For the above reason, we are keen to add one of the three independent implementations (bcoin, btcd and Libbitcoin) into the total coin supply inflation checking system as soon as possible. The method of calculating total coin supply used by these implementations may be independent from that used by Bitcoin Core, which should provide extra reassurance that the number is correct.

Conclusion

This new service may not solve all potential problems with regards to detecting unexpected inflation. For example there could be a bug in the gettxoutsetinfo check. In addition to this, the various mechanisms to check for unexpected inflation and block validity may not be truly independent from each other. Even the independent Bitcoin implementations may have inadvertently copied a bug or erroneous concept from Bitcoin Core. However, we believe this macro inflation checking service is potentially a useful addition to network security.

As a reminder, the ForkMonitor website is open source, therefore please feel free to contribute, fork the project or reproduce the website.

The Bitcoin Foundation

Abstract: In this piece we look back at the history of Bitcoin, focusing in on “The Bitcoin Foundation”, once one of the most prominent organisations in the ecosystem. We look at Foundation’s origins and then examine its failings with respect to its governance, transparency and finances, which ultimately led to a total loss of legitimacy within the Bitcoin community. We conclude that an all-encompassing Foundation was never likely to have been a good idea given the high governance and transparency standards of some in the community, and that a constant stream of scandals damaged the Foundation’s brand to such an extent that its duties had to be carried out by other organisations.

(Screenshot of the Bitcoin Foundation’s website and logo in 2013)

The Foundation’s Origins

Following on from our July 2018 piece, which took us back to shenanigans and incompetence at MtGox in 2011, this second look at Bitcoin’s scandal-rich history takes us back to July 2012, when The Bitcoin Foundation was founded. The Foundation had seven founding members, or six if you exclude Satoshi, who was oddly included as a founding member.

Bitcoin Foundation Founding Members

  • Gavin Andresen, Bitcoin Developer
  • Peter Vessenes, CEO of CoinLab
  • Charles Shrem, CEO of BitInstant
  • Roger Ver, CEO of MemoryDealers
  • Patrick Murck, Principal at Engage Legal
  • Mark Karpeles, CEO of MtGox.com
  • Satoshi Nakamoto, author of the white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”

(Source: GitHub) 

The objective of the Foundation was never completely clear, with the original bylaws stating the following:

The Corporation shall promote and protect both the decentralized, distributed and private nature of the Bitcoin distributed-digital currency and transaction system as well as individual choice, participation and financial privacy when using such systems. The Corporation shall further require that any distributed-digital currency falling within the ambit of the Corporation’s purpose be decentralized, distributed and private and that it support individual choice, participation and financial privacy.

(Source: GitHub) 

The Foundation’s Mission – June 2013

(Source: The Bitcoin Foundation)

In practise the role of the Foundation appeared to be as follows:

  • To pay the salary of Bitcoin developer Gavin Andresen
  • To arrange Bitcoin conferences
  • To promote Bitcoin to regulators

During 2012 and 2013 the Foundation gained in popularity, attracting members from across the Bitcoin community, including prominent developers, businesses and community members.

Public list of individual lifetime members

(Source: Bitcoin Foundation

Corporate members as at September 2013

(Source: Bitcoin Foundation

The Foundation was funded by membership fees – the initial membership fee schedule is provided below. However, the Bitcoin-denominated prices did start to decline in 2013 as the Bitcoin price appreciated.

Initial Membership Fee Schedule

(Source: GitHub)

It was believed by many that due to the membership subscription fees, the Foundation had considerable financial resources to spend on its mission.

Approximate lower bound of member contributions in April 2013 (Assuming initial fee rates)

  • 2 Platinum Industry Members * 10,000 BTC = 20,000 BTC
  • 7 Silver Industry Members * 500BTC = 3,500 BTC
  • 175 Lifetime Members * 25BTC = 4,375 BTC
  • Total Resources = 27,873 BTC

(Source: BitMEX Research)

As we see later on in this report, the Foundation only had around 8,000 BTC at the end of 2012, still a nice warchest, but a lower balance than many had expected. It is possible our estimate above could be an overestimate, as the timing of member subscriptions is unclear.

The Foundation Board

The governance structure of the Foundation was quite complex and arcane. There were three classes of members: 

  1. Founders
  2. Individuals
  3. Corporates 

The board initially consisted of five members, one nominated by the founders, two nominated by individuals and two nominated by corporate members. The term of each appointee was expected to be 3 years. At the start of the Foundation, all five board members were appointed by the founders and all board members were founders, with the exception of Jon Matonis.

Bitcoin Foundation Board Members (2012 to 2019)

(Source: Bitcoin Foundation Website, BitMEX Research)

Critics can point to the fact that the governance structure gave too much power to the initial founders and that new members of the organisation should have been able to join as equals to the founders.

Board Elections

The first board elections took place in 2013, with Meyer Malka winning the Industry seat and Elizabeth Ploshay winning the vote amongst individual members.

Board Election – Industry Seat (2013) – Winners: Meyer Malka

(Source: Bitcoin Foundation)

Board Election – Individual Seat (2013) – Winner: Elizabeth Ploshay

(Source: Bitcoin Foundation)

At the start of 2014, the holders of the two founding industry seats resigned. Charles Shrem resigned on 28 January 2014, two days after his arrest at JFK airport for money laundering and unlicensed money transmitter related offences. Charlie was eventually convicted and sentenced to two years in prison in December 2014. The main substance of Mr Shrem’s felony appears to be that he continued to provide customer support to a user of his BitInstant Bitcoin purchasing service, despite him allegedly knowing the customer wanted Bitcoin for the purposes of purchasing illegal drugs on the Silk Road e-commerce platform (Or that the customer wanted to supply the Bitcoin to somebody else, who wanted to purchase illegal drugs, one extra layer removed). Mark Karpeles, the holder of the other industry seat, resigned on 24 February 2014, following the failure and insolvency of the MtGox Bitcoin exchange, where Mark was CEO.

Brock Pierce and Bobby Lee were then elected as the two replacement industry appointed board members.

Board Election – Industry Seats (2014) – Winners: Bobby Lee & Brock Pierce

(Source: Bitcoin Foundation)

The appointment of Brock Pierce to the board proved controversial, with some claiming the Foundation should have done more vetting before allowing Mr Pierce to stand. The allegation against the former child actor, who featured in the “Mighty Ducks” and Disney’s “First Kid” was related to his alleged involvement in the sexual exploitation of children in the late 1990s. Although only a teenager at the time, Mr Pierce was an executive and co-founder at the internet video startup, Digital Entertainment Network (DEN), which was accused of hosting several parties where sexual abuse may have taken place. The allegations resulted in co-founder and CEO Marc Collins-Rector, along with Mr Pierce, resigning from DEN and supposedly fleeing to Spain.  Mr Collins-Rector eventually plead guilty to child abuse related offences and according to Reuters, court record show that Mr Pierce paid US$21,000 to settle a related civil suit, while other claims were dropped, the article also states that Mr Pierce denies the allegations.

Towards the end of 2014, in the face of considerable pressure, the Foundation made the following improvements to its governance:

  • Board member terms were reduced to 2 from 3 years
  • The founder board seat was eliminated
  • The founder member class was removed

The Foundation’s Finances

The below table provides a basic analysis of the Foundation’s finances, in the period where most of the member dues were depleted (2012 to 2014). The data is based on the organisation’s IRS990 forms. With respect to the pay of the board, the disclosure seems reasonably strong. Most board members received no remuneration other than those acting as executives. Paying Gavin was one of the main aims of the organisation and Gavin’s pay appears to be disclosed in a reasonably clear and appropriate manner.

  2012 2013 2014
Directors pay      
Gavin Andresen $15,000 $209,648 $147,917
Patrick Murck   $57,592 $115,001
Lindsay Holland   $160,652  
Jodie Brady     $141,667
Jon Matonis (Contractor)   $31,250 $137,500
Other pay costs $14,013 $118,047 $582,782
Total pay costs $29,013 $577,189 $1,124,867
Conference costs   $418,413 $825,525
Other costs $32,608 $472,302 $1,335,210
Total costs $61,621 $1,467,904 $3,285,602
       
Foundation Revenue      
Membership fees   $358,007 $335,723
Conference revenue   $377,883 $584,308
Other   $64,803 $35,728
Total revenue $159,359 $800,693 $955,759
       
Surplus/(Deficit) $97,738 ($667,211) ($2,329,843)
       
Disclosed Bitcoin figures      
Bitcoin (US$ value at year end) $107,549 $4,512,316 $703,843
BTC sales proceeds   $749,157 $569,728
Realised Bitcoin gains/(losses)   $77,148 ($40,316)
Unrealised Bitcoin gains/(losses)   $5,195,589 ($1,966,768)

(Source: IRS 990 Forms, BitMEX Research)

The main criticisms related to the Foundation’s finances at the time appear twofold:

  1. There was a sharp increase in spend in 2014, depleting the organisation’s reserves to near zero
  2. There was a lack of transparency with regards to the Foundation’s Bitcoin balance

As for the first criticism, concerns did seem somewhat justified. In 2014 pay costs increased by 81%, the 2014 conference made a significant net loss and other costs increased significantly. As for the $1.3m in other costs, we have provided a breakdown below, therefore readers can judge the extent of the excesses. Compared to the excesses of the ICO bubble in 2017/18, where the total sum of the costs below perhaps represent a fraction of just one marketing party for the most egregious ICOs, the spend is moderate. However, some Foundation members clearly expected their funds to be spent more prudently. The main issue appears to be that expectations were not clearly set out in advance. Whatever your view, the fact is that by the start of 2015, the Foundation had almost run out of financial reserves and to that extent, its finances were mismanaged.

2014 breakdown of other spend

Other professional services $307,767
Legal fees $200,003
Travel $159,166
Information technology $158,021
Professional event expenses $115,401
Public relations $93,241
Exchange loss $73,362
Accounting $50,556
Office costs $39,071
Grants (Foreign) $37,314
Bad debts $18,500
Payments to affiliates $18,002
Occupancy $17,949
Grants $14,000
Advertising $9,218
Insurance $3,639
Other $20,000
Total other spend $1,335,210

(Source: Bitcoin Foundation IRS 990 form)

The lack of transparency with respect to the Foundation’s Bitcoin balance is another area of concern. At the end of each year the IRS990 form disclosed the USD value of the Bitcoin holding, the realised Bitcoin gains and the unrealised Bitcoin gains. Based on this information we calculated the following:

BitMEX Research BTC calculations 2012 2013 2014
Bitcoin price at year end $13 $754 $320
Implied BTC balance at year end 8,216 5,985 1,381
Change in BTC balance   (2,232) (4,604)
Implied sales price   $336 $124
Realised Bitcoin gains/(losses)   $719,945 ($2,901,314)
Unrealised BTC gains/(losses)   $4,433,979 ($599,354)
       
Lowest Bitcoin price figures      
Lowest Bitcoin price in the year $4 $13 $268
Implied BTC sales proceeds   $29,011 $1,233,739
Realised Bitcoin gains/(losses)   ($201) ($2,237,303)

(Source: IRS 990 Forms, BitMEX Research)

The disclosures in the IRS990 forms lead us to the following apparent Bitcoin related discrepancies:

  • The Foundations closing bitcoin balance in 2012 seems reasonably low given the volume of Bitcoin donations (See the c.28,000 BTC figure earlier in this report)
  • The Foundation disclosed an unrealised Bitcoin gain in 2013 of $5.2m, however based on the annual price movement and the calculated year end balance, we calculated an unrealised gain of only $4.4m
  • The Foundation disclosed an unrealised Bitcoin loss in 2014 of $2.0m, however based on the annual price movement and the calculated year end balance, we calculated an unrealised loss of only $0.6m
  • The Foundation disclosed Bitcoin sales proceeds of $569,728 in 2014, while even assuming all Bitcoin were sold at the lowest traded price in the year, given the large reduction in the Bitcoin balance of 4,600 coins, sales proceeds should have been $1.2m

Although there were accusations of embezzlement, we do not consider these disclosures to indicate any such crime. The Foundation was probably receiving Bitcoin and spending Bitcoin throughout the period, therefore clear financial record of Bitcoin sales are not likely to be available. At the same time, rules related to the reporting of realised and unrealised gains with respect to financial assets are not strict for this type of organisation and the Foundation does have a degree of discretion with respect to the calculation methodology. Therefore, the filings themselves do not indicate wrongdoing in our view. However, what we can say is that filings do not clearly explain what happened to the Bitcoin balance and an explanation from the board could be helpful.

Some members clearly expected greater transparency and wanted to question the board about the funds, but they were never given such an opportunity. The following quote from Bitcoin commentator Andreas Antonpoulous (who at the time was a Foundation committee chairman), reflected the views of many in the community at the time.

You say they are funded. Where are those funds? Who controls those funds? When were the last audited? Are they actually solvent? Or have all of those funds disappeared into a big black hole? Just remember who was in the leadership until recently, who is in the leadership today and what their track record of ethics has been and I would suggest that I would not be surprised at all if the Foundation implodes in a giant embezzlement problem sometime down the line or funds get stolen, within quotes or without quotes, or something like that. It’s bound to happen because these things don’t happen due to technical failures of bad actors, they happen due to failures of leadership The Foundation is the very definition of a failure of leadership.

(Source: Andreas Antonopoulos – March 2014 – Let’s Talk Bitcoin Episode 95)

Entanglement in the MtGox Scandal

To make matters worse, there were also accusations of the Foundation’s entanglement in the MtGox insolvency:

  • The MtGoX CEO, Mark Karpeles, was a founder and founding board member of the Foundation, while the company itself was a platinum member of the Foundation
  • Founding member, Roger Ver, famously assured MtGox customers of the solvency of the platform shortly before the exchange failed
  • The Foundation’s founding chairman, Peter Vessenes (who may have believed he was entitled to some MtGox equity), has been involved in various legal disputes with MtGox dating back to 2013 as a result of a failed business partnership. Peter’s company Coinlab sued MtGox for US$75m in 2013. As of August 2019, Peter now claims a remarkable total of US$16bn (Y1.6 trillion) from MtGox, an amount large enough to effectively block distributions to MtGox clients, and a large source of frustration to creditors to this day.

Andreas compared the Foundation’s situation to MtGox as follows:

Its problems go directly back to a complete failure of leadership. A completely closed, insular, arrogant, sheltered, uncommunicative leadership. Part of which was Karpeles himself, but there are another couple of relics left on that board, who pursue the exact same approach with their leadership. The Foundation is the Gox of Foundations. I am surprised it didn’t blow up in the wake of the Gox scandal, because there were a lot of significant conflicts within that environment.

However, perhaps it is unfair to make much of the association between MtGox and the Foundation, afterall, the ecosystem was small and MtGox was the dominant exchange, therefore a degree of association was inevitable to some extent.

The Amsterdam Conference (May 2014)

In May 2014 the Bitcoin Foundation arranged what was, up until this point, the largest conference in the space. It was the first conference (at least one which we attended), with characteristics familiar to many in the 2017/18 era. Unabated enthusiasm, unrealistic expectations about the underlying technology, expensive catering and countless booths representing new businesses with plans that appeared to make little commercial sense. As the figures above indicate, despite the expensive ticket prices of up to $800, the conference appears to have generated a net loss of around US$250,000.

The conference was split into two sections, a commercial section in the main exhibition hall, and the Bitcoin Foundation annual meeting (or technical track), which was down the hallway in a hotel conference room, entry to which was free for Foundation members. The technical discussions were followed by the Foundation members’ meeting

(Source: Eventbrite

Journalist Ryan Selkis (now founder & CEO of Messari), was one of the key lifetime members at the event trying to hold the Foundation to account. At the annual meeting he asked several challenging questions to the Foundation board members, asking for greater transparency. Up until this point much of the debate and complaints had taken place on online web forums and this real world interaction marked a significant and novel change. In response to his challenges, one board member said the following:

We can spend a lot of our time trying to be transparent as much as we can and higher resources can be transparent or we can spend a lot of time in the board level making sure that we [have the] resources to make bitcoin bigger. It’s possible but right now, honestly, we’re in an environment where bitcoin is not well perceived. You asked for priorities at least from my side as a board member, it’s more about [making bitcoin bigger]

(Source: Bitcoin Foundation 2014 Annual Meeting)

It was clear from this response that, for whatever reason, some board members had chosen not to tackle the transparency and governance concerns, leaving some members feeling frustrated and more convinced of wrongdoing on the part of the board. 

The Blockchain Election (February 2015)

Given the issues that the Foundation had faced and the concerns in the community about transparency, governance and the purpose of the Foundation, this was a relatively important set of elections. There was a large number of candidates and a reasonably good quality debate among the candidates, for example a dedicated Let’s Talk Bitcoin podcast on the election. 

The Foundation decided to conduct the 2015 individual board seat elections on the blockchain. As the chair of the election committee, Brain Goss said: 

I believe in the concept of using the block chain for storage of compact proofs/hashes (as the market dictates), and I’m a big believer in transparent voting that any one can verify

(Source: Bitcoin Foundation Forum)

However, the blockchain voting process did not run smoothly and the following issues arose:

  • The first round of voting took place using the Helios voting system. However, no candidate achieved more than 50% of the vote, as required by the by-laws, therefore a second round was required. The Foundation then made the odd decision to switch the voting platform to Swarm between the voting rounds, a decision met with widespread opposition. Despite initially starting the final round voting process on Swarm, during voting the Foundation then decided to switch back to Helios, invalidating the Swarm votes
  • The decision to reduce the number of candidates to four after the first round of voting appeared arbitrary 
  • Registering to vote was widely regarded as a cumbersome and complex process and some candidates complained

(Source: Email received as part of the Swarm voting process)

Board Election – Individual Seats First Round (2015)

(Source: Helios voting system records)

Board Election – Individual Seats Final Round (2015) – Winners: Oliver Janssens & Jim Harper

(Source: Bitcoin Foundation)

After the voting controversy, Patrick Murk told Bitcoin Magazine:

This clearly struck a nerve with folks that think blockchain technology should only be used for transferring Bitcoin and not other [applications] like voting. [It] sparked a debate on how people use the blockchain

(Source: Bitcoin Magazine)

Removal of Directors & The End Of Board Elections (December 2015)

In December 2015, the two newly elected board members, Oliver and Jim, were removed by the other board members, due to a disagreement over the best way forward for the Foundation. Oliver and Jim had recently succeeded in competitive elections from individual members, giving them a considerable democratic mandate. At the same time the two year election terms of Elizabeth and Meyer had already expired, while Brock and Bobby had been elected by the industry and not individuals. Therefore, from the point of view of the individual members, Oliver and Jim were the only two board members with a significant mandate and they had been removed. In a violation of the by-laws, the Foundation then decided not to conduct any further board elections. As the executive director Bruce Fenton put it:

I used to believe that public, open elections were a great thing.  I’m not as convinced now…. We unfortunately don’t have the time or resources for more process. 

(Source: Bitcoin Foundation forum)

In our view, this logic seemed difficult to justify, given many of the problems were caused by the boards apparent lack of accountability to individual members, with Elizabeth Ploshey being the only board member elected by individual members who served on the board for any meaningful amount of time. If the Foundation did want to revive itself, it could have reinstated Oliver and Jim and allowed further elections to replace the other board members who could have left. Instead, the Foundation decided to distance itself even further from members, avoiding the challenges this accountability would have imposed, and consequently the Foundation appeared to lose any remaining legitimacy it had left.

After this point, between 2015 and 2019, four new board members were appointed from the pool of candidates that were defeated in the previous elections, except this time appointments were made by the board rather than members.

Conclusion

The Foundation still exists today, with Brock as Chairman and Bobby as Vice chairman, although their elected terms have long since expired and no more elections are in sight. The Foundation has no significant financial resources and is largely irrelevant. The activities the Foundation used to conduct are now carried out by others, for example Coin Centre does some regulator lobbying, and Bitcoin development is funded by other organisations such as Chaincode Labs, Blockstream, MIT’s DCI and other industry players. In many ways the conclusion to this piece writes itself. Bitcoin never needed a Foundation, it is stronger without one, and any all-encompassing Foundation like this was always doomed to fail.

The outrage at the lack of transparency at the Foundation exposes some of the key divergences in expectations and culture between members of the Bitcoin (now cryptocurrency) community. Some Bitcoiners, especially those involved since the early days of the Foundation, were often highly conspiratorial, paranoid and expected radically high levels of transparency, accountability and financial prudence. The Foundation seems to have misjudged these expectations, lost the backing of the community and ultimately failed. However, compared to the excesses of the coin offering era, which picked up from around 2014 onwards, peaking at the start of 2018, the financial accountability and transparency of the Bitcoin Foundation was almost impeccable, relatively speaking. Some members of the cryptocurrency community (not all newer ones), had radically different expectations, focusing more on what they perceived as game-changing technology, changing the world and getting super rich, rather than governance. Even in this new climate, irreparable damage to the Foundation’s brand had been done and it never again found its place.

UPDATE – 23 September 2019

After the publication of this piece, several prominent Bitcoin developers, whose names were displayed on the Foundation’s website, indicated to us (in some cases with proof) that they were given membership status for free (rather than by paying 25BTC). This may indicate that:

  1. Support for the foundation may not have been as widespread as we initially thought
  2. The Foundation’s bitcoin balance in 2012 may never have been as large as we initially thought

Lightning Network (Part 4) – All Adopt The Watchtower

Abstract: BitMEX Research has upgraded its lightning nodes to include watchtower functionality. The watchtower functionality is a mechanism for connecting to another friendly node, which monitors your lightning channels for you and prevents a dishonest counterparty from stealing your funds, even when you are offline. We successfully conducted an experiment, proving the watchtower concept actually works, at least in our case. It is encouraging that the watchtower concept, which has been around for years in theory, now actually works in practise.

(Source: Alcatraz, flickr)

Overview

This piece on watchtowers follows on from our three previous pieces on the lightning network:

  1. Lightning Network (Part 1) – Motivation
  2. Lightning Network (Part 2) – Routing Fee Economics
  3. Lightning Network (Part 3) – Where Is The Justice?

On 29 June 2019, LND 0.7.0 (Go implementation of lightning) was released and this included the watchtower functionality. A watchtower is a third party lightning node, that can detect if a dishonest party attempts to steal funds and then broadcast a justice transaction, sending the funds back to the honest party, even when the honest node is offline.

There two modes of watchtower functionality

 

Client/Tower User

Server

Description

The client connects to a watchtower server. Whenever the lighting channel states change, data is sent over to the watchtower server with the latest channel state. In the event of a channel breach, the watchtower can broadcast a justice transaction, sending the funds to the honest node’s onchain wallet.

The watchtower server does not need to have any lighting channels or make any payments. The server connects to a lightning client and monitors the client’s lightning channels for them, on their behalf.

Operational details

To connect the node to a watchtower server, one needs to add the following line to the lightning configuration file:


> wtclient.private-tower-uris=tower-public-key@ip-address:9911

Where the public key and IP address is provided by the watchtower server.

To activate a watchtower server, one needs to add the following line to the lightning configuration file:


> watchtower.active=1


After this, one can run the command:


> lncli tower info


The watchtower server should then display the watchtower public key (different from the lightning node public key). This key is needed by the watchtower client. Due to potential denial of service threats, it is currently not advisable to publish the watchtower public key.


One can check if the watchtower is working by viewing the logs.

It is possible for a node to be both a watchtower server and client at the same time. If you run two nodes, each node can be the watchtower server of the other. BitMEX Research currently has three operating lightning nodes and the nodes all watch over each other in a loop configuration.

Successful test of the watchtower

On 30th July 2019, BitMEX Research successfully tested the watchtower system. Much like our previous piece on justice transactions, we tried to cheat ourselves, but this time used a watchtower. In an encouraging sign, the watchtower functionality correctly worked and the would-be thief was punished.

In order to do this test, we needed to run three nodes:

  • The dishonest node – BitMEXThief
  • The node using the watchtower service – BitMEXTowerClient (the user of the watchtower service)
  • The watchtower itself – BitMEXResearch

Manually constructing a watchtower justice transaction

(Source: BitMEX Research)

The eventual justice transaction, broadcast by our watchtower can be seen here.

Conclusion

All BitMEX Research lightning nodes are now protected by watchtowers. While a watchtower is a large improvement in security, in our view, a greater problem than dishonest channel breaches, is the risk of a lightning node’s memory becoming accidentally lost or destroyed – under such circumstances the node could lose the latest channel states. A watchtower does not fix that problem, although there have been improvements in this area, with Static Channel Backups (SCBs). Using SCBs, as long as no new channels were created post backup, all the funds should be safe.

A successful test of the watchtower does provide us with a greater degree of assurance about the robustness of the lightning network. It is encouraging that ideas such as watchtowers, which have been theoretically discussed for years, finally exist. However, when it comes to improving the robustness and reliability of the lightning network, there is still a long way to go.

Lightning Network (Part 3) – Where Is The Justice?

Abstract: In our third look at the lightning network, we examine lightning channel closure scenarios and the incentives to punish dishonest parties and prevent them from stealing funds. This punishment mechanism is called a “Justice Transaction”. We explain how to arbitrarily construct a “Justice” scenario and present data on the prevalence of this type of transaction on the Bitcoin network. We have potentially identified 241 Justice transactions, representing 2.22 Bitcoin in value, since the lightning network launched at the end of 2017.

(Lightning strikes the city of Singapore)

Overview

Following on from our January 2018 discussion of the motivation behind the lightning network and our March 2019 analysis of lightning network routing fee economics, this third piece on the lightning network looks at channel closures and the incentives designed to prevent dishonest lightning nodes from stealing funds, by broadcasting an earlier channel state.

It should be noted that, by design, when a thief attempts to steal funds on the lightning network, if caught, they do not only lose the money they tried to steal, they lose all the funds in the relevant channel. This “punishment” is expected to act as a deterrent and is sometimes called “justice”.

The four lightning channel closure scenarios

Opening lightning channels is, generally speaking, more simple than closing them, there is only one way to open a lightning channel, cooperatively with interactive communication between the parties. On the other hand, when evaluating channel closures, one needs to consider four different scenarios, as outlined in the decision tree below (See figure 1).

Figure 1 – Lightning network channel closure types – decision tree

(Source: BitMEX Research)

Figure 2 – The four lightning channel closure scenarios explained

Closure type Description Onchain technical details and example transactions
This is the most common scenario.

A cooperative closure occurs when an honest node initiates the channel closure, while the node on the other side of the channel is online and communicating.

Funds are distributed to each party’s onchain wallet based on the latest channel state.

A cooperative closure requires only one onchain transaction.

Inputs are redeemed using a “normal” 2 of 2 multi-signature script and sent to two outputs, each belonging to the parties involved, with the balance based on the latest channel state. 

This transaction is hard to identify as lightning and therefore it is the most private of the three channel closure types.

Example closure:

A non-cooperative non-breach closure occurs when an honest node initiates the closure, without directly communicating with the node on the other side of the channel.

Funds are distributed to each party’s onchain wallet based on the latest channel state.

These two different economic scenarios, are represented by one technical onchain scenario.

This scenario requires two onchain transactions. 

Firstly the funds are redeemed using a 2 of 2 multi-signature witness and sent to two outputs. The node which did not initiate the closure is allocated funds based on what the channel closing party says is attributable to them, while another pot of funds is sent to an output which can be redeemed by using either an OP_IF or an OP_ELSE script. 

In a second transaction, the funds sent to the OP_IF script, are claimed by the party that initiated the channel closure, using the OP_ELSE branch of Bitcoin script.

Example closure:

A non-cooperative breach non-justice closure occurs when a dishonest node initiates the channel closure, by broadcasting an earlier channel state, attempting to steal funds from the node on the other side of the channel.

The non closing node does not check the network within the locktime period, normally 24 hours and does not broadcast a justice transaction. Therefore the theft is successful.

Funds are distributed to each party’s wallet based on an earlier channel state, such that the non closing party losses funds and the dishonest channel closing party successfully steals funds.

A non-cooperative breach justice closure occurs when a dishonest node initiates the channel closure, without directly communicating with the node on the other side of the channel.

The non closing node does check the network within the locktime period, and creates a justice transaction, such that the attempted theft fails.

The would-be thief is punished and all the funds go to the honest non closing party.

In the justice scenario, two onchain transactions are also required. 

In the first transaction, the funds are redeemed using a 2 of 2 multi-signature witness and sent to two outputs. The node which did not initiate the closure is allocated funds based on what the channel closing party says is attributable to them, while another pot of funds is sent to an output which can be redeemed by using either an OP_IF or an OP_ELSE script.

In a second transaction, the honest node, that did not initiate the closure claims all the funds sent to the OP_IF script, using the OP_IF branch.

This is the most revealing of the three channel closure types and provides the lowest level of privacy.

Example closure:

How to construct a Justice transaction?

In the below arbitrary scenario, we manually created a justice transaction, using the following steps:

1. Spin up a new lightning network node (LND), with the alias “BitMEXThief” and open a channel, worth US$50 (400,000 Satoshis) with the BitMEXResearch lightning node
2. Switch off the BitMEXThief node and back up the .lnd directory
3. Restart the BitMEXThief node and make a lightning payment of US$25 (200,000 satoshis) to BitMEXResearch. The channel is now balanced, US$25 in both directions
4. Switch off the BitMEXThief node again
5. Switch off the BitMEXResearch lightning node (to prevent it broadcasting the latest channel state to the thief node)
6. Restore the BitMEXThief node back to its state prior to the channel re-balancing, the state in step 2
7. On the restored BitMEXThief node, attempt to close the channel from its earlier state and claim the full US$50 (400,000 satoshis) to the BitMEXThief node’s onchain wallet
8. Restart the BitMEXResearch node. The node then automatically detects the attempted theft and broadcasts the “justice transaction”, sending the full US$50 (less fees) to its onchain wallet. The would be thief was punished, by losing all the funds inside the channel. Note that the thief attempted to steal US$25, but ended up losing the full US$50.

The above experiment occurred successfully, providing some assurance that Lightning does actually work and if you try to steal, you will be punished.

Network Justice transaction data

After conducting our own justice transaction, we looked at the characteristics of this transaction (Inputs redeemed using the OP_IF branch) and searched for other justice transactions on the Bitcoin blockchain. We identified 241 transactions, which appear to be justice channel closures, dating back as far as December 2017. Mr. Alex Bosworth, from Lightning Labs, has created a tool to identify justice transactions, which may be more robust than our more basic search methodology.

Figure 3 – Number of justice transactions – monthly

(Source: BitMEX Research)

(Note: There is a possibility the data includes false positives)

Figure 4 – Value redeemed in justice transactions – monthly (BTC)

(Source: BitMEX Research)

(Note: There is a possibility the data includes false positives)

The justice transactions we identified had transaction inputs totaling 2.22 BTC, with the monthly total peaking at around 0.67BTC in February 2019, as figure 4 above illustrates. This does not necessarily mean thieves tried and failed to steal 2.22 BTC, as the dis-honest nodes may have punished thieves by a amount larger than the value they tried to steal (we do not know the latest channel state). The 2.22 BTC represents the total funds claimed by honest non channel closing nodes, part of this value is funds originally owned by the dis-honest nodes and part of the value will be the value they tried to steal.

It is also possible that many of the 241 justice transactions do not indicate genuine dishonestly, for instance it could be users testing the system, where the same user owns both lightning nodes in question. For example BitMEX Research is responsible for 5 of the 241 justice transactions, when there was no victim, as BitMEX owned all the nodes and funds.

241 justice transactions, with a value of just over 2 BTC is reasonably small relative to the size of the lightning network. The lightning network statistics website 1ml.com, indicates that there are currently 940 BTC locked up in 32,951 channels. The total number of justice transactions in the last 18 months is therefore only 0.7% of the current number of lightning channels.

Conclusion

In order for the lightning network to succeed as a robust, reliable and scalable payment system, the justice mechanism needs to be effective in deterring and preventing theft. As for the optimal justice rate, this is hard to determine, if it is too high and it shows that successful thefts may be too prevalent and the threat of justice may not be sufficient. If it is too low, it may mean nobody is attempting theft, thereby increasing the risk that users do not monitor their channels. This may lead to increases in the risk of large systemic channel thefts in the future.

For now, at least according to the data we have analysed, there appears to be a reasonable degree of justice on the burgeoning lightning network.

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

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

(Facebook vs Blackrock – The battle for the ETFs)

Overview

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

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

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

(Source: BitMEX Research, Bloomberg)

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

Comparing the new ETF structure with the traditional space

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

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

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

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

  Libra ETF

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

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

US$63.5 billion

Asset class

Fixed Income

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

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

Portfolio managers

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

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

Fees

Unknown

0.05%

Investment yield

Unknown

2.6%

Use of investment income

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

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

Attributable to ETF unit holders

Available exchanges

Currently None

The Libra Association

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

NYSE

Creation/redemption basket size

Unknown

100,000 units

Authorized Participants (entities able to create and redeem units)

Authorized resellers, not currently disclosed

Investment Banks

Fund auditor

Unknown

PwC

Information about holdings and Net Asset value (NAV)

Unknown

Full disclosure (Published daily)

(Sources: iShares, Libra)

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

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

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

Figure 3 – Technical and cryptographic considerations

 

Libra ETF

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

Consensus system

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

Blockchain

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

Control of units based on digital signature

Possibly:

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

No

(Sources: iShares, Libra)

Conclusion

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

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

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

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

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

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

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

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

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

The donation is provided unconditionally and without restrictions.

The Bitcoin Cash Hardfork – Three Interrelated Incidents

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

Illustration of the Bitcoin Cash network splits on 15 May 2019

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

The three Bitcoin Cash issues

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

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

(Source: BitMEX Research)

The empty block problem

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

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

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

(Source: BitMEX Research)

The asymmetric chainspilt

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

Bitcoin Cash consensus chainsplit

(Source: BitMEX Research)

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

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

Screenshot of the command line from our Bitcoin ABC 0.19.0 node

(Source: BitMEX Research)

The coordinated two block re-organisation

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

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

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

Transaction ID

Output total (BCH)

1e7ed3efb7975c06ca46598808e17c6f42c66a085fcb65356dc090e3c434d874

Coinbase (not counted)

0cdd5afff40831199d78ac55116a94aaf4ea7d53e599ac44962c29861ef9f05e

79.9

1907e59313a5c2607f706e8439feb613ed3ff89530d17bd9deced7113928df79

358.9

27553ff15a9d58b10b33da69bef3ccd570c007fc0d695cf8b88817cfc4d49065

65.2

2ff74d9b244469dcd87f9c853b70f9bc72d4116c662ee12783a1c32a6825d45e

196.3

357e31bcf17b4d557954b2d69b7169559a64605a628c4bb9eb11adbd416967d1

117.4

3801dc4ee11ccaeda243ac287ee5e40afb0f07dc0ba26f534ea52f4bfde0d3da

161.2

83e6065dd31ef706f6a90669e460000741820c4dcb753290bd2b003a9f853211

71.2

8950cae069562893aa3583b75fd14f2aaef4f0db72292bd05e11f915ca38cd86

107.8

8e10f1f85d9707ca974ddabd9cb8188d0b890586781ef4161a9133dadefbe0e6

72.0

8fc0b3665f4734b56686ffec83f6b23000720af90102e20f39d9dddb5f1f5c25

183.0

99bd320fb7e3fc487b393c3b9afbc6a7bc765d7f9df5902201a70d3cb8fc5a63

57.8

a38b43f85cc592c4bd69b2b1f0f865df6d36f3b89dfa6119780197369e48192a

177.8

b091bf34d72444ff1669dd13b6c912d8801b94aad8a92d162a9680d46d4b727f

89.2

bd8ee13735dcbdad983fe9624c5b3fd3d257b15a62b269ddb40bb4be9d4a15cb

100.5

beae5bc9137beebddea6f5fbc6fe79b77f6d59f2aa2a5da675ccc39b2b2f8cb6

166.3

c47d1c18c39d28df21ce0e3c34021295658b56c7e669af3aebe685cea32462dc

210.3

c8031b2fd429d9e2838dccc7fa0631788139443a7609958c5d2ce195aec97f8a

85.7

cf3af954a7c3b327107aa42498ec31924075bd926a61428352695a696af8d6c4

114.8

cf8f47928c37bc24c88ff8ff8ea3c84419d4cedc907e74d113e681b055c566dc

162.0

dff4537328f2568db5b7f0fa81a57024fdeb9da23a432a893fb48eca1ab63079

115.9

e1398e628da1258db08f969efdade13e6daac6a53e5b43121dab3604c605af29

69.9

e926ce8ca0192b3ea7f971d93eec3f651e8a35839a76101512cb8c37f98caa89

126.8

e9e0482d61300d3b3d6a9340f9ee66bd6d098328cd7ced50416bb28eb8dc796e

307.4

ebc4392b27056b84a0337638f1257031172d842c148f9ffa10e80afc4080d8a1

           82.7

f81267d65855040bf08bb5291a87733555067041ab611cd4e874368c8c1a2c2a

111.9

Total

3,391.7

(Source: BitMEX Research)

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

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

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

(Source: BitMEX Research)

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

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

(Source: BitMEX Research)

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

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

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

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

Allow Segwit recovery

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

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

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

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

Conclusion

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

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

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

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