限制条款与 “多人共享的 UTXO”

[editor-Ajian]

我注意到，最近，限制条款（covenant）得到了更多的讨论；同时，人们也在关注如何获得（比闪电网络）更大的可扩展性。这两类讨论往往相互关联，最终指向同一种资金保管形式：多人共享同一个 UTXO。如果多个人（比如，超过两个人）可以共享同一个 UTXO，则显然它的可扩展性更好；同时，为了让多人能够共享同一个 UTXO，使用现有的操作码和承诺交易可能难以令人满意，我们需要限制条款来帮助我们。

也正因此，这样 “多人共享的 UTXO”，不论在具体场景中叫什么名字，一直是限制条款提议支持者认为限制条款可以给比特币带来的新的用途。

本文正想通过对 “多人共享的 UTXO” 这种形式的研究，来探讨限制条款的用途和局限性。

限制条款

在本文中，我们可能会接触到以下几种限制条款（它们全都仍然处于提议阶段）：

• BIP-119 OP_CHECKTEMPLEVERIFY（CTV）。这种操作码可以在脚本中放置一个哈希值，使得该脚本只能被该哈希值所承诺的交易花费 [1] 。这样的哈希值并不等同于 txID，因为它不承诺输入，所以，你可以认为它所承诺的是资金的流向（会产生什么样的输出）。此外，还可以承诺一些比如交易级时间锁、输入数量这样的属性。

  • 例如，假设我们现在有一个价值 1000 聪的输出，将它花费到 A、B、C 三个地址分别 200 聪（剩下 400 聪当手续费）的交易将具有模板哈希值 H。那么，如果我们在这个输出中使用 CTV 和 H，这个输出将只能被花费到这三个地址，分别 200 聪；任何其它交易都无法通过脚本检查。

• BIP-118 SIGHASH_ANYPREVOUT（APO）。使用该签名模式可以生成一种签名，该签名不承诺要花费哪一个 UTXO，因此，所有使用相同公钥的输入（交易），都可以使用这样的签名。因此，如果我们有一串交易，每一个交易所用的输入都具有相同的脚本，并将资金转移到相同的脚本输出内，那么，对这串交易中的任何一个交易的 APO 签名，也将可以用于所有其它交易。

  • APO 签名的用法并不是只签一次名，相反，它的用法是：每当出现了新的交易，我们就签一次名，但这个新的签名将可以花费前面所有的交易；只要我们在脚本中包含绝对时间锁检查，并使用它来作为交易的编号，我们就可以保证，更新的签名总是可以花费较老的交易，而较老的签名无法花费较新的交易，从而，我们可以放心删除较老的交易，只保留最新的交易 —— 这就是 “Eltoo” 协议 [2] ，它使得闪电通道中的双方不必保存每一笔承诺交易及其撤销密钥，只需保存双方签名的最新一笔交易即可，因为对手发布的任何较老的交易，都可以被这笔最新的交易花费，从而得到通道的最新状态。

此外，本文还会涉及的技术概念有：

• Taproot（MAST）：它使我们可以方便地为一个输出安排多个脚本花费条件，并且，可以被承诺的花费条件在数量上几乎是没有上限的，因为在输出被花费时，只有最终被使用的条件才会曝光（存在的其它条件无需曝光）。
  • 所以，我们可以在一个输出中安排 20 个花费路径，每个路径中都使用了 CTV 和某一个哈希值 —— 也就是让这个输出只能被这 20 个交易花费 ……
• 承诺交易：指参与者签过名、可以发布到链上，但默认不发布的交易。这样的交易有许多用途，例如，闪电通道中的支付就是通过双方交换承诺交易来实现的。顾名思义，它代表着签名者的承诺，是得到签名的用户保护自己的手段。
  • 承诺交易是我们衡量限制条款方案有用性的基准。如果承诺交易本身就可以为用户提供保护并限制参与者的行为，那么限制条款带来的提升在哪里？这是本文的思考方法之一。

下面，我们先通过一些外围的概念，以逐步接近我们想要探讨的概念。

闪电通道

没错，闪电通道也是一种形式的 “多人共享的 UTXO”，它是一个 2-of-2 的多签名输出，一般来说参与者有两个人。在闪电通道中，双方通过签名新的承诺交易来表达新的通道内状态，从而实现支付。而为了确保较旧的承诺交易不会被发到链上，承诺交易的一个输出中带有精心设置的脚本；当某一方将较旧的承诺交易发到链上，该交易为 TA 分配的资金会被对方全部拿走。这种惩罚机制（叫做 “LN-Penalty”）阻止了通道的参与者将旧状态发布到链上。

