Skip to content

Latest commit

 

History

History
301 lines (150 loc) · 27 KB

appdx-segwit.md

File metadata and controls

301 lines (150 loc) · 27 KB

附录4、隔离见证

隔离见证(segwit)是一次比特币共识规则和网络协议的升级,其提议和实施将基于BIP-9 软分叉方案,目前尚待激活(译者注:2017年8月24日,区块高度481,824,隔离见证正式激活)。

在密码学中,术语“见证”(witness)被用于形容一个加密难题的解决方案。在比特币中,“见证”满足了一种被放置在一个未使用的交易输出(unspent transaction output, UTXO)上的加密条件。

在比特币语境中,一个数字签名就是一种类型的“见证”(one type of witness)。但“见证”是一个更为广泛的任意解决方案,能够满足加诸于一个UTXO的条件,使UTXO解锁后可被花费。术语“见证”一词是一个更普遍用于“解锁脚本”(或scriptSig)的术语。

在引入“隔离见证”之前,每一个交易输入后面都跟着用来对其解锁的见证数据,见证数据作为输入的一部分被内嵌其中。术语“隔离见证”( segregated witness),或简称为“segwit”,简单理解就是将某个特定输出的签名分离开,或将某个特定输入的脚本进行解锁。用最简单的形式来理解就是“分离解锁脚本”(separate scriptSig),或“分离签名”(separate signature)

因此,隔离见证就是比特币的一种结构性调整,旨在将见证数据部分从一笔交易的scriptSig(解锁脚本)字段移出至一个伴随交易的单独的见证数据结构。客户端请求交易数据时可以选择要或不要该部分伴随的见证数据。

在这一章节,我们将会看到隔离见证的一些好处,描述用于部署和实施该结构性调整的机制,并展示隔离见证在交易和地址中的运用。

隔离见证由以下BIPs定义:

BIP-141隔离见证的主要定义

BIP-143版本0见证程序的交易签名验证

BIP-144对等服务——新的网络消息和序列化格式

BIP-145隔离见证(对于矿工)的 getblocktemplate 升级

4.1为什么需要隔离见证?

隔离见证是一个将在多方面产生影响的结构性调整——可扩展性、安全性、经济刺激以及比特币整体性能:

交易延展性

将见证移出交易后,用作标识符的交易哈希不再包含见证数据。因为见证数据是交易中唯一可被第三方修改(参见 交易识别符 章节)的部分,移除它的同时也移除了交易延展性攻击的机会。通过隔离见证,交易变得对任何人(创建者本人除外)都不可变,这极大地提高了许多其它依赖于高级比特币交易架构的协议的可执行性。比如支付通道、跨连交易和闪电网络。

脚本版本管理

在引入隔离见证脚本后,类似于交易和区块都有其版本号,每一个锁定脚本前也都有了一个脚本版本号。脚本版本号的条件允许脚本语言用一种向后兼容的方式(也就是软分叉升级)升级,以引入新的脚本操作数、语法或语义。非破坏性升级脚本语言的能力将极大地加快比特币的创新速度。

网络和存储扩展

见证数据通常是交易总体积的重要贡献者。更复杂的脚本通常非常大,比如那些用于多重签名或支付通道的脚本。有时候这些脚本占据了一笔交易的大部分(超过75%)空间。通过将见证数据移出交易,隔离见证提升了比特币的可扩展性。节点能够在验证签名后去除见证数据,或在作简单支付验证时整个忽略它。见证数据不需要被发送至所有节点,也不需要被所有节点存储在硬盘中。

签名验证优化

隔离见证升级签名函数(CHECKSIG, CHECKMULTISIG, 等)减少了算法的计算复杂性。引入隔离见证前,用于生成签名的算法需要大量的哈希操作,这些操作与交易的大小成正比。在O(n2)中关于签名操作数量方面,数据哈希计算增加,在所有节点验证签名上引入了大量计算负担。引入隔离见证后,算法更改减少了O(n2)的复杂性。

离线签名改进

隔离见证签名包含了在被签名的哈希散列中,每个输入所引用的值(数量)。在此之前,一个离线签名装置,比如硬件钱包,必须在签署交易前验证每一个输入的数量。这通常是通过大量的数据流来完成的,这些数据是关于以前的交易被引用作为输入的。由于该数量现在是已签名的承诺哈希散列的一部分,因此离线装置不需要以前的交易。如果数量不匹配(被一个折中的在线系统误报),则签名无效。

