术语表 /闪电网络与 Layer 2
Keysend
- Keysend 是什么？
- Keysend 无需发票即可发送闪电网络支付：付款方生成32字节的原像，将其哈希为支付哈希，并把该原像放进洋葱数据包中一并发出。
Keysend 颠倒了闪电网络的常规流程：常规流程中由收款方选定秘密值，并在发票中公布其哈希。发送方的秘密值放在自定义 TLV 记录5482373484中，这是一个偶数，BOLT 1规定，不认识 keysend 的节点必须拒绝它，而不是忽略它。您可以只凭节点公钥直接付款，无需往返交互，但同时放弃了发票本可留下的密码学收据。
运作方式
Keysend 依据的是 BOLT 1中一条规则较严格的那一半：读取方遇到类型为奇数的未知 TLV 记录时会将其丢弃并继续处理，但遇到类型为偶数的未知记录时，必须使整个数据流失败。
2^16以下的类型标识符保留给各项 BOLT，从2^16起的范围可供自定义记录自由使用，BOLT 1规定：当普通节点应忽略该数据时选奇数，应拒绝该数据时选偶数。bLIP-3记载，5482373484是原始的 lnd 实现随机选定的，它以四结尾，因此 keysend 落在了拒绝的一侧。这就是它需要功能位的原因：愿意支持的节点会通告54/55位，名为keysend，它依赖于var_onion_optin，bLIP-3指出，发送方应先查找该功能位，而不是盲目发送再眼看着失败。
bLIP-3所列的发送方任务很简短：生成一个密码学安全的随机32字节值，放入该记录，并把update_add_htlc中的payment_hash设为其 SHA-256。切勿重复使用原像，也切勿使用已付款发票中的原像。数据包在每一跳都会被混淆，因此每一跳只能恢复出下一跳的地址，中间任何节点都看不到该记录。最终节点对找到的值进行哈希，与被要求接受的哈希核对，然后完成结算。
拒绝是刻意保持低调的。BOLT 4对节点无法理解的负载有一个字面意义上的应答，即PERM|22 invalid_onion_payload，它甚至可以指明出问题的 TLV 类型。bLIP-3则要求接收方改为返回PERM|15 incorrect_or_unknown_payment_details，这样被拒绝的 keysend 就与节点从未签发过的支付哈希无法区分。
在哪里会遇到它
Keysend 是播客打赏（boost）背后的底层机制。
bLIP-10定义了第二个记录，类型为7629169，最初由 Breez 选定，它携带一个附在 keysend 支付上的扁平 JSON 数据块：播客标题、剧集、表示播放位置（以秒计）的ts、设为 boost 或 stream 的action，以及可选的message，正是它构成了 boostagram。按分钟的流式支付会把seconds_back设为60。该记录是奇数类型，因此 bLIP-10对向后兼容性不作考虑：忽略这些元数据的主播仍会收到聪。之所以需要它，是因为单独的 keysend 不会告诉收款方任何信息，应用必须自行标明节目。
同样的缺口也使 keysend 不在购买路径之中。交易所提币要么给您一张发票，要么请您提供一张，因为平台必须把这笔支付与您的账户绑定，而本站的63份交易所记录和41篇钱包评测中都没有出现这个词。bLIP-3如实陈述了这一取舍：它预计 keysend 将让位于设计更好的自发支付，并点名了 offers 和 AMP，同时列出在此期间要放弃的东西，即支付证明，以及收款方对最终 CLTV 到期时间的任何决定权。
Keysend vs 闪电地址
Keysend 和闪电地址都能让您向从未给过您发票的人付款，但只有其中一个真正省去了发票。输入 user@example.com 会让您的钱包发起一次 HTTPS 查询，返回一张全新的 BOLT11 发票，因此原像仍由收款方选定，您最终持有的是一份有对方签名支持的收据。Keysend 不需要网络请求，也不需要服务器，只需33字节的节点公钥和通往该节点的路由，事后不会给您留下任何可供证明的东西，因为这个秘密值从一开始就是您的。如果您将来可能需要证明自己已付款，请使用发票。