从BTC地址和交易原理谁控制比特币

比特币地址有以 1 开头的地址和以 3 开头的地址，这两者有什么区别吗？

什么情况下地址上的比特币会被锁定？

到底是谁控制了比特币，是你吗？还是你的钱包？

如果您使用的是比特币钱包并且无法回答上述三个问题，那么本文适合您。

SECBIT Labs 在审核数字钱包的源代码时比特币是谁在控制，发现一个名为 pywallet 的比特币钱包开源库存在严重缺陷。如果您将资金转移到 pywallet 生成的 OmniLayer 收款地址，将导致资产永久丢失。

根据 SECBIT Labs 的区块链技术专家 zer0to0ne 的说法，OmniLayer 协议允许在比特币区块链上发行自定义资产（例如 USDT）。OmniLayer 资产交易的本质是比特币交易。比特币交易有很多代码库，pywallet 就是其中之一。它可以轻松构建符合 OmniLayer 格式的比特币交易。目前，pywallet已经应用在一些数字钱包软件中。

但是在生成OmniLayer钱包地址的时候，开源库pywallet错误地把地址的前缀写反了，导致多个资产被锁定在无效地址！

以下是pywallet相关错误码截图：

文件地址：#diff-ca3a8be6f2ab4be3bfd69a49f5f4122a

插队科普：比特币网络上最常见的地址类型有三种：普通公钥地址（1-address）、脚本哈希地址（3-address）和隔离见证地址（bc1-address）。前缀来区分。1-address 的前缀是 0x00，3-address 的前缀是 0x05。

1-Address：这是最常见的比特币地址，通常用于普通转账和支付。1-地址实际上是公钥哈希的编码。验证 1-address 的签名后，支付被解锁。

3-Address：这个地址是脚本哈希地址。这种类型的地址实际上对应于比特币脚本哈希的代码。

bc1-address：用于隔离见证交易的 bech32 编码地址。

开源库pywallet将地址前缀反转，误将1-address设置为3-address。因此，原本打算转移到 1-address 的资产将被错误地转移到 3-address。当账户持有人使用1地址验证方式，即私钥签名提取资产时，区块链网络通过3地址脚本执行方式进行验证，用户无法正常提取资产！

请谨慎使用pywallet开源库

真相：比特币从未真正进行过汇款

这出乎很多人的意料，因为比特币的实现是基于UTXO模型，与我们直观理解的账户模型不同。zer0to0ne 解释说，事实上，比特币从来没有真正实现过通常意义上的传递函数。中本聪只为比特币设计了一系列比特币脚本算子和比特币脚本执行器，而所谓的转账过程其实就是模拟了一个比特币脚本加锁和解锁的过程。这与日常生活中的账本（或称为账户模型）的概念并不相同。

为了便于理解，我们可以将比特币区块链上的资产交易比作将资产锁定在保险箱中，只有持有保险箱钥匙的人（即收款人）才能取出保险箱中的资产进行交易。例如，如果 Alice 想向 Bob 支付一项资产，Alice 将该资产锁定在保险箱中，只有 Bob 拥有保险箱的钥匙，即只有 Bob 可以取出该资产。如果 Bob 想要提取资产，则 Bob 需要同时花费该资产（即将其锁定在另一个保险箱中）。在 Bob 取出资产之前，这些资产并不真正属于 Bob。假设如果 Bob 丢失了密钥，资产将无法再被检索。换句话说，虽然资产仍在保险箱中，但它既不属于 Alice，也不完全属于 Bob。当然，Alice 也可以将资产放入任何人都可以打开的保险箱中，

由于比特币区块链上的接收地址不同，保险箱的类型也各不相同。不同类型的保险箱需要不同类型的钥匙才能打开。付款人为收款人定制保险箱，将资产放入保险箱并上锁，然后将保险箱扔到公共场所。有两种方法可以打开保险箱：

• 如果收款人是1-address，我们称该保险箱为Type 1 保险箱。对应的key必须是指定支付地址对应的私钥。保险箱的解锁过程是验证1-address公钥和公钥对应的数字签名。

• 如果收款人是3-address，我们称其为3-type 保险箱。解锁密钥必须是可执行的比特币脚本。保险箱的解锁过程如下：比特币脚本的hash值对应3-address，比特币脚本执行器运行脚本后成功返回。也就是说，只有拥有原始脚本并且能够成功执行的人才能提取这个保险箱中的资产。

回到本节的问题：为什么比特币从来没有实现过真正意义上的传递函数。答案很简单，因为在比特币系统中根本不存在账户的概念，也没有办法谈账户之间的转账。未来一个人可以打开多少个保险箱也是未知数。

通过上面的解释我们可以知道，当pywallet开源库误将1-address识别为3-address时，就像是把原来的1-type保险柜改成了3-type保险柜，账户持有人仍然持有1 - 解锁等级保险柜的钥匙，那么保险柜自然无法打开。那么被 zer0to0ne 意外锁定的 OmniLayer 数字资产能否恢复？

是否有可能使用 1 地址钥匙打开 3 保险箱？

zer0to0ne 随后详细解释了 P2PKH（Pay to Public Key Hash）和 P2SH（Pay to Script Hash）两个重要概念的来龙去脉。这两个名词代表两种不同类型的比特币交易。

