重建比特币 4：数字签名

0.前言

上一篇讲了对称加密，我们发现不需要对所有的交易消息进行加密，因为交易数据不怕光。只需要加密一小部分，究竟应该加密什么？

1.签名

因为我们的根本目的不是防止别人看到交易数据的明文，而只是用密文证明“我就是我”。那么我的要求是加密尽可能少的单词，即加密付款人的名字。

为什么是这样？

灵感通常来自现实生活中的例子。赵四想买拖拉机，钱不够，就向刘能借了一万块钱，刘能让赵四写借条。赵四当然不想写，所以赵四说他不会写。刘能当然放不下，所以刘能给赵四写了一张借条：“赵四欠刘能一万块钱”，但是这张借条没有法律效力，因为赵四可以说刘能是个瞎子. 书面。所以为了让这张借条成为证据，赵四至少要签上自己的名字。因为赵四的笔迹是世上唯一的，所以赵四签下了自己的名字，表示有名字的人认出了这张借条的内容。如果赵四的签名不是自己的名字，这张借条就无效，也就是说赵四' s 唯一的笔迹只有在写上他的名字时才有效。（见下文）

符号

赵四的写法是私钥，因为赵四在全世界都可以这样写。两个标准汉字“赵四”是公钥，赵四的私钥（写法）只能加密自己的公钥。使用密钥（“赵四”）时，具有法律效力。加密别人的公钥（签名别人的名字）是无效的。相反，法官看到赵四的签名（搞砸的签名，相当于加密后的密文），可以用公钥来解密签名，因为公钥是“赵四”，所以法官可以调出法庭保存的签名库，找到赵四过去的签名进行比对。

实际上，我们把借条上的名字叫做签名，而签名是证明“我就是我”的最小文字。

根据上面得到的启示，借用比特币交易系统，爱丽丝可以用她的私钥加密自己的名字作为证明，加密后的密文称为数字签名。（见下文）

使用数字签名证明爱丽丝就是爱丽丝

2.签名用户名漏洞

中本聪在脑海里一遍遍模拟系统的运行，突然发现了一个漏洞。

这个漏洞是因为服务器没有存储用户名和公钥的映射关系，所以不知道Alice的公钥是什么。如果有人用自己的公钥签了别人的名字，在法律上就相当于李斯在借条上签了谢大娇的名字，是无效的。但在目前的设计中，服务器不具备判断能力，因为服务器没有类似法庭的签名数据库。

如果 Carol 想要窃取 Alice 的比特币：

1.Carol 创建了一个虚假交易：“Alice to Carol 40”。

2.Carol 用 Alice 的私钥加密了 Alice 的用户名，并得到了一个伪造的签名：“806535be3e”。

3.然后将Carol的公钥+伪造的签名+伪造的交易数据放入消息中，发送给比特币服务器。

4.服务器接收到消息并解析得到三部分：公钥、签名、交易数据。

5.服务器使用Carol的公钥解密Carol的伪造签名，得到明文用户名：“Alice”。

6.服务器只会验证签名明文“Alice”与交易数据中的付款人“Alice”是否相等。

问题出在这里，服务器无法验证消息中收到的公钥是否是 Alice 的，而本例中的公钥是 Carol 的。因为服务器没有存储公钥和用户的映射关系，所以无法判断。

7.服务器验证通过，交易写入账本，交易生效！Carol 成功冒充 Alice，将 40 个比特币转给了自己。（见下文）

使用用户名作为签名的漏洞

3.公钥代替用户名

那么这个漏洞的关键点在哪里呢？

关键是，虽然服务器可以解密签名明文的用户名，但是服务器不知道消息中的用户名和公钥是否属于同一个人，也就是说服务器不知道 Alice 的公钥是什么。不确定 Carol 的公钥是什么？所以Carol可以使用他的私钥来签署用户名“Alice”的签名。服务器用卡罗尔的公钥解密签名，自然可以解锁。

所以选择要签名的用户名是行不通的。

如何绕过这个漏洞？

中本聪和吉尔福伊尔开始思考。

如果我们让服务器存储用户名和公钥的对应关系，我们将回到账户模型的旧方式。

