概述

一个正常的比特币交易通过引用前一笔交易的交易ID(TXID)来使用至少一个前一笔交易的输出。这些未花费的输出只能被花费一次，如果它们可以被花费两次，你就可以对比特币进行双重支付，使比特币变得毫无价值。然而，在比特币中实际上恰好存在两组完全相同的交易。这种情况之所以可能发生，是因为coinbase交易没有任何交易输入，而是有新生成的币。因此，两个不同的coinbase交易有可能发送相同数量到相同地址，并以完全相同的方式构建，使它们完全相同。由于这些交易是相同的，TXID也相匹配，因为TXID是交易数据的哈希摘要。TXID被复制的唯一其他方式，是哈希碰撞，对于加密安全的哈希函数来说，这被认为是不太可能且不可实现的。像SHA256这样的哈希碰撞在比特币或其他任何地方都从未发生过。

这两组重复交易都发生在相近的时间内，在2010年11月14日08:37 UTC至2010年11月15日00:38 UTC之间，跨度约16小时。第一组重复交易被夹在第二组之间。我们将 d5d2….8599 归类为第一个重复交易，因为它首先成为复制品，尽管奇怪的是，它在区块链上首次出现是在另一个重复交易 e3bf….b468 之后。

重复交易详情

在下面的图片中，可以看到来自mempool.space区块浏览器的两个截图，显示了第一个重复交易在两个不同区块中重复出现的情况。

有趣的是，当在网络浏览器中输入相关网址时， mempool.space 区块浏览器在 d5d2….8599 的情况下默认显示较早的区块，而在 e3bf….b468 的情况下默认显示较晚的区块。Blockstream.info和Btcscan.org与mempool.space有相同的行为。另一方面，根据我们的基本测试，Blockchain.com和Blockchair.com的行为方式不同，当在浏览器中输入URL时，总是显示重复交易的最新版本。

在相关的四个区块中，只有一个区块（区块91,812）包含了其他交易。这笔 交易 将1 BTC和19 BTC的输出合并成了一个20 BTC的输出。

这些输出可以被花费吗？

由于存在两组相同的TXID，这为后续交易创造了引用问题。每个重复交易的价值为50 BTC。因此，这些重复交易总共涉及4 x 50 BTC = 200 BTC，或者根据不同的理解方式，可能涉及2 x 50 BTC = a100 BTC。在某种程度上，有100 BTC实际上并不存在。截至今天，所有200 BTC都未被花费。据我们所知（我们可能在这里是错误的），如果有人拥有与这些输出相关联的私钥，他们可以花费这些比特币。然而，一旦被花费，UTXO将从数据库中删除，重复的50 BTC因此将无法花费并丢失，因此只有100 BTC可能被找回。至于如果这些币被花费，它们将来自哪个区块，是较早的还是最近的，这可能是未定义的或无法确定的。

这个人本可以在创建重复交易之前花费所有比特币，然后创建重复输出，在未花费输出的数据库中创建新条目。这将意味着不仅有重复交易，还有可能有重复的已花费输出的重复交易。如果发生这种情况，当这些输出被花费时，将可能创建更多的重复交易，形成一种重复链。人们必须小心事件的顺序，总是在创建重复之前花费，否则比特币可能永远丢失。这些新的重复交易将不是coinbase交易，而是"正常"交易。幸运的是，这种情况从未发生过。

重复交易的问题

重复交易显然是不好的。它们会给钱包和区块探索者带来混乱，也会让人不清楚比特币的来源。它还会带来许多攻击和漏洞。例如，你可以用两笔重复的交易支付某人两次。然后，当交易方决定尝试使用这笔资金时，他们可能会发现只有一半的资金可以收回。例如，这可以是对交易所的攻击，试图使其破产，而攻击者却没有任何损失，因为他们可以在存款后立即提取资金。

禁止使用重复 TXID 的交易

为了缓解重复交易问题，2012 年 2 月，比特币开发者 Pieter Wuille 提出了 BIP30 软叉方案，禁止使用重复 TXID 进行交易，除非前一个 TXID 已被花费。该软叉适用于 2012 年 3 月 15 日之后的所有区块。

2012 年 9 月，比特币开发者 Greg Maxwell 修改 了这一规则，使 BIP30 检查适用于所有区块，而不仅仅是 2012 年 3 月 15 日之后的区块。本文前面提到的两个重复交易除外。这修复了一些 DOS 漏洞。从技术上讲，这又是一次软叉，尽管规则变更只适用于过去 6 个月以上的区块，因此它不存在与正常协议规则变更相关的任何风险。

这种 BIP30 检查的计算成本很高。节点需要检查新区块中的所有交易输出，并检查这些输出端点是否已存在于 UTXO 中。这可能就是 Wuille 只对未使用的输出进行检查的原因，如果对所有输出都进行检查，计算成本会更高，而且无法进行剪枝。

BIP34

