比特币的区块时间戳保护规则

摘要:我们检查了比特币鲜为人知的两个规则,这些规则用于防止不法矿工操纵区块时间戳以获得不公平的高额挖矿报酬。我们讨论了为什么可能选择类似 2 小时 MAX_FUTURE_BLOCK_TIME 值之类的常数,以及该值会对比特币现金有何特定的影响。我们得出的结论是,考虑到实施规则时缺乏功能网络,比特币的时间保护规则似乎相当有效,令人赞叹。

(来源: Pexels)

比特币的时间问题

人们可能认为时间对于比特币网络并不是一项重要的考虑因素,因为每个区块都引用前一个区块的哈希值,所以这些区块已经有先后顺序。比特币区块还包含交易(输入、输出和值)、推导区块头的默克尔树(Merkle Tree)和区块哈希值本身,用于证明工作量。从表面上看,这对于交易和一致性系统也许已经足够。但是,存在调整难度的问题如果太多的矿工加入网络,区块时间可能变得太快,又或者如果太多的矿工离开,区块时间可能变得太慢,使得网络不可靠。为了解决这个问题,每两星期调整一次采矿难度,以实现区块之间十分钟的目标时间。遗憾的是,为了对两星期的时间进行计算,需要将时间概念引入区块链并成为一致性系统的一部分。因此区块必须含有时间戳,人们可以将比特币看作世界上第一个分布式电子时钟。

区块时间戳安全规则

在比特币区块产生时,实质上涉及两个时间:

  1. 区块头中的时间,是由矿工放置的
  2. 区块产生的实际时间。

当然,这两个时间应当几乎相同。毕竟,矿工们肯定有合理准确的时钟,他们为什么会在时间上撒谎呢?

矿工的确存在在时间上撒谎的诱因。比如,不法矿工可能会添加一个将来的时间戳。举例,如果生产一个区块要 10 分钟,矿工可以通过向将来添加 5 分钟的时间戳来声称花了 15 分钟。如果这种增加 5 分钟的做法在整个两星期的难度调整周期都持续 ,平均区块时间会看起来像是 15 分钟,而实际上比这要短。那么下一个周期的难度可能会向下调整,由于区块时间加快,增加采矿收入。当然,这种方法的问题在于,比特币时钟的移动继续与真实时间越来越远。

为了解决或减轻上述问题,比特币有两个机制防止矿工篡改时间戳。

  1. 过去时间中值(MPT)规则 - 时间戳必须比过去 11 个区块的中值更靠前。11 个区块的中值意味着可以对 6 个区块进行重组并且时间仍不会向后移动,有人可能认为这与 Meni Rosenfeld 的 2012 年报告中提供的例子是一致的,即对于拥有 10% 网络算力的攻击者,必须进行六次确认才能将攻击的成功概率降低到 0.1% 以下。
  1. 未来区块时间规则根据 - MAX_FUTURE_BLOCK_TIME 常量,相比来自同等节点的中值时间,时间戳不能出现在未来 2 小时以上。节点提供的时间与当地系统时钟之间的最大允许差是 90 分钟(又一个安全保障措施)。需要注意的是,不同于上面的 MPT 规则,这不是一个完全达成共识的规则。具有在未来太远时间点的时间戳的区块是无效的,但随着时间向前移动它们可能变得有效。

规则一确保区块链在时间方面继续向前 移动 ,而规则二确保区块链不会向前移动 太远。这些时间保护规则并不完美 ,例如,矿工仍可以在两星期时间内通过生成未来的时间戳,从而将时间戳向前移动,但这种操作的影响有限。

如上文的比率所示  ,由于两个小时只是两星期中很小的一部分,此操作对网络可靠性和挖矿盈利 能力的影响可能有限。这相当于在难度调整后的两星期内,将区块之间的时间从 10 分钟减少至 9 分 54 秒。而且 ,它只是一次性变动,因为一旦发生了两小时的时间移动 之后,除非先向后移动 ,否则无法再次发生前 移。与此同时,矿工在向前移动两个小时之前,可能会考虑安全边际,以减少区块被网络拒绝的风险。

据我们判断 ,这些规则在防止矿工以恶意方式篡改比特币时间戳方面,已经证明具有合理的有效性。

比特币现金的理论区块时间问题

如我们最先在 2017 年 9 月所提及,比特币现金是 2017 年 8 月从比特币分叉出来的一种替代货币, 它的主要目的是提高区块大小限制 。当时比特币现金开发者的担忧之一,  就是很多矿工不会开采比特币现金,因此区块之间的时间 差可能太大。因此实施了所谓的 “紧急难度调整”(EDA),以减轻这种担忧 。我们在此不会进行详细 讨论,但足以说明此机制非常复杂并且证明存在根本的瑕疵 。这种算法意味着,如果在特定时期内没有找到特定数量的区块,难度将会降低。此政策尤其激进,因为它意味着区块之间的时间差越长,难度向下调整的幅度就越大。矿工可以故意留下大的时间差操纵网络,导致难度大幅变动,随后出现以非常高频率生成区块的低难度期。然后网络变得不可靠。

由于这种瑕疵 ,生成的比特币现金区块超过预期,并且矿工在此期间的收入增加。比特币现金建立了基于比特币的大约 5,000 条区块引线,一条引线至今依然存在。几个月后,在 2017 年 11 月,最终进行了修复 。EDA 被移除并且被一个新的难度调整系统(更简单的 24 小时滚动系统)取代。但是,这仍然与比特币的两星期窗口系统不同。比特币现金的系统更加动态并且调整速度更快。 虽然这意味着比特币现金可能在短期拥有更波动的难度,但此货币对变化的调整速度更快,而比特币中的时间差纠正可能需要花费更长时间。

币种 计算期 难度调整 说明
比特币 2 星期 每 2 星期 遭遇区块时间差的可能性更低 时间差需要更长时间解决
比特币现金 1 天 每个区块 遭遇区块时间差的可能性更高 时间差的解决速度更快

(来源: BitMEX Research)

在比特币现金的新难度调整算法中很多人可能忽略了一件事情  ,就是它与两小时时间保护规则的相互关系。 据我们所知,比特币现金保留了 2 小时常数。

两小时时间现在是计算期的 8.3% 。这相当于将区块之间的时间从 10 分钟减少至 9 分 10 秒。这确实似乎具有潜在的重要意义,并且如果加以利用,可能导致矿工盈利能力的变化。因此比特币现金在矿工篡改时间戳方面可能具有一定脆弱性,或者至少比比特币更加脆弱。另一方面,虽然比特币现金面对矿工时间戳篡改攻击时比比特币更加脆弱,但对问题的解决速度更快。

结论

