投稿
区块链

BTC极品8问:为什么区块620826比区块620825早1秒诞生?

作者:admin 2021-07-09 我要评论

写在前面:关于BTC,大家有时会遇见一些难以理解的技术问题,比如“新区块比旧区块早1秒诞生”、“同一时间不同...

写在前面:

关于BTC,大家有时会遇见一些难以理解的技术问题,比如“新区块比旧区块早1秒诞生”、“同一时间不同全节点的大小不同”等极品现象,对于这部分问题,就需需要助专业的开发者来帮忙解惑,在本文中,译者便选取了8个相对较有趣的问题,而来自BTC开发社区的大神们也给出了精彩的答案。

(注:以下问题和答案,均来自bitcoin.stackexchange.com)

(图片来自tuchong.com)

问题1 : 为何两个完全同步的比特币 Core节点在区块链大小上是不一样的?

问题具体描述:实行getblockchaininfo时,size_on_psk显示大小比同时(区块)报告的其他节点小1.2 GB。

txindex=1

可能是哪些原因致使的?我已经在twitter上问过其它对等节点运营者,看是不是有他人也有同样的经历,但每一个人的账本数据都要比我多。 (https://twitter.com/bitdo/status/1231915231368163328)

Ugam Kamat答: 区块链大小上的差异,是因为节点存储的陈旧区块数致使的。陈旧区块是过去构成主链一部分,但目前不是主链的区块。

比如,假如有矿工同时在高度102挖取2个区块,当矿工通过gossip互联网中继区块时,与矿工2开采的区块(102b)相比,更挨近矿工1的互联网将第一接收它挖的区块(102a)。比特币 core将第一个接收到的有效区块添加到链的顶端。之后在同一高度接收的区块不会被删除,而是保存在数据库中,以防发生重组。因此,假如在区块(102b)之上挖取下一个区块103,则第一接收到102a的节点,会将其链重组为包含区块102b的链,如下图所示。

比特币 Core不会删除从其对等节点那接收到的任何有效区块。它永远存储在数据库中的blocks/blk****.dat文件中(这对于主链中的区块也是一样的)。但,软件不会中继陈旧区块。为了接收陈旧区块,当你的对等节点从不一样的链视图向你广播区块时,你需要在线。对等节点只能广播他们从目前活动链中看到的那些区块。因此,你只能拥有在线时收到的陈旧区块,因为这种可变性,很多节点的BTC区块链大小就是不一样的。

问题2:我试着用bitcoin-core推广客户端同步整个区块链,然后这花了我大约9天的时间,结果却被破坏了,所以我不能不删除并重新同步。有没资源可以通过torrent或常规浏览器下载?

chytrik答:假如你用torrent或其它方法下载区块链,但不验证收到的数据,那样你将没办法得知收到的数据是不是有效。这意味着你可能会随便下载到一个被攻击者恶意更改的区块链,其中可能纳入了不真实买卖,删除去合法买卖等,这部分都是你没办法得知的。

这就是为何bitcoin-core要花浪费时间间来下载和验证区块链是什么原因:这是在不需要信赖的状况下,获得目前互联网状况的唯一办法。

请注意,bitcoin-core在下载链数据时效果最好,假如你下载一个区块链的torrent,然后尝试用它进行验证,则需要更长的时间(你需要等待完整的下载,然后进行完整的验证,而不是并行地实行每一个部分)。

我不知晓有什么软件能比bitcoin-core更有效地实行这部分验证步骤。假如RAM借助率不足,可以尝试增加-dbcache选项。

问题3: 为何BTC第620826个区块比第620825个区块早一秒诞生?

Andrew Chow答:BTC并没需要后一个区块的时间戳要晚于前一个区块,唯一的需要是时间戳大于最后11个区块的时间戳中值。因此,这意味着一个区块在某个范围内的时间戳可以低于其父区块。

而第620826个区块早于第620825个,是由于矿工没完全同步的时钟,它们的内部时钟可能略有不同,因此可能会延迟几秒钟。假如一个矿工真的非常幸运,并因为时钟的不同,而非常快找到另一个区块,那样因为时钟的不同,他的时钟可能仍落后于父区块的时间戳。这可能就是这里发生的事情。

问题4 :我可以用同样的钱包运行两个BTC节点吗?

问题具体描述:大家在服务器上有一个BTC全节点和钱包,问题是大家的大部分钱包很长时间以前就完成同步了。对于大家来讲,好像此同步任务可能会花费很多时间,而在该时间段内,所有其他请求都将没办法访问BTC节点,而用户将没办法用大家的服务器。

大家考虑在单独的服务器上复制目前的BTC节点,并在那里同步钱包。完成此过程后,大家会将钱包复制回原始服务器。

这是可行的吗?或者大家不可以在两个不一样的BTC节点上有相同的钱包?

Gašper Čefarin答:这是可行的,你可以依据需要运行多个具备相同钱包的节点。我想你之所以要这么做,是由于同步过程在另一个节点上会更快吗?该过程完成后,你需要要复制完整的区块链数据,而不是钱包本身。

你可能需要考虑检查的瓶颈,可能是硬盘、CPU或某些状况下的网络带宽。

问题5 :为何哈希公钥事实上对抗量子计算没帮?

问题具体描述:在关于taproot的讨论中,有人提到输出将直接包含公钥,而不是对它们进行哈希运算。有人说,现在,哈希运算并不可以真的对抗量子计算提供帮,这是为何?

Andrew Chow答:虽然哈希一个公钥本身确实对抗量子计算提供了帮,但事实上,只有在“真空”条件下才会是如此的,公钥哈希并非存在于如此的环境中的,BTC还有不少其它东西需要考虑。

第一,假如公钥是经过哈希运算的,那样资金只有在用前才是遭到保护的。一旦用了点对点KH或P2WPKH输出,就会公开公钥。当买卖未经确认时,拥有足够快量子计算机的攻击者可以计算私钥并创建冲突的买卖,从而将资金发送给自己,而不是预期的接收者。

除此之外,假如攻击者是一名矿工,他们可以对每一笔买卖都这么做,仅需拒绝挖取不向自己发送币的买卖。

虽然这是一个问题,但大家一般觉得,这要比直接花BTC要好,由于他们拥有区块链中的公钥。虽然这是真的,但有很多公开公钥的输出。

现在有超越550 万 比特币的输出带有公开的公钥,它们要么是由于点对点K输出,要么是由于用户正在重用地址,因此其公钥在其他买卖中是公开的。因此,假如存在一台量子计算机,它可以在适当的时间内为公钥生成私钥,则攻击者可以获得的BTC就是这部分。

因此,虽然你的特定输出可能遭到哈希的保护,但这部分输出的值将是0,由于会有数百万比特币会失窃。哈希真的能做的,只不过提供一种错误的安全感。

除此之外,工具和钱包软件也存在一些问题,它们只不过在买卖和区块链中以其他方法公开公钥。没现有些工具将公钥视为私有信息,它们没理由如此做。

涉及公钥的复杂脚本和合约还存在其他问题,这部分脚本(如multisigs)并没哈希公钥,除此之外,这部分合约的存在一般是由于并不是所有当事方都需要相互信赖(其中一方可能是恶意的),在这样的情况下,合约中的恶意参与者将知晓所涉及的公钥,并可以窃取与这部分输出有关的BTC。现有些公钥哈希没办法预防这样的情况。

最后,假如发现存在可以破坏ECDLP的量子计算机,就大概向后量子密码体制过渡。假如准时测试到,但仍然来不及进行适合的升级,所有依靠ECDLP(即ECDSA和Schnorr)签名算法的用都可以通过软分叉,从而锁定所有些币。然后,这部分币可以通过提供一个零常识的证据来证明某些非公开的或抗量子的信息,这部分信息会表明私钥的所有权。

比如,用户可以提供一个证据,证明他们拥有用于派生给定公钥对应私钥的BIP 32种子。因为它是零常识证明,种子本身不会公开(请注意,种子不是公私密钥对的一部分,因此没有共享的公共组件)。因为大部分钱包都用了BIP 32,这就足够了。可能还有其他办法可以证明所有权,而不必冒着尚未想到的币风险。

当然,这所有都假设有一台量子计算机可以计算出一个公钥的私钥,而公众却不知晓这项技术已经存在。实质更可能的状况是,量子计算机的进步将被察看到,而且在它们强大到足以打破ECDLP之前的某个时刻,BTC将软性地引入一种抗量子签名算法。最后,依靠于ECDLP的签名将被删除。所有这部分,都将在量子计算机真的成为威胁之前发生。因此在这样的情况下,哈希公钥无论怎么样,都不会提供帮。

请注意,以上所有内容不只限于量子计算机,它一般适用于ECDSA(或Schnorr)的任何密码学破坏。

问题6 : 怎么样通过共享相同k值的两个签名获得私钥?

问题具体描述:为了创建测试,我撰写了我们的ECDSA签名算法,用它我创建了两个签名,从地址1GXFXm3es….发出,产生买卖56ec7ca7df…这部分签名用了相同的k值(尽管k值永远不可以重复用)。

后来,有人从1GXFXm3es…. 这个地址偷走了0.0016比特币,并将这笔钱发送到了17WRjamox6VhTUaHsTWfFnMNDYHwCtWio。

因此,势必有人在监控区块链是不是存在此类错误,并在遇见此类错误时窃取资金。

那怎么样从共享相同k值的两个签名获得私钥?

Pieter Wuille答: ECDSA签名是(r,s)对,其中r=.x mod n,与s = /k mod n,这里面的x是密钥,k是随机nonce,而m是信息。

对于同一密钥有两个s值s1和s2,并且具备相同的nonce k(从而具备相同的值r),则可以实行以下操作:

从中大家可以得出:

因此,你不仅能够轻松地测试具备相同随机数的签名(它们具备可辨别的r值),而且一旦有人看到两个签名,就会有一个容易的公式来计算私钥。

至少从2013年起,这种攻击就已被广为人知了,也有人在积极借助它,不要重复用k值,用RFC6979确定但安全地生成它们。

还应该注意的是,光k值不同还是不够的,它们也不可以以已知的方法关联在一块,比如,你不可以将k值用于一个签名,然后将k + 1用于下一个签名。

问题7:为何BTC选择Merkle证明,而不选择RSA累加器,两者相比有哪些优势和弊端?

Pieter Wuille答:

1、RSA累加器非常难正确推行;2、RSA累加器需要一个可信设置(单个或多个实体需要得到一个足够大的整数,它是2个素数的乘积,然后将这部分素数丢弃)。BTC的设计一般是为了防止可信方;3、对于128位安全级别,你至少需要3000位RSA模块,这意味着证明将是3000位。 与具备超越12层树的Merkle路径相比,这只是一个优点,对于区块中的买卖而言,这意味着超越4096笔买卖。 一般情况并不是这样,即使这样,也只不过勉强这样。

问题8 : 三种BTC地址类是不是都可以互操作(legacy、segwit、natie segwit)?

问题具体描述:能否在所有3种地址类(legacy、segwit、natie segwit-bech32)之间来回发送买卖?

或者其中一类不可以发送给另一类?

Pieter Wuille:在协议层面,它们都是兼容的,买卖可花费其中任何一类,并发送给其中任何一种。

钱包软件当然可能会有限制,但这部分限制一般与组合无关。

Murch♦补充回答:

在BTC协议中,从任何类的输出发送到任何地址类都没限制,但一些较旧的钱包,可能不支持发送到较新的地址类。

让大家更好地认识一下在发送BTC买卖时,具体可能会发生什么:

接收者选择一个他们想接收资金的地址,这就涉及到一个地址格式,而选择一种更有效的地址格式,可以节省开支,这符合接收者的利益。

发送者选择他们想要花费的输入,输入脚本是由这部分输出之前接收到的地址类设置的。然而,发送者被勉励为他们的找零输出选择一个有效的地址类,以节省将来的本钱。

然而,较旧的电子钱包软件可能没办法发送到较新的地址类。具体来讲,原生隔离见证地址在2017年3月才获得地址标准(BIP-173),并非所有钱包都支持发送到这种地址。在这样的情况下,发送者应该提供一个封装隔离见证地址。所有钱包都要可以发送到封装隔离见证地址,由于它用了2012年推出的Pay to Script Hash 地址标准。

在任何状况下,发送到任何特定地址类的问题,都是由发送方钱包中缺少功能而致使的,而与用的输入类没任何关系。

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
  • 区块链资金投入中,最被忽略

    区块链资金投入中,最被忽略

  • 怎么样设计区块链中的异常处

    怎么样设计区块链中的异常处

  • 技术解码,区块链中的散列函

    技术解码,区块链中的散列函

  • 工业网络+区块链,下一个超级

    工业网络+区块链,下一个超级