那么根本的解决办法是什么？

中本聪突然灵机一动：“根本的解决办法就是放弃用户名！干脆用公钥代替用户名！”

同样的场景：如果Carol想要伪造Alice转给自己的一段交易数据，则将前面例子中的“Alice to Carol 40”变成“public key A to public key C 40”，其中我们使用public key A 代表 Alice 的公钥，公钥 C 代表 Carol 的公钥。

整个过程是这样的：

1.Carol 创建了一个虚假的交易数据：“公钥 A 到公钥 C 40”，这意味着 Alice 的公钥将 40 个比特币转移到了 Carol 的公钥。

2.Carol 用 Alice 的私钥加密了 Alice 的公钥 A，得到了一个伪造的签名：“f9293ued3”。

3.然后将公钥C+伪造签名+伪造交易数据放入消息中，通过网络发送给比特币服务器。

4.服务器接收到消息并解析得到三部分：公钥、签名、交易数据。

5.服务器使用Carol的公钥解密Carol的伪造签名，得到明文用户名：“公钥A”（即Alice的公钥）。

6.服务器启动验证逻辑：比较消息中的公钥C和签名中解密的公钥A是否相等。显然，这两个公钥不相等，因此可以确定该交易是非法的。

7.服务器拒绝继续处理，交易无效。

这样就解决了上述漏洞，只需要将签名从加密的用户名改为加密的公钥即可。（见下文）

公钥而不是用户名

4.为交易模型添加签名

中本聪在脑海中模拟并运行了几次系统，突然又出现了一个灵感：“当前消息由三部分组成：公钥、签名和交易数据。可以在这里进行优化。首先，你可以去掉消息中的公钥参数，因为和交易数据中付款人的公钥是一样的，另外消息中的签名参数也可以去掉，我们把签名放到交易中数据，改变交易的模型，增加一个签名字段比特币公钥保存在哪里，这样签名就可以作为交易数据的一部分写入账本，并且可以永远被检查。”

Gilfoyle 说：“这样的改变是非常合理的！在交易模型中增加一个签名字段是很有必要的，因为每个交易的签名都应该和交易的业务数据一起存储，并且不能分开。就像描述文本和签名一样。借条。同样不能分开，如果分开，就等于借条被撕成两半，不再具有法律效力。（见下图）

消息的转换

改造后的完整交易是这样的（见下图）

改造交易模型后的交易

“到此为止，用户名是没有用的，因为公钥可以代替用户名，user.txt没有存在的意义，终于可以彻底抛弃账户模型了！” 中本聪终于解决了用户注册的问题。到一个根本的解决方案。

Gilfoyle 说：“我们可以将用户的公钥理解为接收付款的地址，而不仅仅是用户名，尽管它们本质上是相同的。”

“这是一个很好的见解！就像我订购报纸时，我不必告诉送货员我的名字，我只告诉他我的邮寄地址。将公钥理解为付款地址而不是用户名，真的更符合日常生活体验。”

“我准备开始编码并升级到只有账本模型的新版本，”中本聪一边说，一边打开电脑快速打字。

吉尔福伊尔慢条斯理地说：“我能帮忙吗？”。

中本聪说：“太好了！数据部分你可以改，程序部分我来做比特币公钥保存在哪里，服务器的密码我告诉你。”

Gilfoyle按照刚才的讨论进入服务器，开始修改数据模型。

首先删除user.txt。

然后将transaction.txt中的用户名改成用户的公钥。

最后将签名字段添加到事务模型中。（见下文）

数据模型的转换

5.后记

故事中的比特币系统引入了数字签名，最终放弃了账户模式。

但是目前的设计存在设计漏洞，因为用户的签名不会每次都改变，所以存在被复用的漏洞。例如，如果 Alice 向 Carol 支付了 50 个比特币，那么 Carol 就有动机拦截交易数据并向服务器多次发出相同的请求。服务器会误以为 Alice 多次自愿向 Carol 支付了 50Bitcoin，直到 Alice 的余额减少到 50bitcion 以下。

这个错误将在以后的故事中修复。

BSV提示地址：1BudFu186jzdP9CBJTTPGsdbSJinbzzCyB