比特币现金的时间保护规则的明显脆弱性,可能未被利用,显示出比特币的时间保护规则的思考是如此完善。据我们所知,这些时间保护规则自 2009 年比特币推出时就已经存在。在设计系统时,中本聪必须至少在三个深度层面进行创新:

工作系统的验证 → 难度调整系统 → 完善的时间保护规则

虽然这在今天我们看来可能不是特别精巧,但我们对这些系统已经有了 10 年经验。我们认为,中本聪在没有任何此类网络之前对此进行了全面思考,是非常了不起的。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

比特币现金 2019 年 10 月的哈希率波动增大

摘要:我们观察了近期比特币现金网络哈希率波动的增加程度。我们注意到,振荡显性的周期性可能表明存在某种形式的操纵,但我们没有发现这种行为的直接证据。我们的结论是,对于比特币现金哈希率的波动问题,没有简单的解决方案,另一方面,到目前为止,对币的可用性的负面影响微乎其微。短期内最好的办法可能是耐心等待并研究可能的解决方案,除非某个特定的原因变得更加明显。 

比特币现金哈希率估算-(8小时滚动均值)– PH/s

(资料来源:BitMEX 研究)
(注:选择了八个小时,最大程度地提高显性的哈希率振荡的视觉效果。哈希率数据经使用难度和区块时间戳算得)

比特币现金哈希率波动的问题

近期有人对比特币现金哈希率的波动明显高出正常水平,导致区块时间的变化大于预期表示担忧。如上图所示,哈希率的波动似乎在 2019 年 10 月初左右有所增大。需要注意的是,考虑我们是根据区块时间来计算哈希率的,这是一个随机且动态的过程,因此要确定哈希率短期的变化是否随机,或是否是由实际变化所导致的具有挑战性。但是,我们认为数据具有合理的说服力。在我们看来,这种波动性可能让网络在某些时期支付的可靠性略有降低,但这不是个大问题。

在 2019 年 10 月,我们对比特币现金的难度、区块时间戳以及我们节点收到比特币现金区块的时间进行了基本分析。

如下图所示,与比特币相比,比特币现金的波动时间间隔的确显得更大。 

区块间的时间间隔 – 50 区块滚动平均(分钟)- 2019 年 10 月

(资料来源:BitMEX 研究)
(注:x 轴是比特币现金的区块高度,而截至2019年10月29日结束前的29天,比特币增加的时间间隔相同)

不仅是区块之间的比特币现金时间间隔看起来比比特币更加不稳定,峰值更高而谷值更低,而且其随机性似乎也更小,峰值和谷值更规律。数据可能存在某种形式的周期性,这可能意味着操纵,但我们没有发现任何直接的证据。另一方面,数据的随机性意味着图表可能看起来有周期性,但这可能是错觉。请注意,比特币现金难度是按照每个区块调整的,因此调整算法不应造成此类周期性。还请注意,选择的是 50 个区块的滚动周期,以最大程度地增大峰值和谷值的大小,因此图表可能对问题略有放大。 

尚无证据证明引起这一现象的原因

我们在下表中,通过计算每个区块高度的难度,分析了每个矿池每个区块的平均难度。我们试图确定,是否某个矿池在用于实现减小平均难度的某个策略取得了成功。分析没有结论,未知矿工达到的平均难度相当接近平均水平。但是,对数据进行更详细的分析,可能会发现更需要关注的环节。

比特币现金 – 2019 年 10 月采矿统计

矿池 所采区块的号码 采矿份额 采掘每个区块的平均难度 时间戳与本地时钟之间的平均时间间隔(分钟)
未知 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
总计 3,862 100.0% 347,926,146,858 0.48

(资料来源:BitMEX 研究)

我们还分析了区块时间戳与本地系统时钟显示收到区块的时间之间的时间间隔,再次寻找矿池之间的差异以求获得操纵证据。也许可以利用我们昨天的文章中提到的潜在的 8.3%的脆弱性。但同样也没有发现直接证据,未知的矿池表现平均,时间戳早于我们的系统时钟 0.48 分钟。

下面的图表继续对比我们的本地时钟观察时间戳间隔,并对比特币和比特币现金加以比较,试图从视觉上识别任何违规。它们似乎显示,比特币时间戳一般与我们的本地时钟更加一致,而且时间间隔的波动更小。这可能仅仅说明比特币拥有较比特币现金更为强大的点对点网络,区块繁殖的速度更快,而非对时间戳有任何恶意操纵。

比特币现金 – 时间戳与我们的本地节点时钟之间的平均时间间隔(分钟)– 2019 年 10 月–( Y 轴切割以便于与比特币进行比较)

(资料来源:BitMEX 研究)

(注:橙色线是 50 区块移动均值)

比特币 – 时间戳和我们本地节点时钟之间的平均时间间隔(分钟)- 2019 年 10 月

(资料来源:BitMEX 研究)

(注:橙色线是 50 区块移动均值。X 轴是 2019 年 10 月)

我们找不到任何操纵时间戳或其他恶意挖矿策略的证据。比特币现金是一种少数派哈希率币种,因此在种程度上可能让哈希率更加不稳定。显性的周期性,也许是由用于挖掘最具赚钱的币的自动化系统的滞后,或其它某些更为良性的因素所致。

结论

想要解决比特币现金哈希率波动性这一潜在问题,可能需要硬分叉,并且该币种已经计划在几天内就进行硬分叉升级,但不包括针对上述问题的修复。所有修复在展开前都可能需要大量的开发工作和分析/讨论。因此,短期内不可能修复。但是,这一问题也许没那么迫切。

至于比特币现金,也许会考虑解决这一问题,我们建议对以下提议加以考虑:

  1. 合并挖矿–正如我们先前在 2017 年 11 月所说明的那样,启用与比特币合并挖矿可以增加比特币现金挖矿的稳定性,但比特币现金社区的部分人,可能因为对比特币的态度不那么友好而仍然不愿意采纳这种方式。我们认为,这种憎恨会随着时间的推移而消散。

  2. 采用比特币两星期的调整期 比特币现金可以恢复至比特币固定的两星期难度调整系统。这可能无法完全解决问题,但也许是更简单的解决办法。

  3. 减少区块时间 – 比特币现金可以重新启用1MB的区块大小限制,并将区块时间减少到1分钟左右。不过这可能无法解决哈希率的波动,由于区块时间间隔减小,所以无论如何区块都会显出合理地规律性。我们认为,与提高对区块大小的限制相比,该策略更直截地匹配比特币现金社区的目标,即无需等待如此长的确认时间,增加链上的吞吐量并提高可用性。

截至目前,哈希率波动性增加的问题似乎并不紧迫,而且只持续了一个月。至少对我们而言,2019 年 10 月波动明显突然增加,还是一个未解之谜。但如果这种情况持续,或有特定原因变得明显,则可能需要解决。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

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:意外通胀检测与警告系统