承诺交易和 LN-Penalty 保证了通道的免信任性：任何一方都可以随时以通道的最新状态退出通道。当某一方强制关闭通道时，另一方的资金会退出到链上，不会有损失。

在这里，CTV 能够提供的提升是非常有限的。CTV 可以用来预先承诺交易，但对通道来说，双方会不断更新状态。CTV 并不能提供超过 LN-Penalty 和承诺交易的保护作用，也不能简化它们 —— LN-Penalty 已经很紧凑了。

不过，APO 倒是能提供明显的提升。如前所述，APO 让用户可以只保留最新的承诺交易和签名，而无需保留旧的承诺交易和签名，这大大节约了硬盘，也让通道用户的交互以及交易的输出都变得更加简单。值得一提的是，更新状态依然需要双方都在线、签名。

（联盟）侧链

侧链也是一种 “多人共享的 UTXO”。在当前的比特币上，包括 Liquid Network 和 RSK 在内的双向侧链都使用了多签名输出（例如，11-of-15 的联盟）来保管资金。这样的输出保管的是不止一个用户的钱。当用户要进入侧链时，就要把资金存入这样的多签名输出；在这些输出被合并之前，用户有专属于自己的输出，但在资金合并之后，一个输出就将掌控许多个用户的钱。当用户要退出侧链时，也需要从这样的输出中取出资金 —— 这需要联盟成员的帮助才可以做到。

没错，在这里，侧链是一种需要信任的结构。用户需要信任这 15 个成员中不会有 11 个人串通起来盗走资金，也不会有 6 个以上的人串谋让侧链停机。而用户获得的好处是，他们可以在侧链上更新状态而无需支付主链的手续费；同时，侧链可以提供主链所没有的功能。那么侧链内部如何更新状态呢？在联盟成员间运行一套共识算法，以得出各个用户的最新状态。

也许，正是侧链这种需要信任的属性，推动人们思考有无更好的形式，比如，一种免信任的结构，让每一个用户都能不需要他人配合就能随时取款。

Fedimint

Fedimint 跟联盟侧链一样，也使用多签名输出来托管资金。有区别的地方在于，它并不使用共识算法来更新 Fedimint 内部的状态，它使用的是联盟成员的盲签名 —— 用户存入资金之后，就可以获得联盟签发的盲签名票据，这些票据允许用户们相互支付，也可以用来兑现主网的资金。但是，fedimint 依然是一种需要信任的结构。

下面我们进入一种追求免信任性的 “多人共享 UTXO” 构造。

Payment Pool / 拥堵控制

Payment Pool（“支付池”）所追求的 [3]，正是让多人共享的 UTXO 变成免信任的：最起码，这意味着，在这样的 UTXO 中的人，知道自己一定能够无需他人的协助就从中取出属于自己的资金。

我们先看看承诺交易如何做到这一点。假设 Alice、Bob 和 Carol 三人要将资金汇成同一个 UTXO，这个 UTXO 是一个 3-of-3 的多签名输出，以 “UXTO #1” 标记；承诺交易记为 CT，其作用是让某个用户的资金退出。

UTXO #1 --> CT #A --> UTXO A
		--> UTXO BC --> CT#BC --> UTXO B
					--> UTXO C
		--> CT #B ...
		--> CT #c ...

如上所示，只需在建立 UTXO #1 之前，签名 6 笔承诺交易，我们就能保证它的免信任性。不论 Alice、Bob、Carol 哪一个先取出资金，承诺交易的存在都让他们一定能取出资金。这个特性，也被 [3] 的作者归结为 “非交互式任意顺序取款” —— 不论之前发生了什么事，支付池中的用户都应能够无需他人协助就取出资金。（换言之：在任意状态下任意用户取款所造成的状态转换，都被考虑进去了。）