2012 年 7 月，比特币开发者加文-安德森（Gavin Andresen）提出了 BIP34 软分叉方案，并于 2013 年 3 月激活。这一协议变更要求 coinbase 交易包含区块高度，这也使得区块版本管理成为可能。区块高度被添加为币基交易脚本Sig的第一项。coinbase scriptSig 中的第一个字节是区块高度数字所使用的字节数，接下来的字节就是区块高度数字本身。对于第一个 c160 年（223 /（每天 144 个区块 * 每年 365 天）），第一个字节应为 0x03。这就是为什么如今的 coinbase ScriptSig（HEX）总是以 03 开头。这次软分叉似乎彻底解决了重复交易问题，现在所有交易都应该是唯一的。

由于已经采用了 BIP34，2015 年 11 月，比特币开发者亚历克斯-莫科斯（Alex Morcos）向比特币核心软件仓库添加了一个 拉取请求 ，这一更改意味着节点将停止进行 BIP30 检查。毕竟，既然 BIP34 修正了这个问题，那么这种昂贵的检查就不再有必要了。虽然当时还不知道，但从技术上讲，这是为未来一些非常罕见的区块进行的硬分叉。现在看来，潜在的硬分叉并不重要，因为几乎没有人在运行 2015 年 11 月之前的节点软件。在 forkmonitor.info ，我们运行的是2015年10月发布的Bitcoin Core 0.10.3。因此，这是一个硬分叉前的规则，客户端仍在进行昂贵的 BIP30 检查。

区块 ,983,702 问题

事实证明，在 BIP34 激活之前的区块中有一些coinbase交易，当时使用的 scriptSigs 的第一个字节恰好与未来有效的区块高度相匹配。因此，虽然 BIP34 确实在几乎所有情况下都修复了这个问题，但它并不是一个完全的 100% 修复。2018 年，比特币开发者约翰-纽贝里（John Newbery）打印出了这些潜在重复的完整列表，如下表所示。

*注：这些区块已在 2012 年和 2017 年产生Coinbase 交易并非重复。209 921 个区块（距离第一次减半仅差 79 个区块）不可能是重复的，因为 BIP30 在此期间得到了执行。

来源： https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

按年份分列的潜在重复 Coinbase 交易数量

来源： https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

因此，下一个可能出现重复交易的区块是 1,983,702，将于 2046 年 1 月左右产生。2012 年 1 月产生的 164,384 区块中的 Coinbase 交易 向七个不同的输出地址发送了 170 BTC。因此，如果 2046 年的矿工想要进行这次攻击，他们不仅需要足够幸运地找到这个区块，还需要烧掉不到 170 BTC 的费用，总成本略高于 170 BTC，其中包括 0.09765625 BTC 区块补贴的机会成本。按照目前 88500 美元的比特币价格计算，这将花费超过 1500 万美元。至于 2012 年币库交易的七个地址归谁所有，目前还不得而知，密钥很有可能已经丢失。目前，该 Coinbase 交易的所有七个输出地址都已被使用，其中三个在同一笔 交易 中使用。我们认为这些资金可能与 Pirate40 庞氏骗局有关，但这只是我们的推测。因此，这次攻击看起来不仅代价高昂，而且对攻击者来说几乎毫无用处。要在硬分叉中将 31 年前的 2015 年 11 月节点从网络中删除，这将是一笔不小的开支。

下一个可能被复制的脆弱区块是 2012 年 3 月的 169985。这个 Coinbase 只花费了刚刚超过 50 BTC，远远低于 170 BTC。当然，50 BTC 是当时的补贴，而当这一Coinbase交易在 2078 年变得容易被重复时，补贴就会低得多。因此，要利用这一点，矿工将需要烧掉大约 50 BTC 的费用，而这些费用他们是拿不回来的，因为这些费用必须发送到 2012 年的旧产出中。谁也不知道 2078 年比特币的价格会是多少，但这种攻击的成本也可能高得吓人。因此，这个问题可能不是比特币的主要风险，但仍然令人担忧。

自 2017 年 SegWit 升级以来，Coinbase 交易也可以包含对一个区块中所有交易的承诺。这些 BIP34 之前的区块并不包含见证承诺。因此，要产生一个重复的 Coinbase 交易，矿工需要从区块中排除任何 SegWit 输出赎回交易，这进一步增加了攻击的机会成本，因为区块可能无法包含许多其他支付费用的交易。

结论

考虑到复制交易的难度和成本，以及利用它的机会非常罕见，这个复制交易漏洞并不像是比特币的一个主要安全问题。不过，考虑到所涉及的时间尺度和重复交易的新颖性，想想还是挺有意思的。尽管如此，多年来开发人员还是在这个问题上花费了大量时间，2046 年这个日期在一些开发人员心中可能是修复这个问题的最后期限。修复这个错误的方法有很多，可能需要软叉。一种可能的修复方法是强制执行 SegWit 承诺。