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.

HDR Global Trading Limited 向比特币开发者提供 60,000 美元的赠款

继 2019 年 5 月 28 日我们宣布捐赠给麻省理工学院数字货币计划之后,我们很高兴宣布向比特币核心贡献者 Michael Ford (即 fanquake) 提供 60,000 美元的赠款。Michael 自 2012 年以来一直是比特币的贡献者,最近被加入到比特币核心软件项目的维护者名单中。

HDR Global Trading Limited (拥有并运营 BitMEX 加密货币交易平台) 以支持比特币开发和工程为荣,旨在提高比特币的稳健性,可扩展性和隐私性。这项拨款是非独占的,需要 Michael 将其用在比特币核心开发工作上。我们很高兴成为 Michael 作为比特币核心维护者期间的第一个财政支持者。

HDR Global Trading Limited 的首席技术官兼联合创始人 Sam Reed 就这项拨款发表了以下评论:

HDR Global Trading Limited 与加密货币领域的所有其他公司一样,在很大程度上依赖于致力为比特币使命和理念的编码人员(主要是志愿者)的工作。这项工作既困难又苛刻,而且经常吃力不讨好。我们认为,企业有责任回馈他们受益的项目 – 他们的商业模式源于此。如果没有尽心尽力的 OSS 开发人员为我们的操作系统、网络服务器、操作工具和比特币本身提供数百万免费工时,那么 BitMEX 交易平台就无法构建。我们不会忘记这份礼物。因此,HDR认为,在无附加条件的基础上提供的这项拨款,只是为所有人的利益而持续致力于支持比特币和其他 OSS 项目的一小部分。

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

BitMEX (www.bitmex.com)

HDR Global Trading Limited Provides US$60,000 Grant to Bitcoin Developer

Following on from our 28 May 2019 announcement of a donation to the MIT Digital Currency initiative, we are delighted to announce a US$60,000 grant to Bitcoin Core contributor, Michael Ford (AKA fanquake). Michael has been a Bitcoin contributor since 2012 and has recently been added to the list of maintainers for the Bitcoin Core software project.

HDR Global Trading Limited (which owns and operates the BitMEX cryptocurrency trading platform) is proud to support Bitcoin development and engineering, aimed at improving Bitcoin’s robustness, scalability and privacy. The grant is non exclusive and requires Michael to work on Bitcoin Core. We are pleased to be Michael’s first financial supporter during his time as a Bitcoin Core maintainer.

Sam Reed, CTO and co-founder of HDR Global Trading Limited, made the following remark about the grant:

HDR Global Trading Limited, like all other companies in the cryptocurrency space, relies heavily on the (mostly-volunteer) work of coders dedicated to the mission and ideals of Bitcoin. This work is difficult, demanding, and often thankless. We believe it is the duty of corporations to give back to the projects from which they benefit – and from which their very business model stems. Without the millions of free man-hours from dedicated OSS developers powering everything from our operating systems, to our web servers, to our ops tools and Bitcoin itself, the BitMEX trading platform could not have been built. We don’t forget this gift. Therefore, HDR considers this grant, provided on a no-strings-attached basis, to be only a small part of an ongoing commitment to bolstering Bitcoin and other OSS projects for the benefit of all.

 

Facebook 推出名为 Libra 的固定收益 ETF,与 ETF 巨头贝莱德 (Blackrock) 展开竞争

摘要:社交网络巨头 Facebook 以大胆的举动,通过其 “Libra 币”,或者我们称之为 “Libra ETF” 向传统金融和 ETF 行业发起挑战。我们注意到,与传统 ETF 相比,Libra 有许多悬而未决的问题,可能缺乏透明度。Libra 的另一个主要缺点是,与传统 ETF 不同,投资收益没有分配给单位持有人。我们得出的结论是,尽管与传统 ETF 产品相比,Libra 具有明显的劣势,但 Facebook 在 Whatsapp 和 Instagram 等平台上广泛的消费者覆盖可以为 Libra 带来关键的商业优势。