那么，限制条款可以提供哪些帮助呢？它可以减少签名的数量。在上面这个例子中， CT #A/#B/#C 都需要所有三位参与者的签名；CT #BC 这样的交易需要 Bob 和 Carol 的签名。假如我们有 CTV，我们就可以给 UTXO #1 增加三条 CTV 花费路径：这三条花费路径分别承诺了 CT #A/#B/#C，但是，它们分别只需要得到 Alice、Bob、Carol 的签名，就可以生效。在这里，无论哪一个人，都无法任意花费 UTXO #1；但是，每一个人想要拿走属于自己的资金时，都不再要其他人的签名。因为 CTV 的特性，对每一位参与者来说，它所允许的状态转换都是可以验证的。而使用了 CTV 之后，需要签名的数量就减少了。实际上，它也简化了交互的流程：参与者们只需传输这些承诺交易，而无需实际签名！当参与者数量增加时，这种带宽、交互复杂度和存储空间的节约，是非常明显的。

实际上，这种支付池模型，跟 CTV 提出者 Jeremy Rubin 所提出的 “拥堵控制” 应用 [4] ，是一模一样的：当用户需要从托管式交易所取款时，交易所不需要为 n 个取款用户生成 n 个输出，只需形成 1 个输出，并在这个输出中使用 n 个 CTV 花费条件，将每一位用户的取款额度（或者说取款交易）都承诺进去。在手续费高涨的时期，这可以节约大量手续费；每一个用户都可以在手续费率回落到自己愿意接受的水平时从中取出资金。

在这里，我们似乎是证明了，支付池这个概念，是有可能成立的 —— 多人共有的 UTXO 可以是免信任的。但是，我们尚未证明它是有用的 —— 我们尚未搞清楚，它使用起来是否便利；为了获得这些便利，有哪些条件。

按上述描述，稍加思考就会立即发现一个难题：上述承诺交易（以及 CTV 锁）都预设了一次只有一位用户取款；换言之，用户是排着队退出的；如果同时有多位用户希望退出，那该怎么办？

状态争用（race condition）

上述问题有一个专门的术语：“状态争用”：当多位用户共同享有一个状态，他们就有可能因为都希望更改状态而产生冲突。这种情况在比特币世界里，还算是新鲜事。

一种简单但很可能无用的解决方案是：因为交易池输出本身带有 n-of-n 多签名花费路径，所以，可以由这 n 位用户一同签名一笔交易，让某几位用户同时退出。但是，这种方案意味着，要解决这里的状态争用问题，n 位用户必须同时在线 —— 这是一个完全不现实的条件。

幸运的是，如果我们有 CTV，它又可以派上用场：可以预先为每一种 m 位用户（1 < m < n）同时退出资金池的交易安排一个 CTV 花费条件，并且只需要涉及其中的用户的签名，就可以花费这样的分支。例如，在一个 5 位用户的支付池中，为 Bob 和 Carol 同时退出的交易安排一个 CTV 花费条件，并且只需要提供 Bob 和 Carol 的签名（无需其他人的签名）就可以使用这个花费条件。—— 其实，它只是上一章的 CTV 用法的延伸。

在这里，CTV 算是比较好地解决了这个用户退出时候的状态争用问题。但是，它依然预设了：同时希望退出支付池的用户有办法联络到彼此，否则他们就不能一起签名从而使用这个更经济的分支，只能排队。

又或者，如果有一种技术，能够让花费同一个输入但形成不同输出的交易在交易池中非交互式地聚合，即，当 Bob 发起退出支付池的交易后，观察交易池的 Carol 能够直接使用 Bob 的签名、将 Bob 的交易 “升级” 成 Bob 与 Carol 一起退出的交易，那就无需要求用户知晓彼此的即时通讯方式。

令人惊讶的是，SIGHASH_NONE + CTV 似乎就提供了这样的非交互式交易聚合方法。假设 Bob 以 SIGHASH_NONE 签名自己的 CTV 退出交易分支。NONE 意味着这个签名不承诺输出，也即改动交易的输出不会使这个签名作废；同时，CTV 又锁定了交易的输出；这意味着首先这是一种安全的花费。其次，看到了这条交易的 Carol 可以将 Bob 的签名抽出，跟自己的签名（同样以 NONE 签名）一起、使用 CTV 同时退出交易分支。如此，就既不需要联络 Bob，也可以跟 Bob 一同退出。并且，还允许其他参与者在此基础上进一步聚合。【这种方法是不是真的可行，还需要事实检查】

下面，我们要继续探讨支付池的有用性。

状态更新

显然，如果支付池仅仅是用户资金的中转站，资金放在里面只是等待退出，其有用性是值得怀疑的。那么，支付池必须便利地实现下述功能：

