闪电网络隐私：从零到英雄
- t-bast
- 发布于 2023-10-24 14:48
- 阅读 14
本文深入探讨了闪电网络中的隐私问题，从链上到链下、链下到链下的角度分析了各种隐私泄露的风险，并提出了利用 Taproot、PTLCs、Offers、Route Blinding 和 Trampoline routing 等技术来提升闪电网络隐私性的解决方案。文章还讨论了多路径支付和节点连接方式等因素对隐私的影响。
闪电网络隐私：从零到英雄
本文包含闪电网络中许多隐私方面的陷阱，以及你如何避免这些陷阱，以及我们计划 如何在未来解决这些问题。
目录
链上到链下的隐私
每当你使用闪电网络时，都会留下链上足迹：你将打开和关闭 通道。重要的是要确保此链上足迹不会泄露过多信息。
识别闪电网络通道 Funding 脚本
正如我们在闪电网络交易文章中所看到的，通道 Funding 交易使用 p2wsh 2-of-2 多重签名。 当通道打开时，这没问题：攻击者查看区块链只会看到一个 p2wsh 输出，其中可能包含任何内容。 但是，当通道关闭时，我们必须揭示它正在使用 2-of-2 多重签名，这 强烈表明这可能是一个闪电网络通道。
幸运的是，使用 Taproot 可以很容易地解决这个问题。我们将使用 Musig2和密钥路径花费，而不是使用 p2wsh 输出，这将与正常的单 签名输出无法区分。
但是，闪电网络通道可以通过两种方式关闭：要么是合作关闭，其中 双方参与者创建一个交易，将各自的最终余额发送给对方，要么是 在其中一方参与者不合作的情况下单方面关闭。
在第二种情况下，广播的交易是我们在闪电网络交易文章中描述的 commitment 交易。这笔交易依赖于 闪电网络特有的专用脚本，以允许参与者找回他们的资金。 这些脚本将在链上可见，并清楚地表明这是一个闪电网络通道。 不幸的是，在保证资金安全的同时，可能没有办法解决这个问题。 节点运营商应尽可能避免单方面关闭：这只应在以下情况下发生 恶意节点或节点已消失。
公共通道
闪电网络节点目前通过向其对等节点发送 channel_announcement 消息来在闪电网络中公布其通道，这些对等节点会将此公告中继到网络的其余部分。此消息包含 Funding 交易的详细信息，这使任何运行闪电网络节点的人都可以知道哪些 utxo 实际上是闪电网络通道。
通道在网络内部公开公布的原因是，我们正在使用源 路由来确保支付隐私：当 Alice 想要向 Bob 发送支付时，Alice 必须找到 通过现有通道到达 Bob 的路由。如果 Alice 可以访问完整的 图拓扑，她可以自己找到路由，而不会向任何人透露她打算发送 向 Bob 付款。
+------+ +-----+
| Node | | Bob |
+------+ +-----+
| |
| |
+-------+ +------+ +------+
| Alice |---------| Node |---------| Node |
+-------+ +------+ +------+
| |
| +------+ |
+-------------| Node |-------------+
+------+如果我们想保留支付匿名性，我们不能完全摆脱这种机制，但我们 可以做得更好。我们只需要让 网络知道存在一个至少达到给定金额的链上交易，该交易在两个节点之间创建了 一个通道，而不是透露通道的所有详细信息。我们如何做到的细节尚未完全确定， 但应该可以通过一些加密魔法（例如，环签名或 zkps）来实现。
未公布的通道
幸运的是，不想路由付款的节点（例如移动钱包和商家）可以选择不向网络 公布其通道。
+------+ +------+
| Node |---------| Node |
+------+ +------+
| |
| |
+-------+ +------+ +------+ +------+ +-----+
| Alice |ooooooooo| Node |---------| Node |---------| Node |ooooooooo| Bob |
+-------+ +------+ +------+ +------+ +-----+
o |
o +------+ |
oooooooooooooo| Node |-------------+
+------+
NB: unannounced channels are represented with "ooooo"
注意：未公布的通道用 "ooooo" 表示但是，每当节点想要接收付款时，发送者需要知道如何在 图中找到它们，因此他们必须公开有关其未公布通道的一些信息。 目前这是使用 Bolt 11 发票完成的，其中包含了一些未公布 通道的所有详细信息。这很糟糕，因为发票有时会公开共享（例如，在 Twitter 上）， 这会将这些未公布的通道透露给所有人。
我们有两个即将推出的功能将解决此问题：
请注意，路由节点也可以部分利用未公布的通道来保留一些 utxo
隐私。每当两个节点之间打开了多个通道时，它们可以选择仅
向网络公布其中一个通道，而保持其他通道私有。当他们收到要
中继的付款时，他们可以使用未公布的通道，没有人知道他们没有使用公共通道。
请参见以下示例，其中未公布的通道用 oooo 表示：
0.4 btc 1.2 btc
oooooooooooooooooooo oooooooooooooooooooooo
o o o o
+------+ 1 btc +------+ 1.5 btc +------+ 0.8 btc +------+
| Node |-----------| Node |-------------| Node |-------------| Node |
+------+ +------+ +------+ +------+
o 0.6 btc o
oooooooooooooooooooo但也有一个小小的缺点：路径查找启发法使用节点之间的容量来 对要使用的通道进行排名。由于路由节点将隐藏其部分容量，因此它们可能在 路径查找分数中排名略低。
链下到链下的隐私
一旦你打开了通道，闪电网络应该为你的付款提供更大的匿名性，因为它们 没有任何链上足迹。我们将在以下 部分中探讨一些微妙之处和陷阱。
支付关联性
闪电网络支付使用一种名为 Sphinx 的 onion 路由方案，该方案保证 中间节点只知道路由中的上一个和下一个节点，但不能知道 在这些节点之前或之后是否还有其他节点。
例如，如果 Alice 使用以下支付路由向 Dave 付款：
+-------+ +-----+ +-------+ +------+
| Alice |---------->| Bob |---------->| Carol |---------->| Dave |
+-------+ +-----+ +-------+ +------+当 Bob 收到将付款转发给 Carol 的请求时，Bob 只会了解到：
- 付款可能来自 Alice 或 Alice 之前的另一个未知节点
- 付款发送给 Carol 或 Carol 之后的另一个未知节点
同样，Carol 只会了解到以下事实：
- 付款可能来自 Bob 或 Bob 之前的另一个未知节点
- 付款发送给 Dave 或 Dave 之后的另一个未知节点
这种机制为支付提供了极大的隐私。但是，不幸的是，我们泄露了一些
数据：由于 HTLC 的工作方式，路由中的所有节点都获得了相同的支付标识符，payment_hash。
如果路由中的两个节点由同一实体控制，他们可以看到
这是同一笔付款。
+---------------------------+
| Well well well... |
| I know that payment hash! |
+---------------------------+
|
|
+-------+ +-----+ +-------+ +------+ +------+
| Alice |---------->| Bob |---------->| Carol |---------->| Bob2 |---------->| Dave |
+-------+ | +-----+ | +-------+ | +------+ | +------+
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
| payment_hash | | payment_hash | | payment_hash | | payment_hash |
| 0x123456 | | 0x123456 | | 0x123456 | | 0x123456 |
+--------------+ +--------------+ +--------------+ +--------------+我们将在下一节中看到，这种类型的支付关联性如何损害 移动钱包支付的隐私。
好消息是，Taproot 使我们能够从 HTLC 切换到 PTLC，并且这种 更改的好处之一是它完全修复了这种支付关联性攻击：使用 PTLC，路由中的每个 节点都会看到一个不同的、随机的支付标识符。
+-------------------------+
| Never seen that payment |
| point before... |
+-------------------------+
|
|
+-------+ +-----+ +-------+ +------+ +------+
| Alice |---------->| Bob |---------->| Carol |---------->| Bob2 |---------->| Dave |
+-------+ | +-----+ | +-------+ | +------+ | +------+
| | | |
+---------------+ +---------------+ +---------------+ +---------------+
| payment_point | | payment_point | | payment_point | | payment_point |
| 0x02123456 | | 0x03ff0123 | | 0x03abcdef | | 0x026bcad3 |
+---------------+ +---------------+ +---------------+ +---------------+识别移动钱包
大多数用户将通过移动钱包进行闪电网络支付。 移动钱包从根本上不同于服务器节点：移动钱包 不可能对其直接对等节点隐藏它是移动钱包的事实。 它们没有稳定的 IP 地址，它们大部分时间都处于离线状态，并且它们不中继 支付，这很容易检测到。
其中一个后果是，当移动钱包要求其对等节点之一转发 付款时，该对等节点会了解到该移动钱包是发送者。同样，当节点转发 付款到移动钱包时，它会了解到该移动钱包是接收者。
结合上一节中描述的支付关联性问题，它可以让攻击者 发现谁在向谁付款：
+-----------------------+
| Well well well... |
| Alice is paying Dave! |
+-----------------------+
|
mobile | mobile
+-------+ +-----+ +-------+ +------+ +------+
| Alice |---------->| Bob |---------->| Carol |---------->| Bob2 |---------->| Dave |
+-------+ | +-----+ | +-------+ | +------+ | +------+
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
| payment_hash | | payment_hash | | payment_hash | | payment_hash |
| 0x123456 | | 0x123456 | | 0x123456 | | 0x123456 |
+--------------+ +--------------+ +--------------+ +--------------+一旦闪电网络转移到 PTLC，中间节点将只能知道付款人 或接收者是谁，但不能同时知道两者。正如我们所看到的，移动钱包无论如何都不能期望隐藏此 信息。但是，这并不太糟糕，因为：
- 移动钱包可以使用 Tor 或 VPN 来隐藏其真实 IP 地址：它们在
闪电网络上的唯一身份是它们的
node_id，它们可以定期更改（以打开 新通道为代价） - 对等节点只能了解到移动钱包正在进行付款或接收付款，但不知道 向谁或从谁付款
- 移动钱包可以向自己付款以创建合成流量，并阻止链下 分析启发法
- 移动钱包可以有多个对等节点，以便它们的每个对等节点仅看到它们 付款的一个子集
请注意，本节仅适用于连接到由其他人运行的节点的移动钱包。 如果你自己运行一个闪电网络节点，并且你的移动钱包仅连接到该节点， 则这些问题不适用：网络甚至不会看到你的移动钱包存在，因为 一切都将通过你的闪电网络节点。
路径查找技巧
通过利用路径查找的微妙之处，可能会进行更高级的攻击以破坏支付隐私。 让我们探讨其中的两个：
- 多部分付款路径交集
- 图过滤
让我们首先探讨多部分付款路径交集。 多部分付款提高了针对中间节点的支付隐私（因为它们只看到 总付款金额的一部分），但向接收节点提供了更多数据（因为它看到 通过不同通道到达的多个部分）。让我们考虑以下多部分 付款：
+-------+ +------+ +------+
| Alice |----------| Node |----------| Node |------------------+
+-------+ +------+ +------+ |
| | MPP part #1
+------------------+ |
| |
+-----+ +------+ +------+ MPP part #2 +------+
| Bob |------------| Node |----------| Node |---------------| Dave |
+-----+ +------+ +------+ +------+
| |
| |
| | MPP part #3
+-------+ +------+ +------+ |
| Carol |----------| Node |----------| Node |------------------+
+-------+ +------+ +------+Dave 可以回溯所有可能的路径以找到它们的交集。对图的简单分析 可以清楚地表明最可能的发送者是 Bob。通过这种分析，不能保证 发送者的匿名性。
但请注意，这是一个玩具理论示例，在公共图上利用它进行实际 付款可能不可行，但我认为值得一提。
图过滤攻击甚至更复杂，需要更多资源，但总体思路 值得探讨。
让我们考虑一个连接到单个节点 (Eve) 的最终用户 (Alice)：
+-------+ +-----+
| Alice |----------| Eve |
+-------+ +-----+Alice 认为她的付款是私密的，因为她自己计算路由。但是，由于她的 唯一对等节点是 Eve，Alice 只能通过 Eve 获取有关公共图的更新。Eve 可以利用此事实来 过滤掉某些通道，并为 Alice 提供一个修剪后的图版本，该版本强制 Alice 通过 Eve 控制的节点才能到达网络的大部分区域。
+------+ +------+ +------+
+-------------| Node |----------| Node |----------| Eve2 |-------------+
| +------+ +------+ +------+ |
| | |
| +-----------------+ |
| | |
+-------+ +-----+ +------+ +------+ +------+ +------+
| Alice |----------| Eve |----------| Node |xxxxxxxxxx| Node |----------| Node |----------| Dave |
+-------+ +-----+ +------+ +------+ +------+ +------+
| | |
| | |
| | |
| +------+ +------+ +------+ |
+-------------| Node |xxxxxxxxxx| Node |----------| Node |-------------+
+------+ +------+ +------+在上面的示例图中，Eve 过滤掉了标有 xxxxx 的通道。如果 Alice 想要支付
Dave，她将找到的唯一路由将通过 Eve 的第二个节点，这允许 Eve
取消支付的匿名性。
同样，重要的是要强调这种攻击仅在非常特定的情况下有效， 并且可能仅具有理论意义。
Trampoline
Trampoline 路由 是一种机制，允许移动 钱包部分地将支付路由的计算推迟到中间节点。重要的是要 强调钱包不会将完整的路由计算推迟到中间节点，仅 是其中的一部分，这就是它能够保留支付隐私的原因。
让我们考虑以下图：
Alice's local neighborhood Dave's local neighorhood
Alice 的本地邻域 Dave 的本地邻域
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| +------+ | +------+ +------+ +------+ | +------+ |
| +--------------| Node |-----------------------------| N2 |----------| N3 |----------| N4 |-------------+ +------------| Node | |
| | +------+ | +------+ +------+ +------+ | | | +------+ |
| | | | | | | | | |
| | +------------------+ | | | | | | |
| | | | | | | | | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | Alice |----------| Bob |-----------| Terry |----------| N1 |----------| Node |----------| Node |----------| Ted |----------| Carol |----------| Dave | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | | | | |
| | +------------------+ | | |
| | | | | |
| | +------+ | | |
| +--------------| Node | | | |
| +------+ | | |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+Alice 和 Dave 不需要同步整个图，只需同步他们的本地邻域，这为他们节省了 大量带宽，并确保每当他们运行路径查找算法时，它都在一个非常小的 图上，因此速度非常快。
让我们逐步了解一个典型的 trampoline 支付。
第一步是接收者 (Dave) 创建一个发票，其中将包括一些 trampoline 节点，这些节点位于他的邻域中，并且能够将付款路由到 Dave。Dave 找到 这些 trampoline 节点的方法是在他的本地邻域中进行简单的图搜索。 为了保持示例的简单性，Dave 在他的发票中包含了一个 trampoline 节点 (Ted)。
Alice 扫描 Dave 的发票，该发票表明她必须到达 Ted。Alice 选择一个 她自己的邻域中的 trampoline 节点 (Terry)。然后，Alice 构建一个 trampoline 路由：
Alice -----> Terry -----> Ted -----> DaveAlice 使用与正常支付完全相同的构造，但尺寸较小，将此 trampoline 路由加密到一个支付 onion 中。
然后，Alice 在她的本地邻域中找到一条通往 Terry 的路由：
Alice -----> Bob -----> TerryAlice 为该路由创建一个正常的支付 onion，并将 trampoline onion 包含在 Terry 的 payload 中。从高层次上看，该 onion 看起来像这样：
+---------------------------------+
| encrypted payload for Bob |
| Bob 的加密 payload |
+---------------------------------+
| encrypted payload for Terry |
| Terry 的加密 payload |
| +-----------------------------+ |
| | encrypted payload for Terry | |
| | Terry 的加密 payload | |
| +-----------------------------+ |
| | encrypted payload for Ted | |
| | Ted 的加密 payload | |
| +-----------------------------+ |
| | encrypted payload for Dave | |
| | Dave 的加密 payload | |
| +-----------------------------+ |
| | padding | |
| | 填充 | |
| +-----------------------------+ |
+---------------------------------+
| padding |
| 填充 |
+---------------------------------+Alice 将付款发送出去：
Alice's local neighborhood Dave's local neighorhood
Alice 的本地邻域 Dave 的本地邻域
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| +------+ | +------+ +------+ +------+ | +------+ |
| +--------------| Node |-----------------------------| N2 |----------| N3 |----------| N4 |-------------+ +------------| Node | |
| | +------+ | +------+ +------+ +------+ | | | +------+ |
| | | | | | | | | |
| | +------------------+ | | | | | | |
| | | | | | | | | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | Alice |>>>>>>>>>>| Bob |>>>>>>>>>>>| Terry |----------| N1 |----------| Node |----------| Node |----------| Ted |----------| Carol |----------| Dave | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | | | | |
| | +------------------+ | | |
| | | | | |
| | +------+ | | |
| +--------------| Node | | | |
| +------+ | | |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+对于 Bob 来说，这看起来像是一笔正常的付款。他只会了解到：
- 付款可能来自 Alice 或 Alice 之前的另一个未知节点
- 付款发送给 Terry 或 Terry 之后的另一个未知节点
- Bob 不知道 trampoline 正在被使用
当 Terry 收到付款时，他发现他必须找到一条通往 Ted 的路由，并将 付款转发给他。他只会了解到：
- 付款可能来自 Bob 或 Bob 之前的另一个未知节点
- 付款发送给 Ted 或 Ted 之后的另一个未知节点
Terry 找到一条通往 Ted 的路由，并为该路由创建一个正常的 onion，并将 trampoline onion 包含在 Ted 的 payload 中（并解开该 onion 的最顶层）。 从高层次上看，该 onion 看起来像这样：
+--------------------------------+
| encrypted payload for N1 |
| N1 的加密 payload |
+--------------------------------+
| encrypted payload for N2 |
| N2 的加密 payload |
+--------------------------------+
| encrypted payload for N3 |
| N3 的加密 payload |
+--------------------------------+
| encrypted payload for N4 |
| N4 的加密 payload |
+--------------------------------+
| encrypted payload for Ted |
| Ted 的加密 payload |
| +----------------------------+ |
| | encrypted payload for Ted | |
| | Ted 的加密 payload | |
| +----------------------------+ |
| | encrypted payload for Dave | |
| | Dave 的加密 payload | |
| +----------------------------+ |
| | padding | |
| | 填充 | |
| +----------------------------+ |
+--------------------------------+
| padding |
| 填充 |
+--------------------------------+Terry 将付款发送出去：
Alice's local neighborhood Dave's local neighorhood
Alice 的本地邻域 Dave 的本地邻域
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| +------+ | +------+ +------+ +------+ | +------+ |
| +--------------| Node |-----------------------------| N2 |>>>>>>>>>>| N3 |>>>>>>>>>>| N4 |>>>>>>>>>>>>>> +------------| Node | |
| | +------+ | +------+ +------+ +------+ | v | +------+ |
| | | | ^ | | v | |
| | +------------------+ | ^ | | v | |
| | | | ^ | | v | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | Alice |>>>>>>>>>>| Bob |>>>>>>>>>>>| Terry |>>>>>>>>>>| N1 |----------| Node |----------| Node |----------| Ted |----------| Carol |----------| Dave | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | | | | |
| | +------------------+ | | |
| | | | | |
| | +------+ | | |
| +--------------| Node | | | |
| +------+ | | |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+N1、N2、N3 和 N4 是中间节点，对于它们来说，这看起来像是一笔正常的付款。它们只会了解到：
- 付款可能来自上一个节点或上一个节点之前的另一个未知节点
- 付款发送到下一个节点或下一个节点之后的另一个未知节点
- 它们不知道 trampoline 正在被使用
当 Ted 收到付款时，他发现他必须找到一条通往 Dave 的路由，并将 付款转发给他。他只会了解到：
- 付款可能来自 N4 或 N4 之前的另一个未知节点
- 付款发送给 Dave 或 Dave 之后的另一个未知节点
- 但如果 Dave 是移动钱包，Ted 会了解到 Dave 是最终的接收者
- 但是 Dave 可以在他和 Ted 之间使用路由盲化，以向 Ted 隐藏其身份！
Ted 找到一条通往 Dave 的路由，并为该路由创建一个正常的 onion，并将 trampoline onion 包含在 Dave 的 payload 中（并解开该 onion 的最顶层）。 从高层次上看，该 onion 看起来像这样：
+--------------------------------+
| encrypted payload for Carol |
| Carol 的加密 payload |
+--------------------------------+
| encrypted payload for Dave |
| Dave 的加密 payload |
| +----------------------------+ |
| | encrypted payload for Dave | |
| | Dave 的加密 payload | |
| +----------------------------+ |
| | padding | |
| | 填充 | |
| +----------------------------+ |
+--------------------------------+
| padding |
| 填充 |
+--------------------------------+Ted 将付款发送出去：
Alice's local neighborhood Dave's local neighorhood
Alice 的本地邻域 Dave 的本地邻域
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| +------+ | +------+ +------+ +------+ | +------+ |
| +--------------| Node |-----------------------------| N2 |>>>>>>>>>>| N3 |>>>>>>>>>>| N4 |>>>>>>>>>>>>>> +------------| Node | |
| | +------+ | +------+ +------+ +------+ | v | +------+ |
| | | | ^ | | v | |
| | +------------------+ | ^ | | v | |
| | | | ^ | | v | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | Alice |>>>>>>>>>>| Bob |>>>>>>>>>>>| Terry |>>>>>>>>>>| N1 |----------| Node |----------| Node |----------| Ted |>>>>>>>>>>| Carol |>>>>>>>>>>| Dave | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | | | | |
| | +------------------+ | | |
| | | | | |
| | +------+ | | |
| +--------------| Node | | | |
| +------+ | | |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+对于 Carol 来说，这看起来像是一笔正常的付款。她只会了解到：
- 付款可能来自 Ted 或 Ted 之前的另一个未知节点
- 付款发送给 Dave 或 Dave 之后的另一个未知节点
- 但如果 Dave 是移动钱包，Carol 会了解到 Dave 是最终的接收者（但在 非 trampoline 支付中也是如此）
- Carol 不知道 trampoline 正在被使用
由于 Alice 和 Dave 对图的大部分区域一无所知，因此有很大的机会 所使用的完整路由将不是最优的。例如，网络实际上可能看起来像这样：
Alice's local neighborhood Dave's local neighorhood
Alice 的本地邻域 Dave 的本地邻域
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| +------+ | +------+ +------+ +------+ | +------+ |
| +--------------| Node |-----------------------------| N2 |----------| N3 |----------| N4 |-------------+ +------------| Node | |
| | +------+ | +------+ +------+ +------+ | | | +------+ |
| | | | | | | | | |
| | +------------------+ | | | | | | |
| | | | | | | | | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | Alice |----------| Bob |-----------| Terry |----------| N1 |----------| Node |----------| Node |----------| Ted |----------| Carol |----------| Dave | |
| +-------+ +-----+ +-------+ | +------+ +------+ +------+ | +------+ +-------+ +------+ |
| | | | | | |
| | +------------------+ | | | |
| | | | | | |
| | +------+ | | | |
| +--------------| Node |----------------------|-------------------------------------------------------|--------------------------+ |
| +------+ | | |
| | | |
+--------------------------------------------------+ +--------------------------------------------------+其中存在一个非常有效的路由，但 Alice 和 Dave 对此一无所知。 实际上，这对于隐私来说是一件好事，因为它为路由添加了不可预测的随机性， 攻击者的启发式方法无法对其进行逆向工程。
在此示例中，我们仅使用了两个中间 trampoline 节点，因为这是使用 trampoline 的最有效方式，但是具有隐私意识的用户也可以在路由 中间随机添加另一个 trampoline 节点，这可确保最终路由与最优 路由截然不同。
最重要的是，trampoline 与多部分付款结合得很好，并使它们更可靠 和私密。每个 trampoline 节点都可以聚合收到的多部分付款，然后 以不同的方式拆分发出的付款：
150k sat +------+ 250k sat 300k sat +------+ 200k sat
+-------------| Node |-------------+ +-------------| Node |--------------+
| +------+ | | +------+ |
| | | |
| | | |
| | | |
+-------+ 250k sat +------+ 400k sat +-------+ 500k sat +------+
| Alice |---------------------------| Bob |-----------------------------| Carol |-------------------------| Dave |
+-------+ +------+ +-------+ +------+
| |
| |
| |
| +------+ |
+-------------| Node |-------------+
150k sat +------+ 300k sat由于每个 trampoline 节点都了解远程节点不了解的其本地余额，因此 它们能够更有效地决定如何拆分发出的付款。
此外，这也解决了前面我们讨论过的多部分付款路径交集问题。 路由中的每个 trampoline 节点（包括最终接收者）都能够进行一些路径 交集分析，但它们唯一会了解到的是之前的 trampoline 节点可能是谁，这不会透露实际的付款人是谁。
资源
- 原文链接： github.com/t-bast/lightn...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
复制链接
Twitter分享
微信扫码分享
- 比特币中的Tor支持 90 浏览
- Nostr Wallet Connect 协议简介 68 浏览
- 闪电网络的重要指标 127 浏览
- 在移动端开发自主保管闪电钱包的难点 44 浏览
- 2025/06 ZK技术进展 by ZK Mesh 1065 浏览
- 即使进行了零知识证明（ZK）包装，数字身份也存在风险吗？ 702 浏览
- BitVM：在比特币中实现高效可验证计算 205 浏览
- 使用 10101 进行非托管交易 34 浏览
- Payjoin 探测攻击：事实、缓解措施与 Payjoin 的胜利 29 浏览
- 闪电支付是比特币经济体的通用语言 36 浏览
- Ark 协议中的关键概念 29 浏览
- 在 Aptos 上使用保密交易进行构建 318 浏览