摘要:ForkMonitor 现已针对比特币执行意外通胀检测与警告系统。目前的区块奖励是 12.5 个比特币,这意味着每个区块产生的新比特币不应超过 12.5 个。现在一些 ForkMonitor 节点使用 gettxoutsetinfo 远程过程调用(RPC)计算每个区块币的总供应。如果币的总供应增加超过 12.5 个比特币,则警告系统启动。这一服务潜在地向网络参与者提供了在任意给定时间的比特币供应的额外保证。

(资料来源:ForkMonitor.info

概述

ForkMonitor 近期增加了一种新功能,即意外通胀检测。增加的这一功能针对的是比特币和 Testnet 比特币。系统通过定期加总全部未消费的交易输出(UTXO)值检查币的总供应。如果数值过大,则启动警告。比特币节点本来就应该检查币的供应,但这种情况仅仅是通过检查每个单独的交易不会产生未经认证的币,并没有宏观上对总供应的检查。所以 ForkMonitor 服务可针对比特币用户提供额外一层的安全和保护,还有早期警告系统——如果检测到问题,此系统能建议人们在其自己的节点上运行此类检查。

如果通胀符合预期,则网站上显示绿色标记。但如果发生了意料之外的通胀,将显示红叉与其他警告。

比特币核心钱包 (Bitcoin Core) 0.18.1 检测到意外通胀的图解

(资料来源:ForkMonitor.info)

请订阅推送,在发生意外比特币通胀的情况下收到提示。

币的供应检查机制

系统计划使用下列方法检查通胀:

  • 先前区块供应的币数变动—— 在每个区块链产生之后,系统都会检查币的总供应并在数据库保存数据。每产生一个新区块,就重新加总一次,而币的总供应将减去先前的数据。如果变动大于允许的区块奖励(现在是 12.5 个比特币,从 2020 年 5 月左右起是 6.25 个比特币,以此类推),就启动警告。
  • 跨多个节点版本的一致性——此外,系统还将检查参与通胀检查的所有节点在每个区块高度的总比特币供应是否一致。(在 ForkMonitor 网站上有说明)。

Gettxoutsetinfo 问题

我们在执行这一通胀检查功能时面临的一个主要挑战是,比特币核心钱包 (Bitcoin Core) 运行 gettxoutsetinfo 调用需要大量时间,一般是 2 分钟左右。这对ForkMonitor在执行上产生了几个挑战,例如在这两分钟期间显示什么,或是在进行计算的同时发现区块会怎样。例如,通胀检查可以向前运行的最大速率是每两分钟一个区块;如果连续发现多个区块,而他们之间的时间间隔不到两分钟,我们的检查可能失效一段时间。

Gettxoutsetinfo 远程过程调用 (RPC) ——图解大约 1800 万比特币的供应

 (资料来源:Bitcoin Core 0.18.0 “Gettxoutsetinfo” 调用输出)

有些人已经知道了这些问题,例如比特币开发者 Fabian Jahr 近期就表示:

[ gettxoutsetinfo 调用] 没有充分的用户经验,实际上调用需要几分钟才能响应,而且没有反馈

(资料来源:Fabian Jahr (Youtube))

2017 年比特币开发者 Pieter Wuille 向比特币开发邮件列表提交了一个可能的改进,他表示能够让 RPC 调用更快。

替换比特币核心钱包的 gettxoutsetinfo RPC 哈希计算。这目前需要占用 I/O 和 CPU 几分钟,因为它将整个未花费交易输出(UTXO)集进行序列化和哈希计算。滚动的哈希集将让这一过程即时完成,使得整个 RPC 对于完整性检查的可用性大幅改善。

(资料来源:Pieter Wuilles 2017年的邮件滚动的 UTXO 哈希集)

基于以上想法,Fabian 近期表示他致力于执行这一潜在修复,努力改善 RPC 调用。如果实现,对 ForkMonitor 当然会有帮助。 

比特币 2018 年通胀缺陷 (CVE-2018-17144)

ForkMonitor 受到了 2018 年 9 月这一事件极大的启发,当时发现比特币核心钱包存在缺陷, 会让矿工除了正常的区块奖励外,莫名其妙创造出币来。在发布修复程序前,此缺陷影响了比特币核心钱包从 0.14.0 到 0.16.2 的各版本。(0.14.X 节点只是崩溃,而后面的节点会接受具有意外通胀的区块)。

成功利用此错误可能会对网络造成灾难性的后果,例如比特币的供应本来已经膨胀到 2100 万以上,或者会发生规模庞大的回滚,侵害众多用户和企业所依赖的安全性。

ForkMonitor 被启用以缓解这些风险。如果今天还存在这个缺陷,我们的系统应能够用三种方式对其检测:

  • ForkMonitor 跨越多年开发、可运行多版本的比特币核心钱包。如果新引入的缺陷导致意外通胀或未经授权的支付,则早前的节点应当能检测到并将该区块标为无效,触发警告系统。 
  • 本网站还运行类似 bcoin、btcd 和 Libbitcoin 这样的比特币的独立执行。如果比特币核心钱包有漏洞,允许意外通胀或未经授权的支付,只要没有独立执行同一漏洞,其他客户应可将该区块标为无效,触发警告系统。
  • 自 2019 年 10 月起,ForkMonitor 还直接检查每个区块的币的总供应。在出现意外通胀的情况下,即使发生所有的节点都将该区块标为有效这一不太可能的情况,仍将触发警告系统。而即使节点将区块标为无效,通胀检查系统也有用,因为它可以帮助用户及时确定原因。

独立执行

正如我们在 2018 年 10 月的文章《与比特币核心钱包的竞争》中所说的那样,竞争性执行尤其是独立执行有其优缺点。我们所提到的独立执行的一个关键优点是,比特币核心钱包或参考执行中可能存在缺陷,而独立执行中则没有。

考虑上述原因,我们热切期待将三个独立执行(bcoin、btcd 和 Libbitcoin)中的一个添加到币的总供应通胀检查系统中。这些执行所使用的计算币的总供应量方法可能独立于比特币核心钱包所使用的方法之外,后者应额外保证数字的正确性。

结论

这一新的服务可能没有解决关于检测意外通胀的全部潜在问题。例如, gettxoutsetinfo 检查中可能存在缺陷。除此之外,检查意外通胀和区块有效性的不同机制之间可能并非真的相互独立。甚至独立的比特币执行也可能无意间从比特币核心钱包复制了有缺陷或错误的概念。但是,我们认为,这种宏观通胀检查服务可能是对网络安全性的有用补充。  

在此提醒,ForkMonitor 网站是开源的,可以随时参与、分叉项目或复制本网站。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

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.

比特币基金会

摘要:在这篇文章中,我们回顾了比特币的历史,着重介绍“比特币基金会”——这一比特币生态系统中最著名的组织之一。我们考察基金会的起源,并审视其在治理、透明度和财务方面的缺陷,这些是比特币社区合法性尽失的罪魁祸首。我们的结论是,鉴于社区中某些部分需要高标准的治理和透明度,一个包罗万象的基金会恐怕具有先天的劣势,持续不断的丑闻破坏了基金会的品牌,以至于其职责必须由其他机构来执行。

基金会的起源

2018 年 7 月的文章重温了 2011 年 MtGox 公司当时对投资者大搞阴谋诡计和破产的命运,这是第二篇回顾丑闻频发的比特币历史的文章,时间将我们带回到 2012 年 7 月比特币基金会成立之时。该基金会有七个创始会员,如果排除非正常列为创始成员的 Satoshi 外,则有六个成员。

比特币基金会创始会员

  • Gavin Andresen,比特币开发者
  • Peter Vessenes,CoinLab CEO
  • Charlie Shrem,BitInstant CEO
  • Roger Ver,MemoryDealers CEO
  • Patrick Murck,Engage Legal负责人
  • Mark Karpeles,MtGox.com CEO
  • Satoshi Nakamoto,白皮书《比特币:点对点电子现金系统》作者

(来源: GitHub

该基金会的目标从来没有完全清晰过,原章程说明如下:

在使用此类系统时,公司应同时促进和保护比特币分布式数字货币和交易系统的去中心化、分布和私有属性,以及个人选择、参与和财务隐私。公司还应进一步要求属于公司宗旨范围内的所有分布式数字货币是去中心化、分布式和私有的,并支持个人的选择、参与和财务隐私。

(来源: GitHub

基金会的使命 – 2013 年 6 月

(资料来源:比特币基金会

在实际操作中,基金会的作用表现如下:

  • 支付比特币开发者 Gavin Andresen 的工资
  • 安排比特币会议
  • 向监管机构推广比特币

2012 年和 2013 年,该基金会越来越受欢迎,吸引了来自比特币社区的成员,包括知名的开发者、企业和社区成员。

个人终身会员的公开名单

(来源: 比特币基金会

截至 2013 年 9 月的公司会员

(来源: 比特币基金会

该基金会由会员费资助——初始会员费用表如下。但随着比特币价格的升值,按比特币计的价格确实在 2013 年开始下降。

初始会员费用表

(来源: GitHub)

很多人认为,因为有会员订购费,该基金会有可观的财务资源可花费在其使命上。

2013 年 4 月会员供款的大致底限(假设按初始费率)

  • 2 位白金行业会员 * 10,000 比特币 = 20,000 比特币
  • 7 位白银行业会员 * 500 比特币 = 3,500 比特币 
  • 175 位终身会员 * 25 比特币 = 4,375 比特币
  • 总收入来源 = 27,873 比特币   

(来源: BitMEX 研究)

正如我们稍后将在本报告看到的那样,该基金会在 2012 年底仅拥有约 8,000 个比特币,规模依然强大,但余额却让人大跌眼镜。由于会员订购的时间尚不清楚,我们上面的估算还有可能高估。

基金会董事会 

基金会的治理结构非常复杂和神秘。会员有三类: 

  1. 创始人 
  2. 个人  
  3. 公司 

董事会最初由五名成员组成,一名由创始人提名,两名由个人提名,两名由公司成员提名。每名被任命者的任期应该为 3 年。在基金会成立之初,全部五名董事会成员均由创始人指定,且所有董事会成员均为创始人,但 Jon Matonis 除外。

比特币基金会董事会成员(2012 年至 2019 年)

(来源: 比特币基金会网站,BitMEX 研究)

批评者可以攻击的一点是,治理结构给予了最初的创始人太多的权力,组织的新成员理应能够像创始人那样平等地加入。

董事会选举

第一次董事会选举在 2013 年举行,Meyer Malka 赢得了行业席位,Elizabeth Ploshay则在个人会员投票中胜出。  

董事会选举 – 行业席位(2013年) – 胜出者:Meyer Malka

(来源: 比特币基金会

董事会选举 – 个人席位(2013年) – 胜出者:Elizabeth Ploshay

(来源: 比特币基金会)

2014 年初,两位创始行业席位的持有人辞职。Charlie Shrem 于2014年1月28日辞职,他两天前因洗钱和与无证汇转资金相关的违法行为在肯尼迪国际机场被捕。Charlie 最终于2014年12月被定罪并被判处两年监禁。Shrem 犯下的重罪主要涉及他继续为一名在 BitInstant Bitcoin 购买服务的用户提供客户支持,尽管据称他知道客户想要比特币是为了在 Silk Road 电子商务平台上购买毒品(或者客户打算向其他毒品购买人提供比特币,于是持有者又少了一层)。另一个行业席位的持有者 Mark Karpeles 于 2014 年 2 月 24 日辞职,原因是 Mark 担任 CEO 的 MtGox Bitcoin 交易所破产和清算。

接着 Brock Pierce 和 Bobby Lee 被选为两位替任的行业指定董事会成员。

董事会选举 – 行业席位( 2014 年) – 胜出者:Bobby Lee 和 Brock Pierce

(来源: 比特币基金会)

任命 Brock Pierce 为董事被证明是有争议的,一些人声称基金会应该在让 Pierce 上任之前完成更多的审查。对这位在《野鸭变凤凰》和迪士尼的《第一公子》中扮演角色的前儿童演员的指控,与他在 20 世纪 90 年代后期涉嫌参与对儿童的性虐待有关。Pierce 虽然当时只是个青少年,但却是互联网视频创业公司 Digital Entertainment Network (DEN) 的执行官和联合创始人,该公司曾被指控主办数个可能发生性虐待的派对。这些指控导致联合创始人兼 CEO Marc Collins-Rector 以及 Pierce 先生从 DEN 辞职,据说逃往了西班牙。Collins-Rector 先生最终对与虐待儿童有关的罪行表示认罪,据路透社报道,法庭记录显示,Pierce 先生支付了 21,000 美元来解决相关的民事诉讼,而其他索赔则被撤销,文章还指出 Pierce 否认了这些指控。

到 2014 年底,重压之下的基金会对其治理进行了下列改进:

  • 董事会成员任期从 3 年减至 2 年  
  • 取消创始人董事会席位 
  • 去掉了创始人类别

基金会的财务状况

下表是对基金会大部分成员会费被耗尽这段时期( 2012 年到 2014 年)财务状况的基本分析。数据根据的是该组织的 IRS990 表格。在董事会的薪酬方面,披露似乎相当给力。大多数董事会成员除了担任高管之外,没有获得任何报酬。向 Gavin 支付薪酬是该组织的主要目标之一,对 Gavin 的薪酬的披露看起来合理清晰而且恰当。

  2012 年 2013 年 2014 年
董事薪酬   
Gavin Andresen 15,000 美元 209,648 美元 147,917 美元
Patrick Murck  57,592 美元 115,001 美元
Lindsay Holland  160,652 美元 
Jodie Brady   141,667 美元
Jon Matonis (承包商)  31,250 美元 137,500 美元
其他薪酬支出 14,013 美元 118,047 美元 582,782 美元
总薪酬支出 29,013 美元 577,189 美元 1,124,867 美元
会议支出  418,413 美元 825,525 美元
其他支出 32,608 美元 472,302 美元 1,335,210 美元
总支出 61,621 美元 1,467,904 美元 3,285,602 美元
    
基金会收入   
会员费  358,007 美元 335,723 美元
会议收入  377,883 美元 584,308 美元
其他  64,803 美元 35,728 美元
总收入 159,359 美元 800,693 美元 955,759 美元
    
盈余 /(亏空) 97,738 美元( 667,211 美元)( 2,329,843 美元)
    
披露的比特币数据   
比特币(年终按美元计价) 107,549 美元 4,512,316 美元 703,843 美元
比特币销售所得  749,157 美元 569,728 美元
实现的比特币收益 /(亏损)  77,148 美元( 40,316 美元)
未实现的比特币收益 /(亏损)  5,195,589 美元( 1,966,768 美元)

(来源: IRS 990 Forms, BitMEX 研究)

有关该基金会当时财务状况的主要批评似乎有两方面: 

  1. 2014 年的支出大幅增加,令该组织的储备几乎消耗殆尽。 
  2. 在基金会的比特币余额方面缺乏透明度 

至于第一个批评,担心似乎确实有些道理。2014 年薪酬支出增长 81%,2014 年会议出现重大净亏损,而且其他支出显著增加。至于其他 130 万美元的支出,我们在下面提供了细目,读者可以判断超支的程度。与 2017 年和 2018 年首次代币发行(ICO)时过多的泡沫相比 ,支出是适度的,下面的总支出可能只相当于最大手笔的 ICO 某一次营销活动的零头而已。但部分基金会成员显然希望他们的资金使用能更加谨慎。主要问题似乎是,这一预期并没有事先明确提出来。不管你怎么看,实际上到 2015 年初,该基金会几乎耗尽了财务储备,从这个程度上讲,其财务管理不善。

2014 年其他支出明细

其他专业服务  307,767 美元
法律费用  200,003 美元
差旅 584,308 美元
信息技术 158,021 美元
专业的活动费用 115,401 美元
公共关系 93,241 美元
汇兑损失 73,362 美元
会计 50,556 美元
办公室费用 39,071 美元
补助金(外国) 37,314 美元
坏账 18,500 美元
对关联方的支付 18,002 美元
场地租金 17,949 美元
补助金 14,000 美元
广告 9,218 美元
保险 3,639 美元
其他20,000 美元
其他总支出 1,335,210 美元

(来源: 比特币基金会 IRS 990 form)

该基金会在比特币结余方面缺乏透明度也令人关切。每年年底 IRS990 表格都披露持有的比特币的美元价值、实现的比特币收益和未实现的比特币收益。根据这一资料,我们计算如下:

BitMEX 研究的比特币计算 2012 年 2013 年 2014 年
年终比特币价格 13 美元 754 美元 320 美元
年终隐含的比特币结余8,2165,9851,381
比特币结余变动 ( 2,232 )( 4,604 )
隐含的出售价格  336 美元 124 美元
实现的比特币收益 /(亏损)  71,945 美元( 2,901,314 美元)
未实现的比特币收益 /(亏损)  4,433,979 美元( 599,354 美元)
    
最低比特币价格数据   
年度最低比特币价格 4 美元 13 美元 268 美元
隐含的比特币销售所得  29,011 美元 1,233,739 美元
实现的比特币收益 /(亏损) ( 201 美元)( 2,237,303 美元)

(来源: IRS 990 Forms, BitMEX 研究)

通过 IRS990 表格中披露的信息引导,我们发现了以下明显有关比特币的出入:

  • 鉴于比特币捐赠量,基金会在 2012 年末比特币结余较低(参见本报告前面的数字 28,000 个比特币)似乎是合理的。
  • 基金会披露的 2013 年未实现的比特币收益为 520 万美元,但根据年度价格变动和计算的年终结余,我们算出未实现的收益仅有 440 万美元。 
  • 基金会披露 2014 年未实现的比特币亏损为 200 万美元,但根据年度价格变动和计算的年终结余,我们计算出未实现的亏损仅为 60 万美元。  
  • 基金会在 2014 年披露的比特币销售所得为 569,728 美元,但即使假设全部比特币都以当年最低的交易价格售出,考虑到比特币结余大幅减少了 4,600 个,销售所得本应为 120 万美元。

虽然存在贪污指控,但我们不认为这些披露表明存在任何犯罪。基金会可能在整个期间都收到和支出比特币,因此不太可能有出售比特币的清晰财务记录。与此同时,针对此类组织报告金融资产方面已实现和未实现的收益相关的规则并不严格,基金会在计算方法上具有一定程度的自行决定权。因此,我们认为文件本身并未显示存在不当行为。不过文件虽然没有清楚地说明比特币结余的变动情况,但董事会可以提供解释。

一些成员明确希望提高透明度,并希望向董事会询问资金情况,但他们从未获得过这样的机会。引述比特币评论员 Andreas Antonpoulous(当时是基金会委员会主席)下面的话,反映了当时社区中很多人的看法。

你说他们筹到了资金。那些资金在哪里?谁来控制这些资金?最后一次审计是在什么时候?真的有偿付能力吗?还是说,所有这些资金都消失在一个大黑洞里?只记得之前谁是领导,现在谁是领导就可以了吗?他们之前的道德水平如何?我要说的是,如果基金会在接下去的某个时间爆发巨大的贪污问题或者资金被盗,无论说与不说,都不会让人意外。这是必然会发生的,因为这些事不是由于行为不端者的技术失误而发生的,而是由于失败的领导。基金会恰恰是失败领导的代表。

(来源: Andreas Antonopoulos – 2014 年 3 月 – Let’s Talk Bitcoin Episode 95)

卷入 MtGox 丑闻

更为糟糕的是,还有一些关于该基金会牵涉 MtGox 破产的说法: 

  • MtGoX 的 CEO Mark Karpeles 是该基金会的创始人和创始董事会成员,而该公司本身是该基金会的高级会员。 
  • 创始会员 Roger Ver 曾在 MtGox 倒闭前不久向该交易所的客户公开保证该交易所的偿付能力。
  • 2013 年,由于合作失败,基金会的创始主席 Peter Vessenes(他很可能有权获得 MtGox 的部分股权)卷入了与 MtGox 之间的各种法律纠纷。2013 年 Peter 的公司 Coinlab 起诉 MtGox 要求获得 7500 万美元赔偿。截至 2019 年 8 月,Peter 目前对 MtGox 的索赔总共高达 160 亿美元( 1.6 万亿日元), 这一庞大的数额足以有效阻止 MtGox 向客户作出分派,至今仍是债权人受挫的一大缘由。

Andreas 将基金会的情况与 MtGox 做了如下比较: 

它的问题可以直接归结于领导上的彻底失败,这是一种完全封闭、狭隘、傲慢、包庇、缺乏沟通的领导风格。其中有 Karpeles 本人,当然董事会的其他几位也难辞其咎,领导方式如出一辙。这家基金会就是 Gox of Foundations。我很意外它没有在 Gox 丑闻之后爆雷,毕竟当时的环境下出现了大量的重大矛盾。

但是过多强调 MtGox 与基金会之间的联系也许不公平,毕竟生态系统很小,而且 MtGox 是占主导地位的交易所,所以某种程度上有一定的联系是不可避免的。 

阿姆斯特丹会议( 2014 年 5 月)  

2014年5月,比特币基金会组织了迄今为止该领域内规模最大的一次会议。这是(至少是我们参加的)第一次大会,当时已经有了后来 2017 年到 2018 年的风范:有增无减的热情、对基础技术不切实际的预期、昂贵的餐食,和数不清的新企业的展台,但他们带来的计划都似乎没有什么商业意义。如上文数据所示,尽管票价高达 800 美元,但大会似乎产生了约 250 000 美元的净亏损。

会议分为两个板块:一个是主展厅的商业板块,另一个是比特币基金会年会(或技术线),在酒店会议室的走廊上举行,基金会成员可以免费进入。在技术讨论之后,是基金会成员的会议。  

(来源: Eventbrite

记者 Ryan Selkis(现任 Messari 创始人兼首席执行官)在这次活动上是重要的终身会员之一,他试图让基金会承担责任。在年会上,他向基金会董事会成员提出了几个具有挑战性的问题,包括要求提高透明度。直到那时为止,大部分的争论和抱怨都是在网络论坛上进行的,这种真实世界的互动标志着一个重大的新变化。在应对他的挑战时,一名董事会成员是这样说的: 

我们可以花时间精力尽可能做到透明,更上层的资源也可以透明化,或者我们也可以在董事会层面花更多的时间来保证我们(拥有)资源,把比特币做大。这是有可能的,但现在说实话,我们的处境是,比特币并未获得良好的认识。至少从我作为一名董事会成员看来,所要求的优先事项更侧重于[让比特币做大]

(资料来源:比特币基金会 2014 年年会

从这一回复中可以明显看出,无论出于何种原因,一些董事会成员选择了不处理透明度和治理方面的关切,这令一些成员感到沮丧,并更加确信董事会的不当行为。 

区块链选举( 2015 年 2 月)  

考虑到该基金会所面临的问题以及社区对透明度、治理和该基金会宗旨的关切,这是一系列相对重要的选举。候选人的人数众多,候选人之间的辩论质量也相当不错,例如有一个关于选举的大家谈比特币的博客。 

基金会决定在区块链上进行 2015 年个人董事会席位的选举。时任选举委员会主席的 Brain Goss 表示: 

我相信使用区块链存储紧凑证明/散列的概念(根据市场的指示),而且我非常相信投票的透明度经得起任何人的验证

然而,区块链的投票过程并不顺利,出现了下列问题:    

  • 第一轮投票使用的是 Helios 投票系统。但是没有候选人获得超过 50% 的选票,所以按章程规定,需要第二轮投票。接着,该基金会做出了一个怪异的决定,在两轮投票之间将投票平台换到 Swarm ,这个决定遭到了普遍反对。尽管最终在 Swarm 上启动了最后一轮投票程序,但在投票期间,该基金会在投票期决定换回到 Helios ,取消了 Swarm 的投票
  • 决定在第一轮投票后将候选人人数减少到 4 人,这似乎是非常武断的。 
  • 登记投票的程序被普遍认为繁琐而复杂,部分候选人有抱怨。

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

董事会选举——个人席位第一轮(2015 年)

(来源: Helios voting system records)

董事会选举——个人席位最终轮(2015)——胜出者:Oliver Janssens 和 Jim Harper

(来源: 比特币基金会)

在投票争议之后,Patrick Murk 对《比特币》杂志表示:

这显然触动了人们的神经,他们认为区块链技术只应该用于传输比特币,而非类似投票这样的其他(用途)。[这]引发了关于人们如何使用区块链的争论

免去董事和董事会选举结束( 2015 年 12 月)

2015年12月,新当选的两名董事会成员 Oliver 和 Jim 被其他董事会成员免职,理由是他们对基金会未来的最佳发展方式存在分歧。Oliver 和 Jim 近期在个人成员的竞争性选举中获得成功,积累了相当大的民主授权。与此同时,Elizabeth 和 Meyer 的两年任期已经届满,而 Brock 和 Bobby 是由行业而非个人选出的。因此,从个人成员的角度来看,Oliver 和 Jim 是仅有的两名负有重大使命的董事会成员,但他们却被免职。随后基金会违反章程,决定不再进行任何董事会选举。正如执行董事 Bruce Fenton 所说:

我曾经认为公开、开放的选举是一件了不起的事。我现在不大相信了……遗憾的是,我们没有时间或资源进行更多处理。

(资料来源:比特币基金会论坛

我们认为这种逻辑很难自圆其说,因为很多问题是由于董事会对个人成员明显缺乏责任感所导致的。Elizabeth Ploshey 是唯一一位由在董事会有效工作过一段时间的个人成员所选出的董事会成员。如果该基金会真的想重整旗鼓,本可以让 Oliver 和 Jim 复职,并允许进一步的选举来替换其他本应当离开的董事会成员。但是恰恰相反,基金会甚至决定与成员拉开距离,避免这种问责可能带来的挑战,结果也就失去了它剩余的全部的合法性。

在那之后,从 2015 年到 2019 年,从先前选举中落败的候选人中任命了4名新董事会成员,但这次任命是由董事会而非成员做出的。

结论

该基金会至今仍然存在,现在是 Brock 担任主席,而 Bobby 担任副主席,尽管他们的任期早已届满,新的选举却遥遥无期。该基金会没有重要的财务资源(但基本上无关紧要)。之前从事的活动现在由其他机构在进行,例如Coin Centre负责对监管机构进行游说,而比特币开发则由 Chaincode Labs 、 Blockstream 、麻省理工学院 (MIT) 的 DCI 等机构和其他行业参与者资助。在许多方面,这篇文章的结论是不言而喻的:比特币根本不需要基金会,没有基金会它会更强大,任何类似这样无所不包的基金会都注定会失败。

人们对基金会缺乏透明度的愤怒,暴露了比特币(现在是加密货币)社区成员之间在预期和文化方面的一些关键分歧。某些比特币持有者,尤其是那些自该基金会成立之初就参与其中的人,通常都深谙计谋、生性多疑,他们期望极高的透明、问责和财务审慎程度。而基金会似乎误判了这些期望,失去了社区的支持,以失败而告终。但相对而言,与从 2014 年左右开始并在 2018 年初达到代币发行鼎盛时期的程度相比,比特币基金会的财务问责和透明度几乎又无可指摘。加密货币社区的部分成员(并非所有的新成员)有着截然不同的预期,他们更关注于他们认为的改变游戏规则的技术、热衷于改变世界和变得超级富有,而不是治理。即使是在这种新的环境下,基金会的品牌也受到了无法挽回的损害,再也没有找到自己的用武之地。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

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

闪电网络(第 4 部分) – 全面采取瞭望塔功能

摘要:BitMEX 研究已将其闪电节点升级至包含瞭望塔功能。瞭望塔功能是可连接至另一友好节点的机制,即使您处于离线状态,其也可为您监控您的闪电通道,防止不诚实的交易对手窃取您的资金。我们的试验成功证明了瞭望塔是有效的,至少在我们的例子中是这样。振奋人心的是,在理论上已经存在多年的“瞭望塔”概念,现在已经在实践中发挥了作用。

(来源:Alcatraz, flickr

概述

该瞭望塔部分紧随我们之前关于闪电网络的三篇文章:

  1. 闪电网络(第 1 部分) – 动机
  2. 闪电网络(第 2 部分) – 路由费经济
  3. 闪电网络(第 3 部分) – 正义在何处?

2019 年 6 月 29 日,发布了 LND 0.7.0(闪电实施),其中包括了瞭望塔功能。瞭望塔是第三方闪电节点,可以检测到不诚实的一方是否试图窃取资金,然后广播正义交易的消息,将资金发回诚实的一方(即使诚实性节点处于离线状态)。

瞭望塔功能有两个模式

 

客户/瞭望塔用户

服务器

说明

客户连接到瞭望塔服务器。闪电通道状态发生变化时,最新的通道状态数据会被发送至瞭望塔服务器。如果通道中断,瞭望塔可广播一条正义交易的消息,并将资金发回诚实性节点的线上钱包。

瞭望塔服务器不需拥有任何闪电通道或支付任何费用。服务器连接到闪电客户,并为其监控客户的闪电通道。

操作细节

要将节点连接到瞭望塔服务器,需要将以下行添加到闪电配置文件中:


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

其中公共密钥和IP地址由瞭望塔服务器提供。

要激活瞭望塔服务器,需要将以下行添加到闪电配置文件中:


> watchtower.active=1


然后,可以运行以下命令:


> lncli tower info


然后,瞭望塔服务器应显示瞭望塔公共密钥(不同于闪电节点公共密钥)。瞭望塔客户需要此密钥。由于可能存在服务被拒的风险,目前不建议发布瞭望塔公共密钥。

可以通过查看日志来检查瞭望塔的运行状态。

一个节点可同时作为瞭望塔服务器和客户。如果运行两个节点,则每个节点都可以是另一个节点的瞭望塔服务器。BitMEX 研究目前有三个正在运行的闪电节点,这些节点在一个环形配置中互相监控。

瞭望塔成功测试

2019 年 7 月 30 日,BitMEX 研究成功测试了瞭望塔系统。就像我们上一篇正义交易一样,我们试着能骗过自己,但这次我们用的是瞭望塔。振奋人心的是,瞭望塔功能正常运转,将会让那些不诚实的人受到严惩。

为了进行此测试,我们需要运行三个节点:

  • 非诚实性节点 – BitMEXThief
  • 使用瞭望塔服务的节点 – BitMEXTowerClient(瞭望塔服务的用户)
  • 瞭望塔自身节点 – BitMEXResearch

人工构建一个瞭望塔正义交易

(来源:BitMEX 研究)

我们的瞭望塔所广播的最终达成的正义交易可在这里查看。

结论

所有 BitMEX 研究的闪电节点现都处于瞭望塔的保护之下。虽然瞭望塔在安全性方面有了很大的改进,但在我们看来,比不诚实通道中断更大的问题是,闪电节点的内存可能会意外丢失或毁坏—在这种情况下,节点可能会丢失最新的通道状态。虽然我们在这个领域已经有了改进,但瞭望塔无法借助静态通道备份 (SCBs) 解决这个问题。使用 SCBs 的情况下,只要备份后没有创建新的通道,所有资金都是安全的。

通过对瞭望塔的成功测试,我们更加确信了闪电网络的牢固性。振奋人心的是,像瞭望塔这样多年讨论于理论上的概念,终于成为了现实。然而,要使闪电网络更加牢固、可靠,我们还有很长的路要走。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

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.

闪电网络 (第三部分) — 正义在何处?

摘要:在对闪电网络的第三次研究中,我们研究了闪电通道关闭方案以及惩罚诈骗者并阻止他们窃取资金的激励措施。此惩罚机制叫做 “正义交易”。我们对如何任意构建 “正义” 方案进行了解释,并在比特币网络上提供有关此类交易普遍性的数据。自 2017 年底推出闪电网络以来,我们已经确定了 241 笔正义交易,涉及 2.22 个比特币的价值。

(闪电袭击新加坡市)

概述

2018 年 1 月 我们对闪电网络背后的动机进行讨论以及 2019 年 3 月 对闪电网络路由费用进行经济学分析之后,闪电网络的第三部分着眼于通道关闭和为了防止非诚实性闪电节点通过广播早期的通道状态来窃取资金所提出的激励措施。

应该注意的是,根据设计,当窃贼试图通过闪电网络窃取资金时,如果被抓住,他们不仅会失去正在窃取的资金,而且会失去相关通道中的所有资金。期望这种 “惩罚” 将起到威慑作用,因此有时被称为 “正义” 手段。

四种关闭闪电通道的方案

一般来说,打开闪电通道比关闭它们更简单,因为只有一种方式打开闪电通道,就是双方之间的互动沟通。另一方面,在评估通道关闭时,需要考虑四种不同的方案,如下面的决策树中所述 (参见图 1)。

图 1 – 闪电网络通道关闭类型 – 决策树

(资料来源:BitMEX Research)

图 2 – 解释的四种关闭闪电通道的方案

关闭类型 描述

链上技术细节和示例交易

这是最常见的方案。


当诚实性节点启动通道关闭时,而通道另一侧的节点在线并进行通信,就会发生合作关闭。


资金根据最新的通道状态分配给各方在链上钱包。

合作关闭只需要一项链上交易。


输入是使用 “正常” 的 2 / 2 多重签名脚本来进行兑换,并发送到两个输出,每个输出属于各相关方,余额以最新的通道状态为准。

此项交易很难识别为闪电网络交易,因此它是三种通道关闭类型中最私密的。


示例关闭:

当诚实性节点在不直接与通道另一侧的节点通信的情况下启动关闭时,就会发生非合作非违约的关闭。


资金根据最新的通道状态分配给各方的链上钱包。

这两种不同的经济方案由一种技术链上方案表示。


这种方案需要两笔链上交易。 

首先,资金是使用 2 / 2 多重签名见证人来进行兑现,并发送到两个输出。没有启动关闭的节点根据通道关闭方所声称的责任来分配资金,而另一组资金会被发送到输出,该输出可以通过使用 OP_IF 或 OP_ELSE 脚本来兑现。

在第二项交易中,发送到 OP_IF 脚本的资金由发起通道关闭的一方使用比特币脚本的 OP_ELSE 分支进行认领。

示例关闭:

当非诚实性节点通过广播早期的通道状态试图从通道另一侧的节点窃取资金时,就会发生非合作违约非正义的关闭。

非关闭节点在锁定时间段内不检查网络,通常在24小时内,并且不广播正义交易。因此盗窃从而成功了。


资金根据早期的通道状态分配给各方的钱包,这使非关闭方损失资金而非诚实性通道关闭方成功窃取资金。

当非诚实性节点启动通道关闭时,而不直接与通道另一侧的节点通信,就会发生非合作违约正义的关闭。


非关闭节点在锁定时间段内检查网络,并创建一项正义交易,从而导致盗窃失败。


这个潜在的窃贼会受到惩罚,其所有的资金都流向诚实性的非关闭方。

在正义方案中,都需要两笔链上交易。 


在第一项交易中,资金是使用 2 / 2 多重签名见证人中来进行兑现,并发送到两个输出。没有启动关闭的节点根据通道关闭方所声称的责任来分配资金,而另一组资金被发送到输出,该输出可以通过使用 OP_IF 或 OP_ELSE 脚本来兑现。


在第二项交易中,未启动关闭的诚实性节点使用 OP_IF 分支认领发送到 OP_IF 脚本的所有资金。


这是三种通道关闭类型中最容易暴露的,其隐私级别为最低级。



示例关闭:

如何创建正义交易?

在下面的任意方案中,我们使用以下步骤手动创建了一项正义交易: 

1. 使用别名 “BitMEXThief” 来建立一个新的闪电网络节点 (
LND) 并使用 BitMEXResearch 闪电节点打开一个价值 50 美元(400,000 聪)的通道 
2. 关闭 BitMEXThief 节点并备份 .lnd 目录
3. 重新启动 BitMEXThief 节点,向 BitMEXResearch 支付 25 美元 (200,000 聪) 的闪电交易。通道现已平衡,两个方向均为 25 美元
4. 再次关闭 BitMEXThief 节点
5. 关闭 BitMEXResearch 闪电节点(防止其向窃贼节点广播最新的通道状态)
6. 将 BitMEXThief 节点恢复到通道重新平衡之前的状态,即步骤 2 中的状态
7. 在恢复的 BitMEXThief 节点上,尝试使用其早期状态来关闭通道,并认领全部金额 50 美元 (
400,000 聪) 到 BitMEXThief 节点的链上钱包。
8. 重新启动 BitMEXResearch 节点。然后,该节点会自动检测到企图盗窃的行为,并广播“正义
交易”,将 50 美元(减去费用)的全部金额发送至其链上钱包。窃贼将受到惩罚,失去通道内的所有资金。请注意,窃贼试图盗取 25 美元,但最终失去了其拥有的全部 50 美元。

上述实验成功实现,确保了闪电网络能起到作用,警示用户如果你试图偷窃,你将受到惩罚。

网络正义交易数据

在进行了我们自己的正义交易之后,我们研究了此交易的特征(使用 OP_IF 分支兑换输入),并在比特币区块链上搜索其他正义交易。我们确认了 241 笔似乎都是正义通道关闭的交易,其中最早可追溯到 2017 年 12 月。来自闪电网络实验室的 Alex Bosworth 先生创建了一个识别正义交易的工具,它可能比我们的基本搜索方法更强大。

图 3 – 正义交易数量 – 月度

(资料来源:BitMEX Research)

(注意:数据可能包含假阳性)

图 4 – 正义交易中的赎回价值 – 月度(比特币)

(资料来源:BitMEX Research)

(注意:数据可能包含假阳性)

我们确定的正义交易的交易投入总计为 2.22 个比特币,在 2019 年 2 月达到月度总投入的高峰,约为 0.67 个比特币,如上图 4 所示。这并不意味着盗窃者没有成功窃取 2.22 个比特币的投入额,因为非诚实性节点惩罚窃贼的金额可能大于他们试图窃取的价值(我们不知道最新的通道状态)。这 2.22 个比特币代表诚实性非通道关闭节点索赔的总资金,其中一部分是最初非诚实性节点拥有的资金,另一部分是他们试图窃取的价值。

也有可能在这 241 笔正义交易中的大多数交易都并不具有非诚实性,例如,一项交易可能是测试系统的用户,其中同一个用户拥有相关的两个闪电节点。例如,BitMEX Research 参与了 241 笔正义交易中的 5 笔,因为 BitMEX 拥有所有节点和资金,所以是没有受害者的。

在 241 笔正义交易里的价值仅才略高于 2 个比特币,这相对于闪电网络的规模而言,其价值是相当小的。闪电网络统计网站 1ml.com 表明目前有 940 个比特币被锁定在 32,951 个通道中。因此,过去 18 个月的正义交易总数仅为目前闪电通道数量的 0.7%。

结论

为了使闪电网络成为一个强大、可靠和可扩展的支付系统,正义机制需要有效地威慑和防止盗窃。然而,最佳正义率很难确定,如果值太高,表明盗窃成功率很高,而正义的威慑作用可能还不够。如果其值太低,可能意味着没有人试图盗窃,从而增加了用户不采取监控通道措施的风险。这可能导致未来大型系统性通道发生盗窃的风险增加。

目前,至少根据我们分析的数据,迅速发展的闪电网络上似乎存在合理的正义实现程度。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

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.