术语表 /闪电网络与 Layer 2
支付密钥
- 支付密钥是什么？
- 支付密钥是收款方为每张发票生成的32字节值，要求在最终洋葱载荷中返还，因此仅知道支付哈希并不能使您成为付款方。
闪电网络的支付密钥相当于每张发票一个的密码，付款方须先将其回传，接收节点才会接受款项。BOLT 11为其指定标签字母 s，将其长度固定为52个 bech32 字符，并要求读取方使任何不带该字段的发票失败。对您而言，这就是为什么一个看到您支付哈希的路由节点无法判断该笔付款终止于您的钱包。
运作方式
支付密钥由收款钱包生成，绝不由付款方生成，在付款到达最后一跳之前，它一直密封在洋葱包内。
BOLT 11将其定义为类型16的标签字段，用字母 s 书写，data_length 固定为52。这52个 bech32 字符承载260位，即一个32字节的值加填充，发票编写方必须恰好包含一个。如果定长字段的长度有误，读取方必须使该付款失败，如果不存在有效的 s 字段，同样须使其失败。
付款方将该值复制到最后一个节点的洋葱载荷中，BOLT 4称之为类型8的 TLV 记录 payment_data，其中包含32字节的密钥和一个 total_msat 数值。只有目的节点能够剥开这一层，因此中间各跳永远看不到它，这与它们都将各自的 HTLC 锁定到的支付哈希不同。
终点处的检查刻意不提供信息。如果密钥与该支付哈希所预期的密钥不符，或者密钥是必需的却缺失，HTLC 将以 incorrect_or_unknown_payment_details 失败，错误码为 PERM|15，与未知支付哈希得到的回复相同。BOLT 4解释了这一合并：旧的一对错误，即 PERM|16 incorrect_payment_amount 和17 final_expiry_too_soon，会让转发节点以低得多的金额重新发送具有相同哈希的付款，并通过读取回复来确认它已找到目的节点。
对该功能的支持已不再需要协商。BOLT 9将功能位14和15（payment_secret）列为 ASSUMED，而位16和17（basic_mpp）依赖于它。
在哪里会遇到它
在现代 lnbc 字符串中，您可以将以 sp5 开头并持续52个 bech32 字符的那一段识别为支付密钥。
在 BOLT 11的测试向量中，这一段是 zyg3 重复十二次后再接 zygs，编码的是一个32个字节全部为0x11 的密钥。您从不需要自己输入支付密钥：只有发票编写方和付款钱包会经手该值。
该字段真正发挥作用之处是多路径支付。当没有任何单一路由具备足够的流动性，而发票提供 basic_mpp 时，BOLT 4允许钱包将金额拆分到共用同一支付哈希的多个 HTLC 上，每一部分都必须携带该密钥，并且应在 total_msat 上保持一致。收款方在总额到齐之前不会结算任何款项，并且应在第一个 HTLC 之后至少等待60秒，再以 mpp_timeout 使该组失败。因此，从 Strike 这类以闪电网络为主的应用发起的较大额闪电网络提币，如果挂起一分钟后退回，可能是不完整的 HTLC 组到期，而不是资金丢失。无论是由您自己的钱包来汇集这些部分（如 Phoenix 在手机上运行真正的闪电网络节点那样），还是由托管方在您无法掌控的服务器上完成，该密钥都会将它们标记为同一笔付款。
支付密钥 vs 支付哈希
支付哈希和支付密钥都是一张 BOLT 11发票中的256位字段，区别在于谁能看到它们。每一跳都会获知哈希，因为各自转发的 HTLC 都锁定到它，而除最终节点外无人获知密钥，它位于最内层的洋葱层。哈希回答付款是否已结算，打开它的原像就是收据。密钥回答付款方是否依据您所开具的发票操作，这是哈希做不到的，因为路由上的所有人都能看到哈希。在编码上，它们看起来像一对孪生：标签 p 和标签 s，都是52个字符，长度不符时都会被拒绝。