预挖 BTCP 到底是个怎样的事件?这么大的事竟无人能察觉?_区块链:区块链dapp开发

原文标题:《你从未听过的区块链局:一个隐藏在隐私币BTCP代码深处的阴谋》

在区块链行业,各种欺诈事件层出不穷,但CoinMetrics最近发现的一起欺诈行为,却从去年三月份一直潜藏至今,该项目打着隐私技术与zk-SNARKs零知识证明协议的幌子,却利用这些技术在代码深处埋藏了一个极大的阴谋。

若非CoinMetrics使用技术手段层层验证,这一局恐怕至今仍无人能看破。那么,这个局究竟在以怎样的手段来利用最新的这些区块链技术呢?这样的局为什么能瞒过这么多区块链领域的技术行家呢?

接下来,请看本文的深度解析:

BitcoinPrivate项目是比特币和ZClassic的「分叉合并」,旨在为比特币增加ZClassic基于zk-SNARKs的零知识证明技术的隐私和安全特性。其中,ZClassic又分叉自ZCash,由矿工所支持,类似于比特现金。

根据BitcoinPrivate的官方说明,它的初始代币总量基于当时已发行的比特币、ZClassic以及用于挖矿项目的少量代币而确定出来,为2040万。另外,加上一部分用于挖矿奖励的递减分配代币,跟比特币的总供应量一样,BTCP的总供应量也限定为2100万。

然而,在导入比特币UTXO数据的过程中,一件诡异的事情发生了:BitcoinPrivate屏蔽池中神秘地多出了204万BTCP,令初始代币总量高达2260万,这与官方白皮书和BitcoinPrivate团队所公布的数据完全矛盾。

在这过程中,屏蔽池中有一批代币已经被秘密预挖出来:其中有30万BTCP似乎正在从屏蔽池转移到交易所,这就相当于为当前流通的BTCP额外空投10%的代币;除此之外,屏蔽池中还有大约180万被预挖出来的BTCP。

尽管BitcoinPrivate名义上是融合ZClassic与比特币状态的一次「分叉合并」,但其分叉的基础是ZClassic账本数据,而非比特币。

BTCP的区块链不是一条完全从零挖矿出来的链,而是直接生成了事先协商一致的数千个区块。BitcoinPrivate从ZClassic区块链高度为272992的区块处开始分叉,将比特币的UTXO数据直接导入到父链ZClassic内。导入结束时,基于「矿工自愿贡献计划」,又额外生成了62500BTCP。至此,BitcoinPrivate自己的公链才正式启动。

相应的统计信息如下:

因此,BTCP的代币数据如下:

这与BitcoinPrivate白皮书上的官方数据还是吻合的:

在分叉完成时,总量为2100万的BTCP代币中,大约会直接生成2040万个。

此外,分叉后每个区块的挖矿奖励为1.5625BTCP,且每挖21万个区块奖励均会减半。截止撰稿时,BitcoinPrivate公链的区块高度为446997。由于分叉发生在278458区块处,因此有141542个区块的挖矿奖励为1.5635BTCP,另外26996个区块的挖矿奖励为0.78125BTCP。

据此,我们算出当前BTCP的供应总量:

而根据CoinMarketCap的统计,BTCP的循环供应量为20.525M,这似乎是等于「初始供应量-矿工自愿贡献计划-初始ZCL屏蔽池的62.5KBTCP」所得出的数值。

为了验证这些数据,我们亲自运行了一个版本号为1.0.12-1的BitcoinPrivate节点,并使用RPC方法「gettxoutsetinfo」来调取其公链上的数据,所得结果如下:

在撰写本文时,我们的完整节点所给出的BTCP的总供应量为20.841M。这就奇了怪了,CoinMarketCap所统计的数据以及我们根据官方公开数据所计算的结果都不是这个数。到底是哪里出了问题?

为了解释这里的矛盾,我们不得不去一一推敲以下这些可能出问题的地方:

我们的节点没有运行在正确的BitcoinPrivate区块链上,有人以某种方式干扰了我们实验节点的数据;gettxoutsetinfo代码内存在bug;白皮书发布后,挖矿奖励发生了变化,致使我们最初的估算出现错误;zk-SNARKs零知识证明协议被黑客破解,使得有人可以在屏蔽池内创建额外的BTCP代币;BitcoinPrivate项目存在一个隐藏的预挖矿设计接下来,让我们一一分析,到底那种解释更合理:

我们的节点没有运行在正确的链上?

446997区块在BTCP官方区块链浏览器btcprivate.org上的哈希值与我们完全相同,有图有真相:

https://archive.fo/8MTW5

可以排除此项。

gettxoutsetinfo代码内有bug?

自BitcoinPrivate分叉以来,调取区块链数据的主要函数GetStats()从未修改过。