4.2隔离见证如何工作

乍一看,隔离见证似乎是对交易如何构建的更改,因此是一个交易层面的特性,但事实并非如此。实际上,隔离见证也更改了单个UTXO如何被使用的方式,因此它是一个输出层面的特性。

一个交易可以引用隔离见证输出或传统(内联见证)输出,或者两者皆可。因此,把一个交易称作“隔离见证交易”是没有意义的。但是我们可以把某个特定的交易输出叫做“隔离见证输出”。

当一个交易引用一个UTXO,它必须提供一个见证。如果是传统的UTXO,一个交易在引用它时,UTXO的锁定脚本要求见证数据在该交易输出部分中以“内联”(inline)的方式被提供。但隔离见证UTXO指定的锁定脚本却能满足处于输入之外(被隔离)的见证数据。

4.3软分叉(向后兼容性)

隔离见证对于输出和交易的构建的方式是一个十分重大的改变。这样的改变将通常需要每一个比特币节点和钱包同时发生,以改变共识规则——即所谓的“硬分叉”。但是,隔离见证通过一个更少破坏性的改变引入,这种变化能向后兼容,被称作“软分叉”。这种类型的升级允许未升级的软件去忽略那些改变然后继续去操作避免任何分裂。

隔离见证输出被设计成老的“非隔离见证”系统仍然能够验证它们,对于老的钱包或节点来说,一个隔离见证输出看起来就像一个“任何人都能花费”(anyone can spend)的输出。这样的输出能被一个空的签名花费,因此一个交易里面没有签名(签名被隔离)的事实也并不会导致该交易不被验证。但是,更新的钱包和挖矿节点能够看到隔离见证输出,并期望在交易的见证数据中为该输出找到一个有效的见证。

4.4隔离见证输出和交易示例

让我们来看一些交易示例,看看他们是如何随着隔离见证而改变的。我们将首先看看通过隔离见证程序,如何被改变一个“支付给公钥哈希”(Pay-to-Public-Key-Hash ,P2PKH)的支付。然后,我们再看同样的隔离见证如何作用于“支付给脚本公钥”(Pay-to-Script-Hash ,P2SH)脚本。最后,我们会看看以上两种隔离见证程序如何可以被内嵌入一个 P2SH 脚本。

4.4.1Pay-to-Witness-Public-Key-Hash (P2WPKH)

在【一杯咖啡】的例子中,Alice为一杯咖啡创建了一笔交易去付款给Bob,该笔交易构建了一个价值0.015BTC的 P2PKH 输出(Bob可用来花费),该输出脚本看起来像这样:

P2PKH 输出脚本示例:

DUP HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 EQUALVERIFY CHECKSIG

如果通过隔离见证,Alice将会创建一个“支付给见证公钥哈希”(P2WPKH)脚本,看起来是这样的:

P2WPKH 输出脚本示例:

0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

正如你所见,一个隔离见证输出的锁定脚本相对一个传统输出明显大为简化。它包含两个值,这些值被推送到脚本评估堆栈中。对于一个传统(非隔离见证)比特币客户端来说,这两个推送值看起来像一个任何人都能花费的输出而不需要签名(或者更确切的说,能被空的签名使用)。而对一个更新的、隔离见证客户端来说,第一个数字(0)被解释为一个版本号(见证版本),第二部分(20字节)相当于一个锁定脚本,被称为“见证程序”( witness program)。这20字节的见证程序即是公钥哈希值,就像在 P2PKH 脚本中一样。

现在,让我们来看看Bob用来去花费这个输出相应的交易。对于初始脚本(非隔离见证),Bob的交易必须包含签名在交易输入中:

以下被解码的交易显示了一个 P2PKH 输出被一个签名使用:

[...]“Vin” : ["txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2","vout": 0, "scriptSig": “<Bob’s scriptSig>”,][...]

但是,使用一个隔离见证输出时,交易输入内不存在签名。替代的,Bob的交易只有一个空的 scriptSig ,并在交易本身之外包含了一个隔离见证:

以下被解码的交易显示了一个被隔离见证数据使用的 P2WPKH 输出:

[...]“Vin” : ["txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2","vout": 0, "scriptSig": “”,][...]“witness”: “<Bob’s witness data>”[...]

4.4.2钱包的P2WPKH (Pay-to-Witness-Script-Hash)构造

