比特币白皮书(三)

[3. 时间戳服务器]

The solution we propose begins with a timestamp server.

[译] 我们提出的解决方案是先提出一个“时间戳服务器”

[注] 时间戳服务器是用来解决前面提到的双重支付问题的。

A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post

[译] 时间戳服务器通过对对区块内容进行哈希而加上时间戳,并将该哈希值进行广播,像是在新闻或世界性新闻组网络发文章。

[注] 哈希计算:不论哈希前的字节长度,哈希之后得到的字符长度是一样的。如HASH256,哈希之后会产生256 bit的字符,并且哈希前的字符串修改哪怕是一个比特,也会产生不同的哈希值。

如bitcoin字符使用HASH256之后是:

6b88c087247aa2f07ee1c5956b8e1a9f4c7f892a70e324f1bb3d161e05ca107b

那么我把bitcoin改为bjtcoin,使用HASH256之后是:

2d119f3e6dec8efae37d6b8e37ac79948ab3bf7e6783361c8e2f4900c8169f2a

并且通过哈希之后的值反推出哈希之前的值很很难的。这种计算是单向的,即很难反向计算得到哈希计算的值。如求解一个一元二次方程稍微复杂(虽然有现有的公式),但是验证这个解是否正确则非常简单(直接代入计算)。因此,这里也同样,计算得到哈希值简单(有专门的API函数),但是反向求导,则异常困难。

image

[注] 新块的时间戳是由这个块的内容(主要是交易记录)和之前一个块的时间戳(哈希后的哈希值)共同哈希得到。即时间戳是一个数组的哈希值。前面一个块的内容会影响到后一个块的时间戳(哈希值),因此每个块的内容都与后面的时间戳有关。前面提到,如果哈希之前的原始数据中即使其中的一个比特被修改,则最后的哈希值也会改变。因此,如果中间区块的内容被修改,则最后的时间戳也会更改,这时候就会与大多数其他的节点的时间戳不一致。这样就很容易验证出来。

[问题] 这里说的时间戳与实践有没有关联?从上面的描述看,似乎只是交易数据的哈希。将区块串起来形成区块链前面的区块自然就会在前面。时间上更靠前。可是如果没有时间的概念,如何应对双重支付呢?

如果我先支付一笔比特币转账给A,但是我提供很少的矿工费,从而形成打包成区块的时间会更久。在另外一个地方(考虑到交易会广播出去,我子在一个没有接收到我的上一笔交易的节点附近)再用这笔比特币转账给B,这时我提供矿工费多一些,保证能够在转账给A的交易打包之前打包形成区块。这样由于没有时间的概念,从而实现双重支付。

现实中肯定有这种想法的人,如果有这种简单的漏洞,肯定比特币会发现。所以,我认为时间戳还是有一个时间的概念。肯定也有相应的机制来解决上面的问题。是我现在还没有理解到。

看了简书上其他的大神的内容,也基本上有提到时间戳上有使用到时间的,也有说直接是使用哈希然后广播的。我也糊涂了,索性看了下代码简单理一下:

注意到这里有个注释:

那么久认为这里的pblock->nTime是块的时间戳。那么其是传入的参数const CBlockHeader *pblock,那么其结构就是CBlockHeader,对该结构进行查看:

其uint32_t nTime;认为是时间戳,那么这里显然是要记录时间的。

顺便再贴一下简书大神关于时间的理解:时间来自于连接的其他节点(node)时间的中位数(mean,是个数学概念,比平均值更不受极端数字影响),要求连接的节点(node)数量至少为5,中位数和本地系统时间差别不超过70分钟,否则会提醒你更新本机的时间。同时,在接收到新的block时会拒绝时间与自己差距+2小时和-(前11个block时间中位数)的block

上述的理解也不确定是否正确,先记录下来,以后深入理解了再来填坑吧。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180707G1LYWK00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券