1. 内部支付：不涉及资金进入和退出，仅在支付池内部更新状态。注意，在这里我们仅涵盖 Alice 给 Bob 支付的情形，不包括 Alice 使用池内余额给尚未加入支付池的 Lora 支付的情形。
2. 加入支付池：既包括外部资金进入交易池的情形，也包括池内用户使用自己的池内余额给尚未在池内拥有余额的人支付的情形。
3. 外部支付：资金退出支付池并给某一个不由 CTV 承诺的地址支付。

实际上，所有三者功能的实现，都需要更新支付池的内部状态 —— 用户们在支付池内的余额改变了。然而，对一个支付池来说，当且仅当一组 CTV 交易与这样的状态相匹配，我们才能保留它的免信任性。因此，每当状态更新，我们都需要更新这组 CTV 交易。

但内部支付与加入支付池、外部支付有所区别的地方在于：后面两者一定要得到区块的确认，否则对接收资金的用户来说是不安全的（或者说，是需要信任的）。而前者则不必然。

在这里，我们将撞上 CTV 的局限性：CTV 只能确定性地预先承诺交易，但上述支付功能的支付对象、支付数额都是不确定的，我们不可能用 CTV 来承诺这不可计数的可能性（即使技术上可以做得到，通信开销也会令人望而却步，并让交易池变成完全不实用的东西）。

因此，不论是资金加入支付池还是离开支付池，我们都必须要求支付池的所有用户在线，通过 n-of-n 多签名路径花费支付池输出、形成新的支付池。这是支付池的重大局限 —— 它要求所有用户在线。实际上，[3] 的作者们对此心知肚明，他们说：

CoinPool 设计预设了参与者们要定期沟通并交换交易的模板和签名。每次资金池要更新状态时，参与者们都要这样做：从 CoinPool 创建、CoinPol 更新，协作取款。

如果说资金离开支付池并不绝对需要所有参与者在线 —— 想要退出的用户可以先退出到自己的地址，再支付给他人，这样做需要支付更多手续费，并且需要等待更多的区块确认，但并不是完全不能做到；优化这个过程的一个办法是用户在 CTV 退出交易中使用带有复杂结构的地址，例如 “Swap in potentiam” 构造，进入这样的输出的资金可以立即置换成闪电通道内的资金并发起闪电支付 —— 的话，资金进入支付池就必须让所有人都在线了：如果进入操作得不到区块确认，接收者的资金就不安全；但要发起这样的操作，又必须得到所有人的签名，没有别的办法。

但是，这里还剩下一个拥有设计空间的东西：内部支付（状态更新）。因为三种功能都离不开状态更新，所以，它才是核心。假设我们有一个状态更新协议，就可以在它之上附加跟底层链的互动，从而实现资金进入和离开支付池的功能。

如果我们没有限制条款，我们就只能依赖于承诺交易，并且需要在支付池内实现一个类似于 “LN-Penalty” 的东西。但如果我们有 APO，事情就简单很多了。我们可以为支付池实现一个 Eltoo 协议：

• 支付池本身是一个带有两个多签名分支的输出，其中一个带有相对时间锁，一个带有绝对时间锁。在进入这个输出之前，用户们先用 APO 签名一笔结算交易，花费它的相对时间锁多签名分支、形成一个支付池状态输出，该状态输出使用许多 CTV 分支保证了用户的非交互式任意顺序取款（以及交易池内的非交互式退出交易聚合）。然后用户进入交易池。
• 在需要更新状态时，用户们先用 APO 签名新的一笔结算交易，该结算交易的输出以许多 CTV 分支表达了交易池的新状态；然后，用户们用 APO 签名一笔状态更新交易，该交易花费支付池输出的绝对时间锁分支，并形成一个脚本结构完全相同（带有两个时间锁多签名分支）的新支付池输出。实际上，新的结算交易花费的正是这个新支付池输出。
• 每一笔状态更新交易，跟上一笔结算交易总是竞争关系；而相对时间锁的作用是，保证状态更新交易总是能先被提交到链上。相同的输出结构、APO 以及绝对时间锁，保证了新的状态更新交易总是能花费旧的状态更新交易（不论它们中间曾有过多少笔状态更新交易），而旧的状态更新交易无法花费新的状态更新交易。结算交易的签名使用 APO，是为了保证交易 id 怎么变化，结算签名都不会失效；它跟对应状态更新交易的绑定，是通过公钥的调整实现的。
• 由此，无论发生多少次状态更新，所有参与者都只需保留最新一笔状态更新交易以及最新的结算交易，即可。结算交易将形成一个支付池输出，用户可凭借 CTV 退出交易和签名退出支付池。