尤其值得注意的是,P2WPKH 应该只有收款人(接收方)创建,而不是由发送者从已知的公钥、P2PKH 脚本或地址进行转换。发送方无从知道接收者的钱包是否具有能力构建隔离见证交易,并使用 P2WPKH 输出。

另外,P2WPKH 输出必须从被压缩的公钥的哈希值中创建。未压缩公钥在隔离见证中是非标准的,可能会被将来的软分叉明确禁用。如果在 P2WPKH 中使用的哈希值来自未压缩的公钥,那么它可能不可用,您将可能丢失资金。P2WPKH 输出应该由收款人的钱包,通过从钱包私钥中获取压缩公钥进行创建。

警告 P2WPKH 应该由收款人(接收者)通过将被压缩的公钥转换成P2WPKH哈希值进行创建。你绝不应该将P2PKH脚本、比特币地址或未压缩公钥转换成P2WPKH见证脚本。

4.4.3Pay-to-Witness-Script-Hash (P2WSH)

第二种类型的检证程序对应一个“支付给脚本哈希”( Pay-to-Script-Hash , P2SH)脚本。我们在[p2sh]这章中见过。在哪个例子中,穆罕默德的公司使用了P2SH 来表达一个多重签名脚本。对穆罕默德的公司的支付被编码成一个这样的锁定脚本:

P2SH 输出脚本示例:

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

这个P2SH脚本引用了一个赎回脚本( redeem script )的哈希值,改脚本定义了一个“2 of 3”的多重签名需求来使用资金。为了使用该输出,穆罕默德的公司将提供这个赎回脚本(其哈希值与P2SH 输出中的脚本哈希值匹配),以及满足该赎回脚本所需的签名,所有这些都在交易输出中:

显示一个P2SH输出被使用的解码交易:

[...]“Vin” : ["txid": "abcdef12345...","vout": 0, "scriptSig": “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>”,]

现在,让我们看看整个示例如何升级成为隔离见证。如果穆罕默德的客户使用的是一个隔离见证兼容的钱包,他们就会付款,创建一个“支付给脚本哈希”(P2WSH)输出,看起来就像这样:

P2WSH 输出脚本示例:

0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

再一次,就像P2WPKH的例子一样,你可以看到,隔离见证等同脚本要简单得多,省略了各种你在P2SH脚本中见到的脚本操作符。相反,隔离见证程序仅包含两个推送到堆栈的值:一个见证版本(0)和一个32字节的赎回脚本的哈希值。

提示 当P2SH使用20字节的RIPEMD160(SHA256(script)) 哈希值时,P2WSH见证程序使用了一个32字节的SHA256(脚本)哈希值。在选择哈希算法时,这一差异是有意为之,被用于通过哈希值长度来区分两种类型的见证程序(P2WPKH and P2WSH),并为P2WSH(128位 而不是 80 位P2SH)提供更强的安全性。

穆罕默德的公司可以通过提供正确的赎回脚本和足够的签名满足并花出P2WSH输出。作为见证数据的一部分,赎回脚本和签名被隔离在此支出交易之外。在交易输入内部,穆罕默德的钱包会防止一个空的scriptSig:

显示了一个P2WSH输出被用隔离见证数据花出的解码交易:

[...]“Vin” : ["txid": "abcdef12345...","vout": 0, "scriptSig": “”,][...]“witness”: “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>”[...]

4.4.4区分P2WPKH和P2WSH

在前面的两节中,我们展示了两种类型的检证程序:支付给见证公钥哈希 (P2WPKH)和 支付给见证脚本哈希(P2WSH) 。这两种检证程序都有一个字节版本号和一个跟随其后的更长的哈希值组成。它们看起来非常相似,但是被解释得非常不同:一个被解释为一个公钥哈希值,它被一个签名所满足,另一个被解释为一个脚本哈希值,它被一个赎回脚本所满足。他们之间的关键区别是哈希值的长度:

  • P2WPKH中的公钥哈希值是20字节。
  • P2WSH中的脚本哈希值是32字节。

这个区别使得钱包可以对这两种类型的见证程序进行区分。通过查看哈希值的长度,钱包可以确定它是什么类型的见证程序,P2WPKH 或者 P2WSH。

4.5隔离见证升级

