比特币白皮书（三）

[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

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