当需要处理资金进出支付池的操作时，我们就让状态更新交易携带额外的输入或输出，而结算交易的输出就可以表示新状态。在这里，我们需要使用 “通道拼接 [6]” 这样的技术，来保证资金进入和退出支付池的同时，支付池可以保持内部支付功能而不必中断 —— 就像通道拼接让一条闪电通道无需中断运行就可以注入或抽出资金一样。

在这里，我们得到了一种支付池的状态变更协议，但是，它依然要求所有参与者都在线。能够无需所有参与者在线吗？这个问题实际上是问：是否存在一种无需所有参与者在场，但依然能保证内部支付安全性的协议？

答案是不存在。除非所有人都在线，否则无法杜绝重复花费 —— 当我在池内得到一笔支付时，我怎么知道这笔钱没有支付给其他人呢？只有通过要求每一个人都签名，来确保一笔钱不会支付给两个人。

一种放松在线要求的办法是使用支付池内的资金形成闪电通道。比如，Alice 和 Bob 在一次支付池状态更新中形成一条闪电通道，那么，他们在通道内相互支付时，就无需他人在场。但是，当这个通道要关闭、双方的资金要回到支付池中时，依然需要所有参与者在场。

通道工厂/批量通道

通道工厂/批量通道 [7] 可以认为是上述思想的延伸。假定一个支付池有 10 位用户，但 CTV 交易承诺的是他们之间的一对一通道，而不是个人的单签名输出，那么这就成了一个通道工厂。

在通道工厂中，每两位用户之间都有一条通道，因此，任意两位用户之间都可以直接支付而无需得到其他参与者的确认，这样就最小化了参与者的在线要求。它的不便在于，给定用户的资金数量，这样做会使用户的资金更加分散、降低其支付能力；此外，通道无法摆脱 “入账容量” 和 “出账容量” 的概念，一名用户接收支付的能力将受制于自己的入账容量总量，一旦支付额超过了这个入账容量，支付就要失败。而如果要调整通道的大小，则又必须让所有参与者在场，以完成整个通道工厂的状态更新。

CTV 的提出者 Jeremy Rubin 将批量通道当成 CTV 的一个应用场景。但是，我们已经看到了，如果不使用 APO，通道工厂的状态更新就必须得到区块的确认（或者需要使用承诺交易以及一套类似于 “LN-Penalty” 的东西）。

除此之外，资金 进入/定制化退出 通道工厂的要求，跟上述支付池构造的要求是一样的。

我个人的看法是，如果只有 CTV 能被部署，那么通道工厂将优于支付池；但如果我们可以同时部署 CTV 和 APO，则上述支付池构造将优于通道工厂，因为支付池中的用户也可以选择性地进入通道。

结论

本文中，我们研究了一种免信任的 “多人共享的 UTXO” —— 支付池：它是如何得到实现的；为了执行其功能，它对用户提出了哪些要求。与此同时，我们也探究了当前被讨论最多的两种限制条款（CTV 和 APO）分别可以为支付池的构造提供哪些帮助，以及它们各自的特点。我认为，结论是明确的：

• CTV 可以预先承诺交易并让这些的交易容易使用（显著地优化了非交互特性），因此，它善于为支付池的用户设置活动的 “背景板”，或者说，支付池的底线条款。但是，它不善于协助支付池的状态更新 —— 这样的状态更新有无数种可能，无法预先承诺。
• APO 则相反，它可以极大地简化状态更新和保存的复杂性。为使交易池成为真正有用的东西，APO 这样的技术是必不可少的。

在本文的开头，我们将 “侧链” 也作为 “多人共享的 UTXO” 的例子。这绝不是一种偶然，在我看来，探讨支付池概念的限制条款研究者，就像在使用限制条款开发一种免信任的侧链一样。 而缺乏共识算法来解决重复花费问题的支付池，就只能要求所有用户都在线。这可能会成为支付池的可扩展性的瓶颈。

需要指出的是，支付池概念的提出者 [3] 并非不知道这样的局限性（毕竟，在当时，对限制条款的理解可能更少），他们曾指出：

由于复杂性是准阶乘增长的，保守的 CoinPool 超过 10 个叶子就不实用了。

但他们同时也认为：