正如我们前面看到的例子,隔离见证的升级需要经过两步过程。首先,钱包必须创建特殊的隔离型输出。然后,这些输出可以被知道如何构建隔离见证交易的钱包花费。在这些例子中,Alice的钱包是segwit意识到的,并且能够使用Segregated Witness脚本创建特殊输出。Bob的钱包也是segwit意识到,并能够花这些输出。从这个例子中可能不明显的是,在实践中,Alice的钱包需要知道Bob使用了一个支持segwit的钱包,并可以使用这些输出。否则,如果Bob的钱包没有升级,并且Alice试图对Bob进行隔离见证付款,那么Bob的钱包将无法检测到这些付款。

提示 对于P2WPKH和P2WSH付款类型,发件人和收件人钱包都需要升级才能使用segwit。此外,发件人的钱包需要知道收件人的钱包是否具有隔离识别功能。

隔离见证不会在整个网络中同时实施。相反,隔离见证被实施为向后兼容的升级,其中新老客户可以共存。钱包开发人员将独立升级钱包软件以添加隔离区功能。当发件人和收件人都可以感知到网志时,使用P2WPKH和P2WSH付款类型。传统的P2PKH和P2SH将继续为非升级的钱包工作。这留下了两个重要的情况,下一节将讨论这个情况:

  • 发件人的钱包的能力,不是兼容segwit到付款的收件人的钱包,可以处理segwit交易。
  • 具有隔离识别功能的发件人钱包能够识别和区分具有隔离识别功能的收件人和不是他们地址的收件人。

4.5.1在P2SH中嵌入隔离见证

举个例子,假设Alice的钱包没有升级到segwit,但是Bob的钱包已经升级,可以处理segwit交易。Alice和Bob可以使用“旧”非segwit交易。但是Bob很可能会使用segwit来降低交易费用,利用适用于见证数据的折扣。

在这种情况下,Bob的钱包可以构建一个包含一个segwit脚本的P2SH地址。Alice的钱包认为这是一个“正常的”P2SH地址,并可以在没有任何segwit的知识的情况下付款。然后,Bob的钱包可以通过隔离交易来支付这笔款项,充分利用隔离交易并降低交易费用。

两种形式的见证脚本P2PKH和P2WSH都可以嵌入到P2SH地址中。第一个是P2SH(P2PKH),第二个是P2SH(P2WSH)。

4.5.2在 P2SH 中的 P2WPKH

见证脚本的第一种形式是P2SH(P2WPKH)。这是一个Pay-to-Witness-Public-Key-Hash证明程序,嵌入在Pay-to-Script-Hash脚本中,所以它可以被不知道segwit的钱包使用。

Bob的钱包用Bob的公钥构造了一个P2WPKH见证程序。这个见证程序然后被散列,结果散列被编码为P2SH脚本。P2SH脚本被转换成比特币地址,一个以“3”开始的地址,正如我们在[P2SH]部分看到的那样。

Bob的钱包从我们之前看到的P2WPKH 见证程序开始:

Bob的见证程序:

0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

P2WPKH见证程序由见证版本和Bob的20字节公钥散列组成。

Bob的钱包然后散列之前的见证程序,先用SHA256,然后用RIPEMD160,产生另一个20字节的散列:

P2WPKH见证程序的HASH160

3e0547268b3b19288b3adef9719ec8659f4b2b0b

然后见证程序的hash嵌入到P2SH脚本中:

HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL

最后,P2SH脚本转换为P2SH比特币地址:

37Lx99uaGn5avKBxiW26HjedQE3LrDCZru

现在,Bob可以显示这个地址给顾客付钱买咖啡。Alice的钱包可以支付给不支持隔离见证的地址,就像任何其他比特币地址一样。尽管Alice的钱包不支持segwit,但它创建的付款可以由Bob使用segwit交易进行支付。

4.5.3P2SH内的P2WSH

同样,一个用于multisig脚本或其他复杂脚本的P2WSH见证程序可以嵌入到P2SH脚本和地址中,使得任何钱包都可以进行与segwit兼容的支付。

正如我们在Pay-to-Witness-Script-Hash(P2WSH)中看到的,穆罕默德的公司正在使用隔离见证对多重签名脚本的付款。为了让任何客户支付他的公司,无论他们的钱包是否升级为隔离开关,穆罕默德的钱包都可以在P2SH脚本中嵌入P2WSH见证程序。

首先,穆罕默德的钱包创建与多重签名脚本对应的P2WSH见证程序,并用SHA256进行哈希处理:

穆罕默德的钱包创建了P2WSH见证程序

0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

然后,见证程序本身用SHA256和RIPEMD160散列,产生一个新的20字节散列,如传统的P2SH所使用的散列:

P2WSH见证程序的HASH160