https://github.com/BTCPrivate/BitcoinPrivate/commits/b27c72274922eec86f301c2d1a7078dc038cfad6/hide/txdb.cpp

如果这里存在bug,它必然也会影响到比特币以及衍生自比特币的各种山寨币项目,但我们所运行的比特币节点的数据是与预期相符的。

所以,这一项也可以排除。

挖矿奖励发生变化?

挖矿奖励的执行有着固定的时间表,经过查证,它确实从未进行过修改。

这一项也可以排除。

零知识证明协议已经被攻破?

如果Zk-snarks技术确实被攻破,黑客一定会优先攻击ZCash,而非BitcoinPrivate。毕竟,ZCash相对要值钱多了。

这一项也可以排除。

那么,BitcoinPrivate项目确实存在一个隐藏的预挖矿设计?

是的。

我们的分析如下:

从高度272992到高度278457的所有BTCP区块,都用于导入比特币的UTXO数据,攻击有59188317个比特币的未花费输出,其总价值为16891665BTC。而高度为278458的BTCP区块则包含有「矿工自愿贡献计划」的62500个BTCP。

上述区块中,每一个区块均含有1000个输出,每个输出又对应一个比特币的UTXO。这是官方数据所预期的结果。

但奇怪的是,这些BTCP区块内还有一些含有10400个输出的特殊区快,其中这400个额外输出,每一个都价值50BTC,而这样的异常区块总共有102个。

我们可以用如下的图表直观描述一下:其中橙色线条表示的是将比特币的UTXO数据导入到BTCP区块链的预期过程,而蓝色线条所表示的则是实际发生的事情。

这样,在导入过程中,我们看到了102个超大型区块,其中除了10000个预期中的输出之外,每个区块还藏有400个额外的输出,且每个额外的输出都价值50BTC,这就产生了额外的102×400×50=2040000BTCP。

下面这张图清晰地标示出了BTCP区块链上的异常区块:

按UTXO数量进行对比时,异常区块则呈现出均匀分布:

将上图274590到275017间的数据放大,便得到下图:

这额外的2040万BTCP,既未在白皮书中声明,又未出现在比特币的UTXO数据中,但仍旧被BTCP的区块链凭空创造了出来。

目前,屏蔽池内有1807549BTCP,而已释放的UTXO数据内有20841921BTCP,使得BTCP的代币总数达到22649470,而非官方所公布的20631984。

那么,BTCP开发团队会承认这事吗?

简单来说,不会。

该团队一再声明:BitcoinPrivate项目不存在任何预挖代币或开发者税。

BitcoinPrivate与ZClassic基本上是同一批开发者搞出来,而ZClassic之所以要从ZCash分叉出来,就是要取消ZCash所固有的20%创始人奖励。BitcoinPrivate的出发点自然也是想取消创始人税,同时将BTCP的发行总量直接空投到比特币UTXO数据上。

BitcoinPrivate、Bitcoin、BitcoinCash与BitcoinGold对比图

FAQ:

1、BTCP的贡献团队是谁?

2、是否会预挖代币或预设创始人奖励?不会

当然,BitcoinPrivate在自己官方的区块链浏览器上肯定不会统计BTCP区块链上预挖出来的代币,所以我们称之为隐藏的预挖行为。

这难道就是用BTCP创始人口中所说的「社区从未见过的大型区块链欺诈」事件?

https://archive.li/2Gw22#selection-439.0-439.69

此外,还存在一个问题,就是我们的节点只找出了官方数据之外的20万BTCP,而非导入数据中所分析出来的全部204万BTCP。

那么,我们尚未发现的BTCP又藏到了哪里?

预挖BTCP到底是个怎样的事件?

由于ZClassic是ZCash的一个分叉,隐私性相对来说会更好。这就是说,ZClassic可以把其中一些地址屏蔽掉,让人们无法确定具体的交易地址或交易金额。

但是,当屏蔽池和非屏蔽池交互时,人们就能看到屏蔽池中流入和流出的资金。

在ZClassic分叉时,屏蔽池中就只有区区17KZCL。而撰写本文时,屏蔽池中则有180.7万BTCP。将屏蔽池和未屏蔽部分相加,可得出:

1.8M20.8M=22.6MBTCP

20.35M2.04M0.25M=22.6M

从上图可以看出,2018年4月29日,隐藏的预挖代币被送到屏蔽地址。7月11日至8月18日期间,大约有30万BTCP从屏蔽池内流出,当时,BTCP的价格在10美元到3美元之间。如果这些代币在市场上公开交易,就会获得100万到300万美元的利润。

你能找出下图中BTCP被送屏蔽池的那个时间点吗?

从上图可以看出,2018年7月到8月,这个地址接收了屏蔽池输送过来的1360万BTCP。在预挖矿之前,更多的BitcoinPrivate被送入屏蔽池中,并且有太多的BitcoinPrivate有待于矿工挖矿。