这些（在线的）要求类似于闪电网络和金库对用户的要求，所以我们相信 CoinPool 参与者的负担也不会太大，它跟其它二层协议是一样实用的。

我的意见是，经过限制条款优化的支付池应该可以突破上述的 “10”，但究竟能够达到什么样的效果，则需要进一步的基准测试。

在闪电通道中，一位用户只有一个对手方，这意味着如果需要更新状态，他们的交互负担会比较小；同时，跟主链交互（进入和退出）的需要也会少一些。但是，在支付池中，如果我们有 10 个用户，他们跟主链交互的需要可能会成倍增加，而只要一位用户离线，状态更新的流程就会卡住。当然，可以通过承诺 CTV 交易，将离线的用户逐出交易池，但是，这依然是一种糟糕的用户体验。

支付池概念的作者们认为，支付池可以强化用户的隐私性。这当然是对的。但假如用户是从自己的单签名地址加入一个支付池的，则只有在这个支付池发生足够多的内部更新之后，这种隐私性得益才是真实的。

To Be Build

• 笔者尚未考察较新的支付池构造（例如 Ark [8] ），不知道这些新提议为支付池提出了什么样的机制。
• 笔者尚不能完全理解使用限制条款来模拟 drivechain 的构造（比如这个 [9] ）。但是，这样的构造似乎印证了笔者的直觉：限制条款的研究者是在研究一种基于比特币脚本的侧链技术。我们这里的支付池是一种免信任的侧链（但这种侧链的链协议跟主链没有区别），而 drivechain 也是一种特殊的侧链构造（它基于矿工投票）。
• 笔者尚未思考过支付池交易的交易池（mempool）安全性，例如，如何防范交易钉死攻击？使用交易池作为公告牌，是否有对节点造成 DoS 攻击的风险？显然，这里面仍有大量细致的工作要做。

请求评论

请检查我在这里是否有推理上的错误、设计上不完整之处以及事实错误。

---

[1] https://www.btcstudy.org/2022/09/19/covenants-ctv-bitcoin-custody/

[2] https://www.btcstudy.org/2022/01/27/breaking-down-the-bitcoin-lightning-network-eltoo/

[3] https://www.btcstudy.org/2022/06/15/coinpool-exploring-generic-payment-pools-for-fun-and-privacy/

[4] https://utxos.org/uses/scaling/

[5] https://www.btcstudy.org/2023/03/06/swap-in-potentiam-moving-onchain-funds-instantly-to-lightning/

[6] https://bitcoinops.org/en/topics/splicing/

[7] https://utxos.org/uses/batch-channels/

[8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021694.html

[9] https://www.btcstudy.org/2022/10/11/spookchains-drivechain-analog-with-trusted-setup-and-apo/

[editor-Ajian]

修订：

• Fedimint 实际上使用了共识算法。由于 Fedimint 使用了联盟式的铸币厂，每次发放盲签名都需要多位联盟成员参与，所以，它使用 “实用拜占庭容错类型（PSBT）” 类型的算法，以在联盟成员间达成共识。

更新：

• Ark 的作者也将 Ark 定义为一种 “带有管理员的 joinpool” 。这种构造的核心是通过管理员来拆分支付的动作：支付者向管理员支付，并获得管理员的承诺；管理员再向接收方支付。其缺点在于管理员需要投入大量预付资金。技术解析
• 最近，让 CoinPool 获得重大进展的提议当属 OP_CHECKSIGSEPARATE 提议；它改变了签名验证算法的参数构成，使得可以在脚本中承诺将要使用的签名 nonce 值。由此，CoinPool 的输出可以是类似于 Swap-in-Potential 的、带有中介的时间锁脚本。当其他人不在线时，Alice 可以直接用自己的 CoinPool 输出给 Bob 支付；由于中介提前承诺了 nonce 值，就可以通过向 Bob 暴露自己使用相同 nonce 值的其它输出，作为自己不会跟 Alice 串通以重复花费的承诺。由此，CoinPool 允许在部分成员不在线时继续支付。这种做法的缺点是，中介也需要别的输出来形成基于惩罚的承诺，从而削弱了可扩展性。

最后：

• 现在我倾向于不将 CoinPool 视为一种 “免信任的侧链”，原因有二：其一，CoinPool 上可以运行的操作跟比特币主链没有区别；而侧链一般有自己独立的一套链协议；其二，CoinPool 的内部状态并不依赖于 “区块链” 这种数据结构。