86762607e8fe87c0c37740cddee880988b9455b2

接下来,穆罕默德的钱包将哈希码放入P2SH脚本中:

HASH160 86762607e8fe87c0c37740cddee880988b9455b2 EQUAL

最后,钱包从这个脚本构造一个比特币地址:

3Dwz1MXhM6EfFoJChHCxh1jWHb8GQqRenG

现在,穆罕默德的客户可以付款到这个地址,而不需要支持segwit。然后,穆罕默德的公司可以构建隔离交易来支付这些款项,利用包括较低的交易费用在内的隔离功能。

4.5.4隔离见证地址

在将比特币部署在比特币网络之后,钱包升级之前需要一些时间。因此,很可能像我们在前一节中看到的那样,segwit将主要用于嵌入到P2SH中,至少几个月。

但是,最终几乎所有的钱包都能够支持隔离支付。那时就不再需要在P2SH中嵌入segwit。因此,可能会创建一种新的比特币地址形式,表明接收者是具有隔离意识的,并直接对证人程序进行编码。有关隔离见证人地址计划的建议有很多,但没有一个被积极推行。

4.5.5交易标识符

隔离见证的最大好处之一就是消除了第三方交易延展性。

在segwit之前,交易可以通过第三方微妙地修改其签名,在不改变任何基本属性(输入,输出,金额)的情况下更改其交易ID(散列)。这为拒绝服务攻击创造了机会,以及攻击了编写不好的钱包软件,这些软件假定未经证实的交易哈希是不可变的。

通过引入隔离见证,交易有两个标识符txid和wtxid。传统的交易ID txid是序列化交易的双SHA256散列,没有见证数据。交易wtxid是具有见证数据的交易的新序列化格式的双SHA256散列。

传统txid的计算方式与nonsegwit交易完全相同。但是,由于segwit交易在每个输入中都有空的scriptSigs,因此没有可由第三方修改的部分交易。因此,在隔离交易中,即使交易未经确认,txid也是第三方不可改变的。

wtxid就像一个“扩展的”ID,因为hash也包含了见证数据。如果交易没有见证数据传输,则wtxid和txid是相同的。注意,由于wtxid包含见证数据(签名),并且由于见证数据可能具有延展性,所以在交易确认之前,wtxid应该被认为是可延展的。只有当交易的输入是segwit输入时,第三方才可以认定segwit交易的txid不可变。

提示 隔离见证交易有两个ID:txid和wtxid。txid是没有见证数据的交易的散列,wtxid是包含见证数据的散列。所有输入为隔离开关输入的交易不受第三方交易延展性影响。

4.6隔离见证新的签名算法

隔离见证修改了四个签名验证函数(CHECKSIG,CHECKSIGVERIFY,CHECKMULTISIG和CHECKMULTISIGVERIFY)的语义,改变了交易承诺散列的计算方式。

比特币交易中的签名应用于交易哈希,交易数据计算,锁定数据的特定部分,表明签名者对这些值的承诺。例如,在简单的SIGHASH_ALL类型签名中,承诺哈希包括所有的输入和输出。

不幸的是,计算承诺哈希的方式引入了验证签名的节点可能被迫执行大量哈希计算的可能性。具体而言,散列运算相对于交易中的签名操作的数量增加O(n^2)。因此,攻击者可以通过大量的签名操作创建一个交易,导致整个比特币网络不得不执行数百或数千个哈希操作来验证交易。

Segwit代表了通过改变承诺散列计算方式来解决这个问题的机会。对于segwit版本0见证程序,使用BIP-143中规定的改进的承诺哈希算法进行签名验证。

新算法实现了两个重要目标。首先,散列操作的数量比签名操作的数量增加了一个更加渐进的O(n),减少了用过于复杂的交易创建拒绝服务攻击的机会。其次,承诺散列现在还包括作为承诺的一部分的每个输入的值(金额)。这意味着签名者可以提交特定的输入值,而不需要“获取”并检查输入引用的前一个交易。在离线设备(如硬件钱包)的情况下,这极大地简化了主机与硬件钱包之间的通信,消除了对以前的交易流进行验证的需要。硬件钱包可以接受不可信主机“输入”的输入值。由于签名是无效的,如果输入值不正确,硬件钱包在签名输入之前不需要验证该值。

4.7隔离见证的经济激励