(Facebook 与贝莱德 – ETF 之战)

概述

Libra 的结构类似于广受欢迎的交易所交易基金(ETF)模式,其中单位持有人有权获得一篮子金融资产的财务回报。这些单位可以在交易所交易,经过挑选的授权参与者可以利用标的资产创建和赎回单位。

正如我们在 2019 年 2 月的一篇文章中指出的,ETF 行业在过去十年左右的时间里取得了可观的增长,尤其是在固定收益领域(见下图 1)。2019 年 6 月,ETF 行业迎来了一个爆炸性时刻,社交媒体与互联网巨头 Facebook 加入了该行业,这意味着贝莱德 (Blackrock) 和先锋 (Vanguard) 等老牌基金公司将面临挑战。Facebook 宣布计划推出一款名为 “Libra ETF” 的新 ETF,同时专注于固定收益和政府债券,这是对贝莱德旗下 “iShares Core U.S. Aggregate Bond ETF” (AGG) 的直接挑战。

图 1  – 针对美国投资者的顶级债券 ETF 的规模 – 10 亿美元

(资料来源:BitMEX Research,Bloomberg)

(注:图表代表以下债券 ETF 的市值总和: 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)

对比新的 ETF 结构和传统空间

下方图 2 中,我们将创新的新型 Libra ETF 和传统的 ETF ——贝莱德旗下的 iShares Core US Aggregate Bond ETF (AGG) 进行了分析和比较。我们的分析表明,尽管 Libra 产品是新产品,但许多相关信息,如持股透明度和资产净值公布的频率,尚未得到公布。

分析还强调,Libra 在投资组合管理方面可能会遇到不必要的复杂性。该基金似乎由 Libra 协会管理,该协会由全球多个行业的多家实体组成。这些实体负责发行 ETF,公司名单将进一步扩大。与此同时,投资授权并不明确。相比之下,贝莱德的固定收益 ETF 产品有明确的投资授权,以跟踪独立于 ETF 发行人管理的彭博巴克莱美国综合债券指数。

也许 Libra 产品最显着的缺点是单位持有人似乎没有资格获得投资收益。这与贝莱德的产品形成了鲜明的对比。贝莱德的产品专注于几乎相同的资产类别,投资收益率约为 2.6%。Libra 的保护者可能会指出,这些费用需要从某个地方支付,但Libra 的费用尚未披露。然而,ETF 行业已经具有很强的竞争力,贝莱德收取的费用仅为 0.05%。该费用远远低于产品的预期投资收益率,约为 2.6%,因此 Libra ETF 可能不具备价格竞争力,这对潜在的投资者来说是一个主要的潜在劣势。

图 2 – Libra ETF 与 iShares Core U.S. Aggregate Bond ETF (AGG) 的详细对比

  Libra ETF

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

发布日期 2019 年 6 月 2003 年 9 月
发布者Libra 协会/ Facebook 贝莱德
管理资产 未知

635 亿美元

资产类别

固定收益

银行存款和政府债券,货币来自稳定和信誉良好的中央银行

固定收益-投资级政府债券和公司债券
标的指数 未知/不适用 彭博巴克莱美国综合债券指数

项目组合负责人

总部设在瑞士的Libra协会将负责管理储备。目前,投资授权尚未披露。当前的成员如下:
  • 万事达卡
  • 贝宝
  • PayU (Naspers的金融科技部门)
  • Stripe
  • 维萨卡
  • Booking Holdings
  • 易趣
  • Facebook/Calibra
  • Farfetch
  • 来福车
  • MercadoPago
  • 声田
  • 优步
  • Iliad
  • 沃达丰集团
  • Anchorage
  • Bison Trails
  • 比特币公司
  • Xapo
  • 安德森·霍洛维茨风险投资公司
  • 突破计划 (Breakthrough Initiatives)
  • Ribbit Capital
  • 兴盛资本
  • 联合广场风投
  • 创意破坏实验室
  • Kiva
  • 国际美慈组织
  • 世界妇女银行

