#204 主动支付->要约

Author: winkybupt

_posts/zh/newsletters/2022-06-15-newsletter.md

@@ -38,17 +38,17 @@ lang: zh
 
   - *<!--minisketchbased-efficient-gossip-->高效消息协议*：如[周报 #198][news198 minisketch] 所述，开发者正在研究使用 [minisketch][topic minisketch] 来降低节点间同步 LN gossip 的带宽，我们还可凭此进一步降低更新通道的最小时间的间隔。
 
-  - *<!--onion-message-dos-->洋葱消息拒绝服务式攻击*：多个闪电网络实现已经支持[洋葱消息协议][topic onion messages]，既作为使用 [keysend][topic spontaneous payments] 支付功能来通讯的替代方法，也作为还在提议阶段的 [BOLT12 主动支付协议][topic offers]的通信层。但是，如[周报#190][news190 onion] 所述，一些开发者依然担心洋葱消息无法抵御许多不同类型的拒绝服务式攻击。讨论了多种防止拒绝服务式攻击的方法。
+  - *<!--onion-message-dos-->洋葱消息拒绝服务式攻击*：多个闪电网络实现已经支持[洋葱消息协议][topic onion messages]，既作为使用 [keysend][topic spontaneous payments] 支付功能来通讯的替代方法，也作为还在提议阶段的 [BOLT12 要约协议][topic offers]的通信层。但是，如[周报#190][news190 onion] 所述，一些开发者依然担心洋葱消息无法抵御许多不同类型的拒绝服务式攻击。讨论了多种防止拒绝服务式攻击的方法。
 
-  - *<!--blinded-paths-->路径盲化*：一种提议了许多年（见[周报#185][news85 blinded]）并且现在已经用于洋葱消息的协议也在开展实验，用在常规支付中以允许用户在接收支付时无需公开自己的闪电网络节点的身份。这种方法面临的挑战之一是它要沟通更多的路由信息，所以要使用更大数据量的发票。这可能会让路径盲化的高效实现依赖于更新颖的发票管理协议，比如 BOLT12 主动支付协议或者 [LNURL][]。还讨论了许多别的难点。
+  - *<!--blinded-paths-->路径盲化*：一种提议了许多年（见[周报#185][news85 blinded]）并且现在已经用于洋葱消息的协议也在开展实验，用在常规支付中以允许用户在接收支付时无需公开自己的闪电网络节点的身份。这种方法面临的挑战之一是它要沟通更多的路由信息，所以要使用更大数据量的发票。这可能会让路径盲化的高效实现依赖于更新颖的发票管理协议，比如 BOLT12 要约协议或者 [LNURL][]。还讨论了许多别的难点。
 
   - *<!--probing-and-balance-sharing-->余额打探及共享*：当前，使用多种技术，你可以 *打探* 出网络中某个通道的余额分布。这样的侦测对执行侦测的节点来说是没有成本的，却会对网络的普通用户造成困扰，还会降低隐私性。对专门的 “[通道干扰攻击][topic channel jamming attacks]” 的缓解措施也能帮助限制侦测，但当前人们还有疑虑，所以参与者们讨论了一些节点设定上的简单变更，让侦测变得更困难。
 
     此外，一个之前大家讨论过的思想实验是，把执行侦测的节点可能获取的信息提取出来并主动、免费地分享。要是每一个节点都这样做，带宽要求和隐私降级都会削弱闪电网络的关键优势 —— 但这会让支付路由高效得多。没有人支持这种想法，但之前的一个研究课题讨论了每个节点都只向自己的直接通道对手分享一些可被侦测的信息的想法。有人主张这会极大地提高支付路由的成功率，比如可以增加 “[柔性的通道再平衡（Just-in-time channel rebalancing）][topic jit routing]” 机制。
 
   - *<!--trampoline-routing-and-mobile-payments-->蹦床路由与移动支付*：[蹦床路由][topic trampoline payments]允许一个花费者将寻路的任务外包给网络中的另一个节点，还可以选择性维持闪电网络通常的隐私性，即防止任何中间节点知道花费者和接收者的身份。这种外包对移动端的闪电网络客户端尤其有用，因为它们本身不打算为其他节点路由支付。会议总结中提到，蹦床支付可以跟 *一跳保管支付（first hop payment holds）*（见[周报 #171][news171 ln offline]）相结合，后者的意思是支付由花费者的直接通道对手保管，直到接收节点下一次上线，他能允许一个经常离线的手机节点可靠地接收来自其他经常离线的手机节点的支付。
 
-  - *<!--lnurl-plus-bolt12-->闪电网络统一资源位置符加闪电网络技术基础十二*：闪电网络统一资源位置符（LNURL）协议允许一个节点向一个互联网服务器（webserver）请求一个 [BOLT11][] 发票；而 BOLT12 [主动支付][topic offers] 协议允许一个节点向网络中的另一个节点请求发票。围绕这些协议的其它侧面，参与者们讨论了这两个协议如何相互兼容，使得节点可以使用其中一个或同时使用两个。
+  - *<!--lnurl-plus-bolt12-->闪电网络统一资源位置符加闪电网络技术基础十二*：闪电网络统一资源位置符（LNURL）协议允许一个节点向一个互联网服务器（webserver）请求一个 [BOLT11][] 发票；而 BOLT12 [要约][topic offers] 协议允许一个节点向网络中的另一个节点请求发票。围绕这些协议的其它侧面，参与者们讨论了这两个协议如何相互兼容，使得节点可以使用其中一个或同时使用两个。
 
 - **<!--using-routing-fees-to-signal-liquidity-->使用路由费来说明流动性**：开发者 ZmnSCPxj 在 Lightning-Dev 邮件组中[发帖][zmnscpxj hilolohi]，论证了最便宜和可靠的支付如何可以通过花费者和路由节点之间的博弈理论行为来实现：