比特币交易可变性,零变化输入及其如何影响比特币交易

交易延展性再次影响整个比特币网络。通常,这会导致很多混乱,并且导致看似重复的事务,直到下一个块被挖掘。这可以看作如下:

  • 您的原始交易从未确认。
  • 出现另一笔交易,具有相同数量的硬币往返于同一地址。这有不同的交易ID。

通常,这个不同的交易ID会确认,在某些块浏览器中,您会看到有关原始交易是双重花费或其他无效的警告。

最终,只有一个交易,如果发送了正确数量的比特币,应该确认。如果没有交易确认,或者多个交易确认,那么这可能与交易延展性没有直接关系。

然而,有人注意到有些交易已发送但尚未发生变异,也未能确认。这是因为它们依赖于之前也无法确认的输入。

基本上,比特币交易涉及支出投入(可以将比特币称为比特币地址内的比特币)然后得到一些改变。例如,如果我有10 BTC的单个输入并且想要向某人发送1 BTC,我将创建如下交易:

10 BTC - > 1 BTC(对用户)和9 BTC(回到我自己) )

这样,可以为初始挖掘交易中的所有比特币创建一种链。

当比特币核心进行这样的交易时,它相信它将获得9 BTC的变化,它会因为它本身产生了这个交易,或者至少,整个交易都不会确认,但没有任何东西丢失。它可以立即在另一个交易中发送这个9 BTC而无需等待确认,因为它知道硬币的去向,并且它知道网络中的交易信息。

然而,这种假设是错误的。

如果交易发生变异,比特币核心最终可能会尝试使用9 BTC更改创建新交易,但基于错误的输入信息。这是因为实际的交易ID和相关数据在区块链中发生了变化。

因此,比特币核心永远不应该信任自己,并且在发送此更改之前应该始终等待确认更改。

比特币交换可以将其主要比特币节点配置为不再允许更改,零确认,包含在任何比特币交易中。这可以通过使用-spendzeroconfchange = 0选项运行bitcoind来配置。

这是不够的,这可能导致无法发送事务的情况,因为没有足够的输入,至少有一个确认要发送一项新交易。因此,我们还运行一个执行以下操作的过程:

    1. 通过调用bitcoin-cli listunspent 1检查可用的,未使用但已确认的输入。
    2. 如果少于x个输入(当前为12个),则执行以下操作:

 

    1. 计算大约10 BTC的输入。
    2. 计算如何将其分成尽可能多的1个BTC交易,留出足够的空间以收费。
    3. 调用bitcoin-cli sendmany发送~10 BTC输入到大约10个输出地址,全部归比特币市场所有。

这样,我们可以将一个10 BTC输入转换成大约10个1 BTC输入,这些输入可用于进一步的交易。当我们在输入上“低位”时,我们会这样做,剩下的就会减少12个。

这些步骤确保我们只会发送具有完全确认输入的交易。

在我们实施此更改之前仍然存在一个问题,一些交易发送依赖于变异变化,永远不会被确认。

目前,我们正在研究重新发送这些交易的最佳方式。我们可能会在非高峰时间消除这些交易,尽管我们想要逐项列出我们认为应该事先消除的所有交易,这将需要一些时间。

一种简单的技术可以降低可塑性成为问题的机会让您的比特币节点连接到尽可能多的其他节点。这样,你就会“大喊”你的新交易并让它很快流行,这可能意味着任何变异的交易都会被淹没并首先被拒绝。

有一些节点有反突变代码已经。这些能够检测变异的事务并仅传递经过验证的事务。连接到这样的可信节点是有用的,值得考虑实现它(当然会有自己的风险)。

所有这些延展性问题一旦BIP 62增强比特币实施就不会成为问题,这将使延展性变得不可能。遗憾的是,目前还没有参考实现,更不用说迁移到新块类型的计划了。

虽然只给出了简单的思路,但未来版本的比特币软件有可能被检测到当变更输入发生可塑性时,然后执行以下操作之一:

  1. 将此交易标记为已拒绝并将其从钱包中删除,因为我们知道它永远无法确认(可能存在风险,特别是如果存在重组) 。可能通知节点所有者。
  2. 尝试“重新包装”事务,即使用相同的地址和地址参数,但使用块中接受的来自更改事务的正确输入详细信息。

来源, 作者: Marc Warne

0

发表评论

电子邮件地址不会被公开。 必填项已用*标注

微信扫一扫

微信扫一扫

微信扫一扫,分享到朋友圈

比特币交易可变性,零变化输入及其如何影响比特币交易
返回顶部

显示

忘记密码?

显示

显示

获取验证码

Close