Seafooler's Blog

在前一篇博客中，我们介绍了比特币签名机制的基础知识。本篇博客我们将从原理层介绍签名流程。下一篇博客从btcd源码层面讲解签名流程。

在前面的比特币源码分析中，我们有意忽略了签名机制部分的介绍。 但比特币的签名机制远非我们想象的那么简单，正如这篇博客Bitcoin contracts所言：

Bitcoin achieves high flexibility due to three features: 1. scripts — unlocking funds in transactions is done using a simple scripting language, 2. signature hash flags — indicate which parts of the transaction are signed, 3. sequence numbers and lock time — mark transactions as not valid until specified time.

换句话说，正是因为不同签名格式(signature hash flags)的存在，才使得比特币的编程功能更加灵活多变。 接下来的三篇博客即从原理和源码两个角度来分析比特币的签名机制。 本篇博客先介绍基础知识，第二篇博客介绍签名流程的基本原理，第三篇博客从btcd源码层面讲解签名流程。

源码分析所针对的btcd版本为: ed77733ec07dfc8a513741138419b8d9d3de9d2d

前一篇博客btcd源码解析——交易创建中的III.B节介绍了创建output的细节，本篇博客主要介绍input的创建细节。

从本节开始，我们从源码层面关注比特币交易的构建过程。 其中，我们尤其会关注比特币解锁脚本（为了使用UTXO）和新的锁定脚本（为了生成新的UTXO）的创建细节。我们相信通过跟踪两种脚本的创建过程，我们将对于比特币的交易细节理解得更为深入。

新交易的创建会涉及到两个代码仓库（btcd和btcwallet）编译生成的三个可执行文件（btcd，btcctl，和btcwallet）。 btcd和btcwallet代码版本号如下所示：

• btcd版本：[git commit log]: ed77733ec07dfc8a513741138419b8d9d3de9d2d
• btcwallet版本：[git commit log]: ae9416ad7623598121a7c8ad67a202c1be767155

读者如果没有阅读过之前的这两篇博客btcd源码解析和btcd源码解析——从“新区块的生成”开始，强烈建议先阅读完再来阅读本篇博客。

前两篇博客headersFirstMode模式和非headersFirstMode模式主要介绍了区块数据同步过程中两个节点如何交互。但我们当时遗留下一个问题：在peer A接收到区块数据之后，是如何将这个区块存储到本地的。回忆我们在headersFirstMode模式的I.F小节最后提到的

由于block的数据存储过程比较复杂，我们在后面会再写一篇博客介绍：从P2P连接中接收到的block数据是如何存储的

本篇博客主要就来介绍“区块数据的存储过程”。

上一篇博客btcd源码解析——peer节点之间的区块数据同步(2)——headersFirstMode模式介绍了headersFirstMode模式下，peer节点之间的数据同步过程。本篇博客将介绍非headersFirstMode模式下的数据同步过程。 因为本篇博客中的许多函数都已经在上一篇博客中进行了讲解，且在此不会过多赘述，强烈建议读者在阅读完上一篇博客之后再来阅读本篇博客。

上一篇博客btcd源码解析——peer节点之间的区块数据同步 (1)中，我们介绍了peer A是如何发起数据同步的请求的，当时讲到存在两种模式：headersFirstMode模式和非headersFirstMode模式。本篇博客，我们将介绍headersFirstMode模式下数据同步的细节。

从这一篇博客开始，我们将介绍btcd节点之间的数据同步。考虑到内容太长，分为三篇博客来讲解:

• 第一篇 (本篇) 介绍节点是如何发起数据请求的
• 第二篇介绍headersFirstMode模式下的数据同步
• 第三篇介绍非headersFirstMode模式下的数据同步

源码解析是基于btcd仓库c26ffa870fd817666a857af1bf6498fabba1ffe3的commit id 版本。

我们假设peer B是先启动的节点，peer A后启动。peer A在启动后需要从peer B同步数据，那么peer A应该首先向peer B发送数据请求。

我们接着上一篇博客，继续讲解P2P主动连接的管理和被动接受连接的过程。

从这一篇博客开始，我们将介绍btcd节点之间P2P连接建立的过程。考虑到内容太长，分为上下两篇博客来讲解。这两篇博客之后，我们将继续介绍节点之间数据的同步过程。 源码解析是基于btcd仓库c26ffa870fd817666a857af1bf6498fabba1ffe3的commit id 版本。