比特币挖掘节点和完整节点会产生用于支持比特币网络和区块链的资源的成本。随着比特币交易量的增加,资源成本(CPU,网络带宽,磁盘空间,内存)也在增加。矿工通过与每次交易的大小(字节)成比例的费用来补偿这些成本。不挖矿的完整的节点没有得到补偿,所以他们承担这些成本,因为他们需要运行一个权威的充分验证全索引节点,可能是因为他们使用节点操作比特币业务。

如果没有交易费用,比特币数据的增长可能会大幅增加。费用旨在通过基于市场的价格发现机制,使比特币用户的需求与交易对网络带来的负担相一致。

基于交易规模的费用计算将交易中的所有数据视为相同的成本。但是从完整节点和矿工的角度来看,交易的某些部分的成本要高得多。加入比特币网络的每笔交易都会影响节点上四种资源的消耗:

  • 磁盘空间

每笔交易都存储在区块链中,并添加到区块链的总大小中。区块链存储在磁盘上,但可以通过“修剪”较旧的交易来优化存储。

  • CPU

每个交易都必须经过验证,这需要CPU时间。

  • 带宽

每笔交易至少通过网络传输一次(通过泛洪传播)。如果在块传播协议中没有任何优化,交易将作为块的一部分再次传输,从而将对网络容量的影响加倍。

  • 内存

验证交易的节点将UTXO索引或整个UTXO设置在内存中,以加速验证。由于内存至少比磁盘贵一个数量级,所以UTXO集的增长对运行节点的成本贡献不成比例。

从列表中可以看出,并不是交易的每个部分都对运行节点的成本或者比特币支持更多交易的能力产生同等的影响。交易中最昂贵的部分是新创建的输出,因为它们被添加到内存中的UTXO集。相比之下,签名(又名见证数据)为网络增加了最小的负担,并且节省了运行节点的成本,因为见证数据只被验证一次,之后又不再使用。此外,在收到新的交易并验证见证数据之后,节点可以立即丢弃该见证数据。如果按照交易规模计算费用,而不区分这两种数据,那么市场上的收费激励就不符合交易实际成本。事实上,目前的费用结构实际上鼓励了相反的行为,因为见证数据是交易的最大部分。

费用所产生的激励因为它们影响钱包的行为。所有的钱包都必须实行一些策略来组合交易,这些策略要考虑到隐私(减少地址重复使用),碎片化(大量松动)以及收费等因素。如果费用压倒性地促使钱包在交易中使用尽可能少的投入,这可能导致UTXO选择和改变地址策略,从而不经意地膨胀UTXO集合。

交易在其输入中消耗UTXO,并用它们的输出创建新的UTXO。因此,交易输入比输出多将导致UTXO集合的减少,而输出多于输入的交易将导致UTXO集合的增加。让我们考虑输入和输出之间的差异,并称之为“Net-new-UTXO”。这是一个重要的指标,因为它告诉我们一个交易对最昂贵的全网资源,内存 UTXO设置。正值Net-new-UTXO交易增加了这一负担。负值Net-new-UTXO交易减轻了负担。因此,我们希望鼓励交易是负Net-new-UTXO或零Net-new-UTXO的中值。

让我们来看一个例子,说明有无隔离见证交易费用计算产生了哪些激励措施。我们将看两个不同的交易。交易A是3输入,2输出的交易,其具有-1的净新UTXO度量,这意味着它消耗比它创建的多一个UTXO,将UTXO减1。交易B是2输入3输出的交易,其具有1的净新UTXO度量,这意味着它向UTXO集增加一个UTXO,对整个比特币网络施加额外的成本。这两个交易都使用多重签名(2/3)脚本来演示复杂脚本如何增加隔离证人对费用的影响。我们假设交易费为每字节30 satoshi,证据数据为75%的折扣费用:

  • 未使用隔离见证

    交易费用:25,710 satoshi 交易B费用:18,990 satoshi

  • 使用隔离见证

    交易手续费:8,130 satoshi 交易B手续费:12,045 satoshi

当隔离见证实施时,这两个交易都较为便宜。但是比较这两笔交易的成本,我们发现在隔离见证之前,交易净收益为负的净新UTXO的收费更高。在隔离见证之后,交易费用与最小化新的UTXO创造的激励相一致,而不会无意中惩罚许多输入的交易。

因此,隔离见证对比特币用户支付的费用有两个主要的影响。首先,segwit通过折扣见证数据和增加比特币区块链的能力来降低交易的总体成本。其次,segwit对证人数据的折扣纠正了可能无意中在UTXO集合中产生更多膨胀的激励的错位。