以下是zer0to0ne的精彩技术分析

P2PKH——中本聪的伟大发明

Pay to Public Key Hash，顾名思义，就是把比特币放进保险箱，钥匙孔就是公钥哈希（Public Key Hash）。我们看到的最常见的 1-address 本质上是公钥哈希的编码。1-地址的生成过程也很简单。公钥通过Hash160运算得到Public Key Hash，在Public Key Hash的头部加前缀0x00，在Hash尾部加校验和，得到以1开头的比特币基数 58。地址。

Base58(0x00 + + 校验和)

下面我们来看看P2PKH交易类型的安全构建过程。以 Alice 向 Bob 发送比特币为例：

付款人 Alice 在构建保险箱时需要设置一个锁定脚本：

OP_DUPOP_HASH160（包含在 Bob 支付地址中的公钥哈希） OP_EQUALVERIFYOP_CHECKSIG

注意：我们可以将这一步理解为 Alice 为 Bob 定制了一个保险箱，将比特币放入保险箱并用 Bob 的公钥 PubKey Hash 锁定。现在，除了持有私钥的 Bob 之外，任何人都无法打开此锁。

当 Bob 需要花费 Alice 给他的比特币时，他需要提供必要的参数：交易签名 + 公钥（技术术语：scriptSig）来打开保险箱，这样锁脚本在执行后返回 True比特币是谁在控制，通常是这样做的自动由钱包。

我们来看看比特币节点如何验证scriptSig的合法性。

（图片来自掌握比特币）

脚本执行流程如图所示。Bob 对交易后得到的数据进行签名（其实也包括数据长度信息）。真正的scriptSig应该是，比特币脚本执行器从PUSH数据开始，PUSH操作会先读取到要入栈的数据的长度信息，以字节为单位，然后继续执行比特币脚本，直到最终执行完成，检查执行结果。

首先将其压入堆栈，然后将其压入堆栈。DUP 操作将复制堆栈顶部的副本。HASH160弹出栈顶并计算Hash，将结果推回栈中，然后使用EQUALVERIFY弹出Hash，比较是否相等。如果它们相等则返回 True，如果它们不相等，则交易被标记为无效。此时公开了公钥，保证了签名者身份的正确性，但是黑客或矿工可以通过公开的公钥构造一个新的交易来代替原来的交易，不能保证安全，那么就需要进行下一步了。保证交易不能被伪造。这时候栈上还有一个sum，

数字签名只能由持有私钥的人伪造。至此，一笔比特币P2PKH交易已经安全完成。

再解释一下：当 Bob 想要花掉 Alice 给他的比特币时，Bob 只能用正确的钥匙打开 Alice 留给他的保险箱，将钱放入 Bob 建造的新保险箱。

这时，一些聪明的读者会注意到一个细节：如果 Bob 取出钥匙，区块链上的任何矿工在打开保险箱之前都可以看到钥匙的形状，理论上可以立即复制。用于打开和花费 Alice 留给 Bob 的保险箱的钥匙（通常称为 Front-running 攻击）。真的有可能做到这一点吗？显然中本聪想到了这一点，这个密钥中的交易签名就是 Bob 发起的交易的完整签名。假设 Bob 想要将 Alice 构建的保险箱中的比特币放入一个新的保险箱（给 Charlie）。此时，Bob 显示的密钥包含 Charlie 的公钥 Hash。虽然矿工可以复制 Bob 的密钥，但是这个密钥下一个新保险箱的密钥信息已经被隐藏了，

P2SH——后中本聪时代的重大创新

中本聪设计了如此强大的脚本系统。只构建转账交易似乎太浪费了。让我们尝试用其他指令构造一些特殊的锁定脚本，并使用其他方法来解锁它们。

例如，我们可以构建一个使用 Hash 原像来解锁交易的脚本：

OP_HASH160OP_EQUAL

这个脚本的意思是：当Hash160(Pre-image)==这个条件满足时，脚本就可以成功解锁了。

我们以保险柜为例继续说明，称这种保险柜为三型保险柜。现在 Alice 给 Bob 的比特币被锁在了一个由上面的 Hash160 保护的保险箱里，我们姑且称之为哈希锁。

锁仍然需要正确的形状才能打开，但安全性要弱得多。缺少数字签名机制导致密钥隐藏的密钥信息不会随着 Bob 的新保险箱而改变。任何矿工都可以在 Bob 出示密钥的那一刻复制完全相同的密钥，急于打开 Alice 留给 Bob 的保险柜（Front-running），将硬币转移给另一个人 Eve，所以它原本是属于 Bob 的。比特币将被洗劫一空。

虽然这个脚本很不安全，但它有两个非常神奇的功能：

1. 交易结构的输出足够短，这意味着比特币节点维护的UTXO缓存占用的空间会明显减少

2. 交易花费时，前映像始终作为输入引用，不会出现在交易的输出端。UTXO 保持精简，手续费的负担可以转嫁给接收方。

既然描述的输出脚本有很多好处，有没有办法让这个交易安全？这就需要谈谈什么是P2SH。

比特币核心开发人员 Gavin Adresen 提出了一种称为 Pay to Script Hash (P2SH) 的技术。

P2SH的交易输出还是判断Hash160(Script)==