James Mauro 和 Scott Radel,对指数进行跟踪的授权明显受到限制

费用

未知

0.05%

投资收益率

未知

2.6%

投资收益的使用

单位持有人无权获得投资收益 ,投资收益将:

首先是支持协会的运营费用——为生态系统的增长和发展提供资金,为非营利组织和多边组织、工程研究等提供资助。满足这笔费用后,剩余的部分回报将用于支付“Libra投资令牌”中的早期投资者的股息,作为他们最初投资的回报

归于 ETF 单位持有人

可用交易所

目前无

Libra协会

将鼓励 Libra 在全球多个受监管的电子交易所上市

纽约证券交易所

创建/兑换篮子的大小

未知

100,000 个单位

授权参与者(能够创建和兑换单位的实体)

授权代理商,目前尚未披露

投资银行

资金审计

未知

PwC

持有股份及资产净值 (NAV) 资料

未知

充分披露(每日发布)

(资料来源: iSharesLibra

我们还从技术角度分析了这两种备选方案。如下图 3 所示,关键区别在于 Libra 代币的控制可能部分由数字签名进行管理。只要未实施地址白名单,这可能会带来一些优势:

  • 使用假名
  • 有限的审查抵制
  • 与加密货币交易相对容易集成

然而,正如我们在 2018 年 2 月的 Tether 报告中提到的那样,历史表明这些特征可能最终导致平台面临实施 KYC 或被当局关闭的选择当中。Facebook 已经在其主要平台上审查了一些有政治争议的人物,因此,公共私人密钥密码术管理 Libra ETF单位的程度可能会受到很大限制,或逐渐被淘汰。

图 3  – 技术和加密方面的考虑

 

Libra ETF

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

共识系统

不适用 (ETF 不需要共识系统)

区块链

不相关(将 ETF 交易记录分组为通过散列链接在一起的区块链,对 ETF 来说无关紧要)

基于数字签名的单元控制

可能:

Libra 区块链是匿名的,允许用户持有一个或多个与其真实身份无关的地址

(来源: iSharesLibra

结论

尽管 Libra 的主要劣势在于其单位持有人无权获得投资收益,但许多行业分析师仍然正在仔细研究 Libra 对传统 ETF 行业和现有电子支付系统的影响。

尽管我们对 ETF 的比较是在半开玩笑,但它确实突出了 Libra 的产品结构与现有金融产品具有相似的属性。所以我们认为这个比较是恰当的,如果 Libra 想要具有竞争力,它应该仿效传统 ETF 的一些管理和收费的特点。

不过,Libra 也可以通过整合 Facebook、Whatsapp 和 Instagram 等平台来吸引客户。如果 Libra 确实保留允许私钥控制钱币的属性,那发展下去也将会是挺有趣的,同时钱币可能会从诸如 Tether 之类的代币中获得份额。然而,在我们看来,从长远的角度来看,Libra 要么会禁用这一功能,要么会在技术上造成困难,因此只有极少数用户拥有这些“非托管”的钱包。如果出现这种情况,那么 Libra 便只是一只收费很高的 ETF。

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

BitMEX (www.bitmex.com)

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.

比特币现金硬分叉—— 三个相互关联的事件

摘要:2019 年 5 月 15 日,比特币现金硬分叉似乎遭遇到三个相互关联的重大问题。 “攻击交易” 利用一个漏洞,导致矿工产生空块。 围绕空区块的不确定性可能引起了一些矿工的担忧,他们可能试图在最初的非硬分叉区块链上挖矿,继而引发了共识区块链分裂。开发人员和矿工似乎已经制定了一项计划,以复原意外发送到隔离见证(SegWit)地址的资金,上述漏洞可能破坏了这一计划。 这种失败可能导致了进行有意识和协调的两个区块链重组。 根据我们的计算,大约有3392 比特币现金(BCH)可能已经在一个精心策划的交易逆转中成功地被双重花费了。 不过,这次双重花费的唯一受害者可能是原来窃取这笔钱的 “小偷”。

比特币现金网络在 2019 年 5 月 15 日分裂的图解

(资料来源: BitMEX 研究)
(注: 分裂的图形说明)

三个比特币现金的问题

比特币现金在2019年5月的硬分叉升级受到三个重大问题的困扰,其中两个可能是间接由一个导致空块的漏洞引起的。下图显示了这三起事件之间的潜在关系。

比特币现金在硬分叉升级期间面对的三个问题之间的关系

(资料来源: BitMEX 研究)

空块问题

Bitcoin ABC 是比特币现金的一个重要实现软件,但它有一个漏洞,进入内存池的交易的有效性条件可能没有共识有效性条件那么繁琐。 这与比特币(想必比特币现金也一样)预期运作的方式相反,共识有效性规则本应比内存池有效性更宽松。这实际上是一个非常重要的特性,因为它可以防止恶意花费者创建满足通过网络中继并进入商家内存池的条件,但是无法满足进入有效区块所需条件的交易。这会使 0 确认双重花费攻击相对容易阻止,而无需担心初始付款进入区块链。在这种情况下,攻击者可以有理由确定,恶意构造的交易永远不会进入区块链。

攻击者似乎已经在比特币现金 ABC(Bitcoin Cash ABC)中发现了这个漏洞,然后在硬分叉之后加以利用,从而引起混乱和迷惑。这个攻击可以随时执行。 攻击者只需要广播满足内存池有效性条件但未通过共识检查的交易。当矿工试图产生这些交易的区块时,他们失败了。作为故障保护,矿工似乎已经制造空块,而不是颗粒无收,至少在大多数情况下是这样。

比特币现金 — 每个区块的交易数量 — 橙色线是硬分叉

(资料来源: BitMEX研究)

不对称的链分裂

在空块不确定性达到最高峰时,我们的预硬分叉 Bitcoin ABC 0.18.2 节点收到了一个新的区块,582,680。 当时,许多人都担心空块,一些矿工可能已经恢复到一个硬分叉前客户端,认为较长的区块链遇到了麻烦,并可能会恢复到硬分叉之前。不过,这仅仅是我们的猜测,而空块漏洞可能与链分裂无关,这可能只是由一个太慢而无法升级的矿工造成的。

比特币现金共识链分裂

(资料来源: BitMEX 研究)

对于硬分叉的结构,链分裂确实向我们强调了一个问题。 我们测试了我们的硬分叉后客户端 ABC 0.19.0 是否会将分裂的非硬分叉侧视为有效。 为了使分裂 “干净”,分裂的每一侧都应该认为另一侧是无效的。

为了测试较短的硬分叉前区块链的有效性,从 Bitcoin ABC 0.19.0 节点的角度来看,我们不得不使自分裂以来的第一个硬分叉区块无效。 然后,我们观察该节点是否会跟随链分裂或仍然卡在硬分叉点。 出乎我们意料的是,如下面的屏幕截图所示,该节点跟随分裂的另一侧。 因此,分裂并不完全,这种不对称,可能为攻击者提供更多机会。

我们的 Bitcoin ABC 0.19.0 节点的命令行截图

(资料来源: BitMEX研究)

协调的两个区块重组

在硬分叉之后的几个区块,在分裂的硬分叉侧,有一个长度为 2 的区块链重组。 当时,我们认为这是由正常的区块传播问题引起的,并没有考虑太多。 例如, Bitcoin SV 在此之前几周经历了该长度的 6 个区块的重组, 根据我们的分析,当 Bitcoin SV 重组时,孤链中的所有交易最终都进入主要的获胜链(Coinbase 交易除外)。 不过,在这种比特币现金重组中,我们发现事实并非如此。

孤立区块,582,698,包含 137 笔交易(包括 Coinbase),其中只有 111 笔交易进入获胜链。 因此,就 25 笔交易而言,似乎发生了一次成功的 2 个区块双重花费。 如下表所示,这 25 笔交易的输出值总计超过 3,300 个BCH。

孤立区块(582,698)中没有进入主链的交易列表

交易 ID

总输出 (BCH)

1e7ed3efb7975c06ca46598808e17c6f42c66a085fcb65356dc090e3c434d874

Coinbase (未计算)

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

(资料来源: BitMEX 研究)

如上表所示,这 25 笔双重花费交易的总输出值为 3,391.7 BCH,从经济角度来看,这是一笔重大数额。 因此,可以得出结论,重组是一个精心策划的事件,而不是偶然发生的。 如果这是偶然发生的事件,则分裂的每一侧的交易可能不会出现不匹配。 不过,假设协调和故意重组是我们的猜测。 

我们提供了以下两个双重花费的输出示例:

其中一个双重花费 UTXO(未花费过的交易输出)示例—— “0014”

(资料来源: BitMEX 研究)

上表说明了重组期间 5 个 BCH 输出发生的情况。 这 5 个 BCH 首先被发送到区块 582,698 中的地址 qzyj4lzdjjq0unuka59776tv4e6up23uhyk4tr2anm 。 该链是孤立链,而相同的输出最终被发送到不同的地址, qq4whmrz4xm6ey6sgsj4umvptrpfkmd2rvk36dw97y,在 7 个区块之后。

第二个双重花费 UTXO 示例—— “0020”

(资料来源: BitMEX研究)

上述输出的情况与 25 笔双重花费交易中的几乎所有资金有共同的特征。 大多数输出似乎已经在主链上的区块 582,705 附近进行双重花费,在孤立区块后大约 7 个区块。 

用于赎回交易输入的 SigScript 以 “0020” 或 “0014” 开头,在上面的示例中突出显示。 这些可能与 Segregated Witness(隔离见证)有关。 根据 Segregated Witness 中的规范,“0014” 被推送到 P2WPKH(支付给见证公钥哈希),和 “0020” 被推送到 P2WSH(支付给见证脚本哈希)。 因此,这些输入的赎回可能与比特币升级的隔离见证有关,其中只有一部分是在比特币现金上采用的。

实际上,基于我们的分析,孤立区块 582,698 中的 25 笔交易中的每个单个输入都用 “0014” 或 “0020” 开头的 Sigscript 来赎回。 因此,除了赎回这些 SegWit(隔离见证)输出的 “攻击者” 或 “小偷” 之外,有可能没有人丢失与此链重组相关的资金,而这些资金可能首先被偶然地发送到这些输出。 

作为比特币现金 2019 年 5 月硬分叉一部分,有一个变化,就是允许复原被意外发送到 SegWit 地址的比特币。 因此,这可能发生在这次事件中。

允许隔离见证复原

在上次升级中,意外发送到 Segwit P2SH 地址的比特币因 CLEANSTACK 规则而变为不可花费。 这次升级将对这些比特币进行豁免,并将它们恢复到之前可以花费的情况。 这意味着一旦 P2SH 赎回脚本预映射被透露(例如通过从相应的BTC地址花费比特币),任何矿工都可以拿走硬币。

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

这个 2 个区块重组可能与空块漏洞无关。 不过,分裂似乎就在在解决漏洞之后一个区块发生,因此它可能是相关的。 也许“诚实”的矿工们试图在分裂后直接协调这些输出的花费,又或许要将它们归还到原来的所有者那里,而空块漏洞搞砸了他们的时间,让攻击者得益并卷走资金。 

另一方面,该攻击非常复杂,因此攻击者可能非常老练,并需要进行广泛的规划。 因此,即使没有空块漏洞,这种攻击也可能是有效的。 

结论

我们从有关比特币现金硬分叉升级的事件中吸取到许多教训。 硬分叉似乎为恶意行为者提供了攻击和制造不确定性的机会,因此对硬分叉的精心规划和协调非常重要。 另一方面,这个空块漏洞可能是其他两个事件的根本原因,其可能在任何时候发生,而无论是否正在试图硬分叉,尝试防止这样的漏洞才是重中之重。

这些事件的另一个重要教训是需要透明度。 在事件发生期间,很难知道开发人员的计划、漏洞的性质或矿工支持的链。 在公共渠道中就这些问题进行公开交流可能会更有帮助。 特别是,很多人都不能清晰知道开发人员和矿工的计划,以协调和复原发送给 SegWit 地址的资金。 如果这个计划事先在社区中,以及在明显的经过深思熟虑和协调的重组期间进行辩论和讨论,可能会有所帮助。 当然,假设有时间披露后者。 如果参与者在事后披露有关这些事件的详细信息,也可能会有所帮助。

我们认为,所有这一切中令人最担忧的是经过深思熟虑和协调的重组。 从论证的一方来看,资金被盗,因此将资金归还给其“合法所有者”的行为是合理的,即使这造成了一些短期中断。 不过,许多人或者某些人认为交易最终确认等现金是这些区块链系统的唯一独特特征。 如果能够逆转交易,和在本情况下的经济上重大交易,这将否定这个系统的整个前提条件。 这种行为可能消除适当保障资金的动机,开创先例或改变预期,更有可能产生进一步逆转。

对于比特币社区中所有不喜欢比特币现金的人来说,这可能成为嘲笑这种币的机会。 不过,虽然比特币现金的哈希值比比特币低得多,使得这种逆转更容易,但我们认为,成功对比特币现金进行经济上重大的精心策划交易逆转对比特币而言并不是好消息。 从某些方面来看,这些事件有助于树立一个危险的先例。 这表明这些事件可能会发生在比特币身上。 或者,这可以说明比特币现金在成为少数链的同时所面临的风险。

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

BitMEX (www.bitmex.com)

HDR Global Trading Limited 向麻省理工学院的数字货币计划(MIT DCI)提供捐助,以支持加密货币研究

我们非常高兴地宣布 ,HDR Global Trading Limited 将对麻省理工学院数字货币计划提供捐助,这是一项研究全球加密货币生态系统的开发和改进的计划。

HDR Global Trading 首席技术官兼 BitMEX 交易平台联合创始人 Sam Reed 宣布了这一赞助:

加密货币的潜力一直激励着我们前行。我们捐助研发是为了确保这个网络发展得更加稳健,因为一个更强大的比特币网络对所有人都有益。非常高兴能够促进它的发展.

HDR Global Trading 是全球最大的加密货币交易平台 – BitMEX 的所有者和经营者。 HDR Global Trading 很荣幸能够支持这样一项使比特币更强大,提升比特币的稳定性,扩展性和隐私性的研究工程。

值得一提的是,HDR一向热衷于为如 Wladimir van der Laan 和 Cory Fields 的比特币核心开发者的工作提供支持和帮助。他们在比特币协议的不同部分中扮演着至关重要的角色。

此次捐助为无条件提供,并没有任何限制。

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

BitMEX (www.bitmex.com)

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.

比特币现金 SV – 6 区块链裂

摘要: 2019 年 4 月 18 日,BitMEX 研究团队的比特币现金 SV 节点曾经历了 2 次区块重组。 先是一次 3 区块重组,接著是 6 区块重组。 在此简报中,我们给出了此次临时链裂的相关数据和图表。 此次链裂似乎是由太长而难以传播的大型区块,而非与共识相关的问题所导致的。 我们的分析显示,没有双重支出与此次分裂有关。

链裂图解 – 2019 年 4 月 18 日

资料来源: BitMEX 研究

注: 上图显示有两个有效的竞争链,并且在区块 578,639 处发生了非共识分裂。 我们的节点跟随左边的链直到 578,642 区块为止,然后跳到右边。 大约一个小时后,跳回到左边。 左边的链延续,而右边的链最终被抛弃。 

链裂交易数据

 
交易数
主链(6 个区块内)
754,008
分叉链
1,050,743
重叠(6 个区块内) 
753,945
最终双重支出
0

资料来源: BitMEX 研究团队 

根据我们对交易的分析,来自分叉链(右边)的所有 TXID 最终都会回到主链中,但生成交易明显是例外。 所以,我们认为没有发生于与此次意外相关的双重支付。

分裂相关区块的时间戳 – 2019 年 4 月 18 日

本地时间 区块时间戳 高度 哈希值 大小 (MB) Log2 计算
11:39:47 11:39:19 578,638 000000000000000001ccdb82b9fa923323a8d605e615047ac6c7040584eb2419 3.1 87.803278
12:04:51 12:04:37 578,639 0000000000000000090a43754c9c3ffb3627a929a97f3a7c37f3dee94e1fc98f 8.6 87.803280
12:28:01 12:20:36 578,640 00000000000000000211d3b3414c5cb3e795e3784da599bcbb17e6929f58cc09 52.2 87.803282
12:43:42 12:29:39 578,641 0000000000000000050c01ee216586175d15b683f26adcfdd9dd0be4b1742e9e 42.1 87.803285
12:59:27 12:51:40 578,642 00000000000000000a7a25cea40cb57f5fce3b492030273b6f8a52f99f4bf2a8 76.2 87.803287
13:05:18 12:32:39 578,640 000000000000000007ad01e93696a2f93a31c35ab014d6c43597fd4fd6ba9590 35.5 87.803282
13:05:18 12:33:16 578,641 0000000000000000033ed7d3b1a818d82483ade2ee8c31304888932b7729f692 0.1 87.803285
13:05:18 12:41:38 578,642 00000000000000000ae4a0d81d4c219139c22ba1a8a42d72b960d63a9e157914 1.0 87.803287
13:05:19 12:56:37 578,643 00000000000000000590821ac2eb1d3c0e4e7edab586c16d5072ec0c77a980dc 0.8 87.803289
13:19:36 13:14:22 578,644 0000000000000000001ae8668e9ab473f8862dc081f7ac65e6df9ded635d338e 128.0 87.803291
13:21:56 13:18:07 578,645 0000000000000000049efe9a6e674370461c78845b98c4d045fe9cd5cb9ea634 107.2 87.803293
14:12:54 13:15:36 578,643 0000000000000000016b62ec5523a1afe25672abd91fe67602ea69ee2a2b871f 23.8 87.803289
14:12:55 13:43:35 578,644 000000000000000003e9d9be8a7b9fc64ef1d3494d1b0f4c11845882643a6439 1.3 87.803291
14:12:55 14:01:34 578,645 0000000000000000052be8613e79b33a9959535551217d7fdacc2d0c1db1e672 0.0 87.803293
14:12:55 14:06:35 578,646 00000000000000000475ab103a92eb6cb1c3c666cd9af7b070e09b3a35a15d66 0.0 87.803296
14:27:09 14:24:37 578,647 0000000000000000062bade37849ade3e3c4dfa9289d7f5f6d203ae188e94e4f 77.0 87.803298

资料来源: BitMEX 研究团队 

如有兴趣,可参看我们在上表中披露的链裂相关区块的所有相关详情,其中包括:

  • 区块时间戳
  • 本地时间时间戳
  • 区块哈希值 
  • 区块大小
  • 每个区块累计总工作量证明(PoW)

通过上述细节,可以跟踪发生的与链裂相关的情况并创建时间线。

结论
我们提供本信息和分析的主要目的不是出于对比特币现金 SV 的兴趣,而是希望开发系统来分析和探测比特币网络上的此类事件。 我们的网站https://forkmonitor.info 目前正在开发系统,以帮助检测由区块传播不良或与共识相关的问题导致的链裂。 比特币现金 SV 的此次事件对我们来说是一次非常不错的实践。

至于比特币现金 SV,区块在重组期间的规模极为庞大。 在分叉链上,最后两个区块分别为 128MB 和 107MB。 在主链上,很多区块超过 50MB。  因此,在我们看来,大型区块可能是重组的根本原因,因为矿工无法在不同链上找到其他区块之前足够快地传播和验证这些大型区块。

至于这对比特币现金 SV 的影响,我们不作评论。我们会把这个问题留给他人。

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

BitMEX (www.bitmex.com)