Wormhole燃烧地址到底有多安全

Wormhole协议采用了Proof-of-Burn(PoB)机制进行Bitcoin Cash与Wormhole Cash之间的兑换。有人会好奇这个地址到底是如何选取出来的,本文就如何选取Wormhole燃烧地址的细节做一下介绍。
Wormhole团队在选取燃烧地址时,通过以下几个原则来筛选:

1.无人拥有该地址的公私钥

2.该地址从未被使用过

3.该地址以whc结尾,具有鲜明的Wormhole协议特色

Wormhole团队是如何选择燃烧地址的

Wormhole团队在选取燃烧地址的时候,是通过不断迭代的方式选出燃烧地址的,我们选取燃烧地址的代码开源在这里,任何人都可以运行这段代码查看结果。下图为选取燃烧地址的核心代码片段:

11.png-321.3kB
11.png-321.3kB

这段代码可以分为两部分来看,第一部分如下图:
6.png-118.2kB
6.png-118.2kB

这段代码主要功能是从0开始,以步长为1不断叠加的方式来构造地址,因为NewCashAddressPubKeyHash函数需要传递一个20个字节的pkHash(该函数具体实现可点击这里查看),所以通过内层的for循环构建出的result是一个40个字符的16进制数,对一个字节进行16进制编码需要用2个字符来表示,所以40个字符的正好是20个字节的16进制编码,再将得到的结果作为参数传递给NewCashAddressPubKeyHash函数就得到一个Bitcoin Cash地址。然后来到第二段代码筛选出符合要求的地址:
10.png-175.4kB
10.png-175.4kB

第一个if条件判断生成的地址是否以whc结尾,符合这样条件的地址总共有300个(太多就不贴出来了),第二个if和第三个if用来筛选该地址后缀是不是8whc,符合这样条件的地址总共有9个:

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqp5fmqjgec8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqxkqxc0pml8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqtwhhu7krj8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqvv72yrlp48whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqq3hsu5436g8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqk4epvgcc08whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqmdwsge0qz8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqppgv4s588t8whc

第四个if用来筛选后缀是[0-9]8whc的地址,这样的地址总共有三个:

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqvv72yrlp48whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqk4epvgcc08whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc

为什么一定要选后缀是8whc的地址?因为数字8在中国文化中是一个Lucky Number,所以我们期望找一个后缀为whc并且前面跟数字8相关的地址,但是符合这个限定条件的只有上述三个满足,就像选车牌一样,人们总是喜欢选一个自己喜欢的数字和字母的组合,所以我们在这三个地址选定了qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc作为燃烧地址。

对CSW博士错误观点的修正

CSW博士在medium上发表了一篇文章,我们发现这篇文章中两个地方的描述是完全错误的。

1、分割出地址的Checksum

我们可以看一下在CSW博士的描述中,他是如何分割出Checksum的


9.png-100.7kB
9.png-100.7kB

可以看到这个地址一个经过Base58编码得到的BCH的地址,对该地址来说是不能直接这样分割出Checksum的,这是众所周知的事情,CSW博士文章中这种描述真是令人贻笑大方,在讲正确的分割方法之前我们先来了解一下什么是Base58编码。

什么是Base58编码

Base58是在Bitcoin中使用的一种独特的编码方式,主要用于产生Bitcoin的钱包地址。相比Base64,Base58不使用数字"0",字母大写"O",字母大写"I",和字母小写"l",以及"+"和"/"符号。设计Base58主要的目的是:

1.避免混淆。在某些字体下,数字0和字母大写O,以及字母大写I和字母小写l会非常相似。

2.不使用"+"和"/"的原因是非字母或数字的字符串作为帐号较难被接受。

3.没有标点符号,通常不会被从中间分行。

4.大部分的软件支持双击选择整个字符串。

Bsae58编码的具体实现是:

1. 将待编码的字节数组表示为一个大整数;

2. 该整数除以58,其余数作为base58字符表的索引,获得相应的字符,保存到字符串中;其商继续除以58,取余再次获得一个字符,追加到上述的字符串中;重复以上步骤,直至商为0;

3. 对于以字节0开头的待编码字节数组,向上述字符串末尾追加相等数量的字符 '1' (直至遇到第一个不为0的字节);