因此,这极有可能来自于预挖矿。有趣的是,大多数预挖出来的BTCP并没参与交易,而是存储在屏蔽池内。

关于此次分叉,另一条比较有趣的线索就是其效率:在BTCP区块链上,只有15%的代币被「激活」。这就意味着,这笔预挖出来的BTCP,最终将占据其供应总量的很大一部分。

自分叉以后,BitcoinPrivate声称链上只有2.55MZCL与572KBTC,也就是非预挖的代币总量仅为3.12MBTCP。而目前从屏蔽池内流出的预挖BTCP数量则有30万左右,占分叉后BTCP总量的9.5%。

换句话说,在分叉后的钱包中,每10个BTCP里面就有0.95个来自于预挖。

这么大的事竟无人能察觉?

BitcoinPrivate的主网于2018年3月上线,这就是说2100万货币总量的说法应当在数月前就已经破产了。因为,只要写出一些共识算法,检查一下导入过程中不能该存在的代币数据,肯定有人能发现其中有鬼。

但为什么这么大的问题,始终却无人察觉出来呢?

里面可能有两个原因:首先,很多人并不熟悉验证比特币UTXO导入过程,且验证力度也弱;其次,BitcoinPrivate继承了比特币的供应量检查,这是一个用于审查比特币公司代币输出的方法——但并没有察觉欺诈行为,因为BTCP的挖矿方法采用的是UTXO数据导入。

不合理代币总量检查

鉴于BitcoinPrivate代币来自各个不同的地方,在这里使用比特币代币供应-验证模型不太合适。在比特币中,代币总数是以每个区块为基础进行审查的,根据比特币处于预定于减半计划中所处的位置,新挖掘的代币数量不超过50/25/12.5/6.25。在比特币协议中,并没有内置用于验证模型中的自上而下的代币供应量审计。挖掘代币的难度、保证减半计划顺利进行的难度以及每个区块coinbase审查,都要考虑到这一点。

在BitcoinPrivate中,大部分代币并不是来自于挖矿,而是来自于比特币UTXO导入和现有的ZClassicUTXO数据。由于比特币UTXO导入检查工具力度较弱,BitcoinPrivate也缺乏一个真正的代币供应审核方法。

为了捕捉行为,我们可以通过观察代币的实际流动踪迹来实现。BitcoinPrivate不得不相信UTXO导入和挖矿过程都是按照开发人员的说法完成的。根据PeterTodd的建议,我们运行一个完全验证,并删除了检查点,但是额外的代币发行超出了节点执行验证检查的范围,因此,对于节点运行者来说,结果并不是太明显。由于代币发行是在协议范围外完成的,因此,完全验证节点也不能轻松的捕捉到这些额外的发行。这就需要提取数据,然后运行代币供应量检查。

弱化UTXO导入验证

BitcoinPrivate团队发布了一组用于审核导入区块的文件,除此之外,还发布了一组用于重新创建这些文件的工具。每个文件都包含了单个导入区块的内容。由于发布的文件表示了正确的UTXO数据转储,人们审核这些文件并确保共识代码不会发现任何问题。对于每个导入区块,共识代码检查该区块包含的10000个交易,并且,每个交易的第一个输出要与预期的比特币值和脚本相匹配。但是,它并没有检查区块中是否有其他额外的输出,这样一来,这些额外的代币就无法进行完整性检查。

https://github.com/BTCPrivate/BitcoinPrivate/pull/27

添加这些检查的拉推请求尽管包含了很多共识代码,但并没有收到任何评论。除此之外,拉推请求的名字并没有反映提议变更的重要性。

只有导入区块位于最后一个已知检查点之后,这些检查才可以运行。由于导入过程的检查点在分叉3天后就添加了,因此它们只能在导入过程中或导入之后,由运行完整节点的开发人员或禁用检查点的开发人员来运行。

这一案例研究可以说明:通过运行完全验证节点,并审核由这些节点所生成的数据,我们就可以检查代币总数是不是跟官方说法一致,而非一味地信任开发团队的官方数据,或是一些所谓的计算公式。

来源链接:coinmetrics.io

本文来源于非小号媒体平台:

区块链大本营

现已在非小号资讯平台发布1篇作品,

非小号开放平台欢迎币圈作者入驻

入驻指南:

/apply_guide/

本文网址:

/news/3627107.html

BTC比特币

免责声明:

1.资讯内容不构成投资建议,投资者应独立决策并自行承担风险

2.本文版权归属原作所有,仅代表作者本人观点,不代表非小号的观点或立场

上一篇:

安全公司揭秘ETC51%算力攻击的来龙去脉

下一篇:

MetaStable合伙人为交易所拆招:如何对付51%攻击

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:15ms0-4:211ms