LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 币圈百科 > 揭秘比特币白皮书(5)--双花如何发生

揭秘比特币白皮书(5)--双花如何发生

2014-09-28 哈喽 来源:比特儿

  文/哈喽

  双花这次很搞笑,不懂的人会问,是什么花啊,我怎么没听过

  他当然没听过,而且也不会看到。

  因为双花根本就不是一种花。

  我刚刚百度了一下,还真有双花这么一种花,好像可以作为药材,不过不重要了,这跟我们将要谈论的,半毛钱关系都没有。

  在讨论双花之前呢,我们来讲一下《比特币白皮书》中,有关网络的描述,因为这是必要的前提条件,没有区块链网络的支持,谈论双花就好像在盖空中楼阁。

  中本聪在《比特币白皮书》第五小节网络中,是这样说的:

  运行该网络的步骤如下:

  1,新的交易向全网进行广播

  2,每一个节点都将收到的交易信息纳入一个区块中

  3,每个节点都尝试在自己的区块中找到一个具有足够难度的工作量证明

  4,当一个节点找到了一个工作量证明,它就向全网进行广播

  5,当且仅当包含在该区块中的所有交易都是有效的且之前未存在过的,其他节点才认同该区块的有效性

  6,其他节点表示他们接受该区块,而表示接受的方法,则是在跟随该区块的末尾,制造新的区块以延长该链条,而将被接受区块的随机散列值视为先于新区块的随机散列值。

  节点始终都将最长的链条视为正确的链条,并持续工作和延长它。如果有两个节点同时广播不同版本的新区块,那么其他节点在接收到该区块的时间上将存在先后差别。当此情形,他们将在率先收到的区块基础上进行工作,但也会保留另外一个链条,以防后者变成最长的链条。该僵局(tie)的打破要等到下一个工作量证明被发现,而其中的一条链条被证实为是较长的一条,那么在另一条分支链条上工作的节点将转换阵营,开始在较长的链条上工作。

  所谓“新的交易要广播”,实际上不需要抵达全部的节点。只要交易信息能够抵达足够多的节点,那么他们将很快被整合进一个区块中。而区块的广播对被丢弃的信息是具有容错能力的。如果一个节点没有收到某特定区块,那么该节点将会发现自己缺失了某个区块,也就可以提出自己下载该区块的请求。

  好了,有了上面这个基础,我们来举例说明一下,在比特币网络中,双花如何发生,以及它发生的可能性到底大不大。

  首先来说双花如何发生,比如说张三和李四交易,张三是买方,李四是卖方,他们事先约定好通过比特币交易,那么,张三用自己的私钥进行签名,将比特币发给李四,李四等待交易被确认,并且加入区块链,然后才发货。

  表面上看,这似乎没有任何问题,对不对

  但是,注意读我上文罗列出的《比特币白皮书》当中的摘录,从上文中我们不难得出这样一个结论,节点总会切换至最长的分支,那么如果张三在发送比特币之后,能够生成更长的分支,用与其他人的交易,来替代与李四的,那么李四将永远也收不到张三发的比特币,看清楚哦,是永远!

  张三发给李四的这笔交易,会被扔回到未确认的大盘子里,可能还傻乎乎的等待着被确认,但是由于张三已经用另外一笔交易替换了与李四的交易,并且其中援引的是同一笔进账(这里不懂的童鞋,可以看我写的《揭秘比特币白皮书(3)--当你发送比特币,你在发送什么》,里头有详解,你会明白为什么援引的是同一笔进账),那么网络上所有的节点,都会认为张三发给李四比特币的这个交易,是无效的!

  因为它援引了已经被消费了的进账,而这个进账,是被张三自己用其他的交易替换之后,消费掉的,这个其他交易,可以是任何交易,通常情况下,张三会自己发给自己!

  张三要用其他的交易代替与李四的交易。

  你可能会这么想,张三会提前计算出一串区块,然后在适当的时间,上传至网络,但其实每个区块的数学谜题会阻止上述情况的发生(想要详细了解的童鞋,请看《揭秘比特币白皮书(4)--解密区块链》里头有详解)。

  那么张三有没有可能提前计算出一串区块链呢

  下文分解吧。。。。。。

  推广不易!

  BTC: 1N55rYGhX2ck4n9eW9kvueXfhmEmKMjZip

  LTC: LQqGBp8NvwDp1vfUGVGCwgc4fVQkaMSRXH

  NXT: NXT-TZ6N-PA5K-MKE6-CTH4C

  DOGE: DKWvtGX8xSu38zrUtzCArxBPBiMPPJiar7

  BC: BMznrE2Shbb8UPPrJtAiYmoZXE1Vsrk9hM

  欢迎赐币!

—-

文章来源:https://bter.com/article/3096

编译者/作者:哈喽

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...