4. 然后将所得的字符串倒序表示,即是最终结果。

核心代码如下图所示:

14.png-118.1kB
14.png-118.1kB

如果你想看客户端中对Base58的详细实现过程,请点击这里源码中对Base58的实现逻辑和上图所示的代码逻辑是一致的。

Checksum正确的分割方式

按照CSW博士在文中描述的方式分割出Checksum,对分割出的两部分分别进行Base58解码得到的结果为:

00-00000000000000000000000000000000000CD9CF-0361022C67

这个结果显然是错误的,而按照正确的分割逻辑,1111111111111111115KMYP7R278如果要分割出Checksum,首先要对其先进行Base58解码,1111111111111111115KMYP7R278经过Base58解码后相应的十六进制表示为:

00-000000000000000000000000000000000071E76C-501B5A27

按照传统地址规范,第一个字节的00表示版本号,最后的4个字节501B5A27才是Checksum。

2、可以通过亚马逊集群服务器逆推出地址的私钥

在CSW博士文章中他是这样说的:


15.png-55.6kB
15.png-55.6kB

按照CSW博士的说法,那现在所有的基于椭圆曲线加密算法的数字货币都是不安全的,都可以通过所谓的“any Amazon cluster”破解,这种说法显然是站不住脚的。Wormhole燃烧地址所包含的 160比特哈希值的十六进制表示为

000000000000000000000000000000000071E76C

观察可知,该160比特的哈希值最左侧的137个比特位全部为零。如果这是开发团队精心构造出来的地址,则构造的过程需要遍历pubkey直到RIPEMD160(SHA256(pubkey))的输出的最左侧的137个比特位全部为零。这一过程跟BCH网络的PoW求解非常相似:通过大量穷举尝试,使获得的哈希值的最左侧的一些比特位为零。以当前(2018/09/12)的块高度541027为例,块哈希的十六进制表示为:

000000000000000002712253f9230d6e1f98c8071e98e197423d6cd285c8800

最左侧的共有68个比特为零,根据PoW机制可知,为获得该块矿工大约尝试了2^68 次计算。同样,要求最左侧的137个比特位全部为零,需要Wormhole开发团队尝试大约2^137 次哈希计算。这是个什么样的概念呢?现在BTC全网算力是51.14EH/s,BCH全网算力总共是3.99EH/s,加起来是55.13EH/s,也就是说现在BTC和BCH全网合起来每秒可进行5.513x10^19 次Hash运算,那以现在BTC和BCH全网算力总和来计算 2^137 次Hash需要多少时间呢?我们很容易得出结论:

T(年) = 2^137 / 55.13×10^18 ≈ 2.5×10^10(年)

可以看到这个计算需要大约250亿年的时间能完成,宇宙迄今为止才有大约137亿年 [1],这是时间上的不可能。另外从耗能的角度来说,我们这里以S9 Hydro矿机为例,S9 Hydro的功耗为1728W,算力为18T [2],也就是说1秒钟计算18万亿次Hash耗能是1728J,那么运算一次Hash需要消耗的能量是:

W = 1728 / 1.8×10^13 ≈ 9.6×10^-11(J)

那么要计算2^137 次Hash总共消耗的能量是:

W = 9.6×10^-11 × 2^137 ≈ 1.3×10^31(J)

要知道太阳一百亿年总共才释放了1.12×10⁴⁴ 焦耳的能量[3],从而也说明要计算2^137 次Hash在耗能上也是不可能的。关于计算2^137 次Hash的难度,我在这只给大家一些直观上的感受。具体的Wormhole燃烧地址的安全性,我们之前已经有过详细的讨论,感兴趣的同学可以点击这里查看。

Wormhole团队的初衷是为BCH网络增加更先进的功能,为整个BCH网络生态繁荣贡献自己的力量,纵然有各种各样无端的质疑,我们也会不忘初心砥砺前行。

References

  1. https://en.wikipedia.org/wiki/Age_of_the_universe

  2. https://shop.bitmain.com/product/detail?pid=00020180911132006680AinyTiI406BB

  3. https://www.bp.com/content/dam/bp/pdf/energy-economics/statistical-review-2016/bp-statistical-review-of-world-energy-2016-full-report.pdf

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容