BOLT 7：P2P节点和通道发现

BOLT #7: P2P 节点和通道发现

本规范描述了简单的节点发现、通道发现和通道更新机制，这些机制不依赖于第三方来传播信息。

节点和通道发现服务于两个不同的目的：

• 节点发现允许节点广播其 ID、主机和端口，以便其他节点可以打开连接并与它们建立支付通道。
• 通道发现允许创建和维护网络拓扑的本地视图，以便节点可以发现到达所需目的地的路由。

为了支持通道和节点发现，支持三个 gossip 消息：

• 对于节点发现，节点交换 node_announcement 消息，这些消息提供有关节点的其他信息。可能存在 多个 node_announcement 消息，以便更新节点信息。

• 对于通道发现，网络中的节点交换 channel_announcement 消息，其中包含有关两个节点之间新 通道的信息。他们还可以交换 channel_update 消息，这些消息更新有关通道的信息。对于任何通道，只能有 一个有效的 channel_announcement，但预计至少有两条 channel_update 消息。

目录

• 定义 short_channel_id
• announcement_signatures 消息
• channel_announcement 消息
• node_announcement 消息
• channel_update 消息
• 查询消息
• 初始同步
• 重新广播
• HTLC费用
• 修剪网络视图
• 路由建议
• 参考

定义 short_channel_id

short_channel_id 是 funding transaction 的唯一描述。 它的构造如下：

1. 最高有效 3 字节：表示区块高度
2. 接下来 3 字节：表示区块内的交易索引
3. 最低有效 2 字节：表示支付给通道的输出索引。

short_channel_id 的标准人类可读格式是通过打印上述组件来创建的，顺序为： 块高度、交易索引和输出索引。 每个组件都打印为十进制数， 并用小写字母 x 相互分隔。 例如，short_channel_id 可以写成 539268x845x1， 表示高度为 539268 的区块中索引为 845 的交易的输出 1 上的通道。

理由

short_channel_id 人类可读格式的设计 使得双击或双击它将在大多数系统上选择整个 ID。 人们在阅读数字时更喜欢十进制， 因此 ID 组件以十进制书写。 小写字母 x 被使用，因为在大多数字体中， x 明显小于十进制数字， 使其易于清晰地将 ID 的每个组件分组。

announcement_signatures 消息

这是通道的两个端点之间的直接消息，作为一种选择机制，允许将通道公告给网络的其余部分。 它包含发送者构造 channel_announcement 消息所需的签名。

1. type: 259 (announcement_signatures)
2. data:
   • [channel_id:channel_id]
   • [short_channel_id:short_channel_id]
   • [signature:node_signature]
   • [signature:bitcoin_signature]

发起节点宣布通道的意愿在通道打开期间通过在 channel_flags 中设置 announce_channel 位来表示（参见 BOLT #2）。

要求

announcement_signatures 消息是通过构造一个 channel_announcement 消息来创建的，该消息对应于新建立的通道，并使用与端点的 node_id 和 bitcoin_key 匹配的密钥对其进行签名。签名后，可以发送 announcement_signatures 消息。

一个节点：

• 如果 open_channel 消息设置了 announce_channel 位，并且尚未发送 shutdown 消息：
  • 必须发送 announcement_signatures 消息。
    • 在发送和接收 funding_locked 并且 funding transaction 至少有六个确认之前，不得发送 announcement_signatures 消息。
• 否则：
  • 不得发送 announcement_signatures 消息。
• 重新连接时（一旦满足上述时间要求）：
  • 必须使用其自身的 announcement_signatures 消息响应第一个 announcement_signatures 消息。
  • 如果它尚未收到 announcement_signatures 消息：
    • 应该重新发送 announcement_signatures 消息。

一个接收节点：

• 如果 short_channel_id 不正确：
  • 应该发送 warning 并关闭连接，或者发送 error 并使通道失败。
• 如果 node_signature 或 bitcoin_signature 不正确：
  • 可以发送 warning 并关闭连接，或者发送 error 并使通道失败。
• 如果它已发送和接收有效的 announcement_signatures 消息：
  • 应该将其对等方的 channel_announcement 消息排队。
• 如果它尚未发送 funding_locked：
  • 可以推迟处理 announcement_signatures，直到它发送 funding_locked
  • 否则：
    • 必须忽略它。

理由

允许推迟过早的 announcement_signatures 的原因是 该规范的早期版本不需要等待接收 funding locked： 推迟而不是忽略它允许与 此行为兼容。

channel_announcement 消息

此 gossip 消息包含有关通道的所有权信息。它将 每个链上比特币密钥与关联的闪电网络节点密钥相关联，反之亦然。 在至少一方使用 channel_update 宣布 其费用水平和到期时间之前，该通道实际上是不可用的。

证明 node_1 和 node_2 之间存在通道需要：

1. 证明 funding transaction 支付给 bitcoin_key_1 和 bitcoin_key_2
2. 证明 node_1 拥有 bitcoin_key_1
3. 证明 node_2 拥有 bitcoin_key_2

假设所有节点都知道未花费的交易输出，则第一个证明是 通过节点查找 short_channel_id 给出的输出并 验证它是否确实是 BOLT #3 中指定的那些密钥的 P2WSH funding transaction 输出来完成的。

最后两个证明是通过显式签名完成的： 为每个 bitcoin_key 生成 bitcoin_signature_1 和 bitcoin_signature_2，并且对每个对应的 node_id 进行签名。

还需要证明 node_1 和 node_2 都同意该 公告消息：这是通过来自每个 node_id（node_signature_1 和 node_signature_2）对消息进行签名来完成的。

1. type: 256 (channel_announcement)
2. data:
   • [signature:node_signature_1]
   • [signature:node_signature_2]
   • [signature:bitcoin_signature_1]
   • [signature:bitcoin_signature_2]
   • [u16:len]
   • [len*byte:features]
   • [chain_hash:chain_hash]
   • [short_channel_id:short_channel_id]
   • [point:node_id_1]
   • [point:node_id_2]
   • [point:bitcoin_key_1]
   • [point:bitcoin_key_2]

要求

发起节点：

• 必须将 chain_hash 设置为唯一标识通道在其内打开的链的 32 字节哈希：
  • 对于 比特币区块链：
    • 必须将 chain_hash 值（以十六进制编码）设置为等于 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000。
• 必须设置 short_channel_id 以引用已确认的 funding transaction， 如BOLT #2中所述。
  • 注意：相应的输出必须是一个 P2WSH，如 BOLT #3 中所述。
• 必须将 node_id_1 和 node_id_2 设置为操作该通道的两个节点的公钥， 使得 node_id_1 是按升序词典顺序排序的两个压缩密钥中按字典顺序较小的。
• 必须将 bitcoin_key_1 和 bitcoin_key_2 设置为 node_id_1 和 node_id_2 的 各自的 funding_pubkey。
• 必须计算消息的 double-SHA256 哈希 h，从偏移量 256 开始，直到消息结尾。
  • 注意：哈希跳过 4 个签名，但哈希消息的其余部分， 包括附加到末尾的任何未来字段。
• 必须将 node_signature_1 和 node_signature_2 设置为哈希 h 的有效签名（使用 node_id_1 和 node_id_2 的各自的密钥）。
• 必须将 bitcoin_signature_1 和 bitcoin_signature_2 设置为哈希 h 的有效签名（使用 bitcoin_key_1 和 bitcoin_key_2 的各自的密钥）。
• 必须根据 BOLT #9 设置为此通道协商的 feature features。
• 必须将 len 设置为容纳其设置的 features 位所需的最小长度。

接收节点：

• 必须通过验证签名来验证消息的完整性和真实性。
• 如果 features 字段中存在未知偶数位：
  • 不得尝试通过该通道路由消息。
• 如果 short_channel_id 的输出不对应于 P2WSH（使用 bitcoin_key_1 和 bitcoin_key_2，如 BOLT #3 中指定的）或者输出已花费：
  • 必须忽略该消息。
• 如果指定的 chain_hash 接收方未知：
  • 必须忽略该消息。
• 否则：
  • 如果 bitcoin_signature_1、bitcoin_signature_2、node_signature_1 或 node_signature_2 无效或不正确：
    • 应该发送 warning。
    • 可以关闭连接。
    • 必须忽略该消息。
  • 否则：
    • 如果 node_id_1 或 node_id_2 在黑名单中：
      • 应该忽略该消息。
    • 否则：
      • 如果引用的 transaction 之前未宣布为通道：
        • 应该将该消息排队以进行重新广播。
        • 可以选择不发送超过预期最小长度的消息。
    • 如果之前已收到针对同一 transaction、同一区块但针对不同的 node_id_1 或 node_id_2 的有效 channel_announcement：
      • 应该将先前消息的 node_id_1 和 node_id_2 以及此 node_id_1 和 node_id_2 列入黑名单，并忘记任何与它们关联的通道。
    • 否则：
      • 应该存储此 channel_announcement。
• 一旦其 funding output 被花费或重组：
  • 应该忘记通道。

理由

需要两个节点都签名以表明他们愿意通过此通道路由其他支付（即成为公共网络的一部分）；需要他们的 比特币签名证明他们控制该通道。

将冲突节点列入黑名单不允许发布多个不同的 公告。任何 节点都不应广播此类冲突公告，因为这暗示密钥已泄漏。

虽然在通道具有足够的 depth 之前不应宣传通道，但 对重新广播的要求仅适用于 transaction 尚未移动到不同的块的情况。

为了避免存储过大的消息，但仍然允许合理的未来扩展，允许节点限制重新广播（可能在统计上）。

将来可能会出现新的通道功能：向后兼容（或 可选）功能将具有 奇数 特征位，而不兼容的功能将具有 偶数 特征位 （"It's OK to be odd!"）。

node_announcement 消息

此 gossip 消息允许节点指示与其关联的额外数据， 除了其公钥之外。为了避免琐碎的拒绝服务攻击， 会忽略与已知通道无关的节点。

1. type: 257 (node_announcement)
2. data:
   • [signature:signature]
   • [u16:flen]
   • [flen*byte:features]
   • [u32:timestamp]
   • [point:node_id]
   • [3*byte:rgb_color]
   • [32*byte:alias]
   • [u16:addrlen]
   • [addrlen*byte:addresses]

timestamp 允许对消息进行排序，以防有多个公告。rgb_color 和 alias 允许 intelligence 服务分配 节点颜色，例如黑色和酷的昵称，例如“IRATEMONK”和“WISTFULTOLL”。

addresses 允许节点宣布其接受传入的网络连接的意愿：它包含一系列用于连接到 节点的 address descriptor。第一个字节描述地址类型，后跟 该类型的适当数量的字节。

定义了以下 address descriptor 类型：

• 1: ipv4; data = [4:ipv4_addr][2:port] (长度 6)
• 2: ipv6; data = [16:ipv6_addr][2:port] (长度 18)
• 3: 已弃用（长度 12）。用于包含 Tor v2 onion service。
• 4: Tor v3 onion service; data = [35:onion_addr][2:port] (长度 37)
  • 版本 3 (prop224) onion service 地址；编码： [32:32_byte_ed25519_pubkey] || [2:checksum] || [1:version]，其中 checksum = sha3(".onion checksum" | pubkey || version)[:2]。

要求

发起节点：

• 必须将 timestamp 设置为大于之前创建的任何 node_announcement 的时间戳。
  • 可以将其基于 UNIX 时间戳。
• 必须将 signature 设置为 signature 之后整个剩余数据包的 double-SHA256 的签名（使用 node_id 给出的密钥）。
• 可以设置 alias 和 rgb_color 以自定义其在地图和图形中的外观。
  • 注意：rgb_color 的第一个字节是红色值，第二个字节是绿色值，最后一个字节是蓝色值。
• 必须将 alias 设置为有效的 UTF-8 字符串，任何 alias 后面的字节等于 0。
• 应该使用地址描述符填充 addresses，以用于每个期望传入连接的公共网络地址。
• 必须将 addrlen 设置为 addresses 中的字节数。
• 必须按升序排列地址描述符。
• 不应将任何零类型地址描述符放置在任何位置。
• 仅应将 placement 用于对齐跟随 addresses 的字段。
• 不得创建 port 等于 0 的 type 1 或 type 2 地址描述符。
• 应该确保 ipv4_addr 和 ipv6_addr 是可路由地址。
• 必须根据 BOLT #9 设置 features
• 应该将 flen 设置为容纳其设置的 features 位所需的最小长度。
• 不应宣布 Tor v2 onion service。

接收节点：

• 如果 node_id 不是有效的压缩公钥：
  • 应该发送 warning。
  • 可以关闭连接。
  • 必须不再处理该消息。
• 如果 signature 不是有效签名（使用 node_id 对 signature 字段之后整个消息的 double-SHA256 进行签名，包括 附加到末尾的任何未来字段）：
  • 应该发送 warning。
  • 可以关闭连接。
  • 必须不再处理该消息。
• 如果 features 字段包含 未知的偶数位：
  • 不应连接到该节点。
  • 除非支付 BOLT #11 invoice，其中没有 设置相同的位，否则不得尝试向该节点发送支付。
  • 不得通过该节点路由支付。
• 应该忽略与上述类型不匹配的第一个 address descriptor。
• 如果 addrlen 不足以容纳已知类型的地址描述符：
  • 应该发送 warning。
  • 可以关闭连接。
• 如果 port 等于 0：
  • 应该忽略 ipv6_addr 或 ipv4_addr。
• 如果 node_id 之前不是从 channel_announcement 消息中得知的，或者如果 timestamp 不大于从此 node_id 收到的最后一个 node_announcement 的时间戳：
  • 应该忽略该消息。
• 否则：
  • 如果 timestamp 大于从此 node_id 收到的最后一个 node_announcement 的时间戳：
    • 应该将该消息排队以进行重新广播。
    • 可以选择不将比预期最小长度长的消息排队。
• 可以使用 rgb_color 和 alias 来引用界面中的节点。
  • 应该暗示它们的自签名来源。
• 应该忽略 Tor v2 onion service。

理由

将来可能会出现新的节点功能：向后兼容（或可选）的功能将具有 奇数 feature 位，不兼容的功能将具有 偶数 feature 位。这些将正常传播；此处不兼容的特征位是指节点，而不是 node_announcement 消息本身。

将来可能会添加新的地址类型；由于地址描述符必须按升序排列，因此可以安全地忽略未知的地址类型。 将来也可能会添加超出 addresses 的其他字段 - 如果它们需要特定的对齐方式，则可以使用 addresses 中的可选填充。

节点别名的安全注意事项

节点别名是用户定义的，并为注入攻击提供了潜在途径，无论是在渲染过程中还是在持久性期间。

节点别名应始终在 HTML/Javascript 上下文或任何其他动态解释的渲染框架中显示之前进行清理。同样，请考虑使用预处理语句、输入验证和转义来防止注入漏洞和支持 SQL 或其他动态解释的查询语言的持久性引擎。

• 存储和反映的 XSS 防护
• 基于 DOM 的 XSS 防护
• SQL 注入防护

不要像 Little Bobby Tables 的学校那样。

channel_update 消息

在最初宣布通道之后，每一方都独立地宣布费用和最小到期时间增量，它需要通过此通道中继 HTLC。每一方都使用匹配 channel_announcement 的 8 字节通道 shortid 和 1 位 channel_flags 字段来指示它位于通道的哪一端（原始端或最终端）。一个节点可以多次执行此操作，以便更改费用。

请注意，channel_update gossip 消息仅在 中继 支付的上下文中有效，而不是在 发送 支付的上下文中有效。在进行支付 A -> B -> C -> D 时，只有与通道 B -> C（由 B 宣布）和 C -> D（由 C 宣布）相关的 channel_update 才会发挥作用。在构建路由时，需要从目标到源反向计算 HTLC 的金额和到期时间。用于路由中最后一个 HTLC 的 amount_msat 的确切初始值和 cltv_expiry 的最小值在支付请求中提供（参见 BOLT #11）。

1. type: 258 (channel_update)
2. data:
   • [signature:signature]
   • [chain_hash:chain_hash]
   • [short_channel_id:short_channel_id]
   • [u32:timestamp]
   • [byte:message_flags]
   • [byte:channel_flags]
   • [u16:cltv_expiry_delta]
   • [u64:htlc_minimum_msat]
   • [u32:fee_base_msat]
   • [u32:fee_proportional_millionths]
   • [u64:htlc_maximum_msat] (option_channel_htlc_max)

channel_flags 位字段用于指示通道的方向：它标识此更新的来源节点，并发出有关通道的各种选项的信号。下表指定了其各个位的含义：

位位置	名称	含义
0	direction	此更新引用的方向。
1	disable	禁用通道。

message_flags 位字段用于指示 channel_update 消息中可选字段的存在：

位位置	名称	字段
0	option_channel_htlc_max	htlc_maximum_msat

请注意，htlc_maximum_msat 字段在当前 协议中在通道的生命周期内是静态的：它 不是 设计用于指示每个方向的实时通道容量，这将是大量的数据泄漏并且无用地垃圾邮件网络（gossip 平均需要 30 秒才能传播每个 hop）。

签名验证的 node_id 取自相应的 channel_announcement：如果标志的最低有效位是 0，则为 node_id_1，否则为 node_id_2。

要求

发起节点：

• 在收到 funding_locked 之前，不得发送创建的 channel_update。
• 可以创建一个 channel_update 以将通道参数传递给 通道对等方，即使通道尚未宣布（即未设置 announce_channel 位）。
  • 出于隐私原因，不得将此类 channel_update 转发给其他对等方。
  • 注意：此类 channel_update（未先前的 channel_announcement）对任何其他对等方都无效，并且会被丢弃。
• 必须将 signature 设置为其自身的 node_id 使用 signature 之后整个剩余数据包的 double-SHA256 的签名。
• 必须设置 chain_hash 和 short_channel_id 以匹配唯一标识 channel_announcement 消息中指定的通道的 32 字节哈希和 8 字节通道 ID。
• 如果发起节点是消息中的 node_id_1：
  • 必须将 channel_flags 的 direction 位设置为 0。
• 否则：
  • 必须将 channel_flags 的 direction 位设置为 1。
• 如果存在 htlc_maximum_msat 字段：
  • 必须将 message_flags 的 option_channel_htlc_max 位设置为 1。
  • 必须将 htlc_maximum_msat 设置为它将通过此通道为单个 HTLC 发送的最大值。
    • 必须将其设置为小于或等于 channel capacity。
    • 必须将其设置为小于或等于它从对等方收到的 max_htlc_value_in_flight_msat。
• 否则：
  • 必须将 message_flags 的 option_channel_htlc_max 位设置为 0。
• 必须将 channel_flags 和 message_flags 中未分配含义的位设置为 0。
• 可以创建一个 disable 位设置为 1 的 channel_update 并发送，以指示通道的暂时不可用（例如，由于连接丢失）或永久不可用（例如，在链上结算之前）。
  • 可以发送一个 disable 位设置为 0 的后续 channel_update 以重新启用该通道。
• 必须将 timestamp 设置为大于 0，并且大于为此 short_channel_id 以前发送的任何 channel_update。
  • 应该基于 UNIX 时间戳设置 timestamp。
• 必须将 cltv_expiry_delta 设置为它将从传入 HTLC 的 cltv_expiry 中减去的区块数。
• 必须将 htlc_minimum_msat 设置为通道对等方将接受的最小 HTLC 值（以毫聪为单位）。
• 必须将 fee_base_msat 设置为它将对任何 HTLC 收取的基本费用（以毫聪为单位）。
• 必须将 fee_proportional_millionths 设置为它将对每个转移的聪收取的金额（以百万分之一聪为单位）。
• 不应创建冗余的 channel_update。

接收节点：

• 如果 short_channel_id 与之前的 channel_announcement 不匹配，或者在此期间通道已关闭：
  • 必须忽略不对应于其自身通道之一的 channel_update。
• 应该接受其自身通道的 channel_update（即使是非公共的），以便学习关联的发起节点的转发参数。
• 如果 signature 不是有效签名，则使用 signature 字段之后整个消息的 double-SHA256 的 node_id（包括 fee_proportional_millionths 之后的未知字段）：
  • 应该发送 warning 并关闭连接。
  • 必须不再处理该消息。
• 如果指定的 chain_hash 值未知（这意味着它在指定的链上不活动）：
  • 必须忽略通道更新。
• 如果 timestamp 等于为此 short_channel_id 和 node_id 最后收到的 channel_update：
  • 如果 timestamp 下面的字段不同：
    • 可以将此 node_id 列入黑名单。
    • 可以忘记与其关联的所有通道。
  • 如果 timestamp 下面的字段相等：
    • 应该忽略此消息
• 如果 timestamp 低于为此 short_channel_id 和 node_id 最后收到的 channel_update 的时间戳：
  • 应该忽略该消息。
• 否则：
  • 如果 timestamp 在未来太远：
    • 可以丢弃 channel_update。
  • 否则：
    • 应该将该消息排队以进行重新广播。
    • 可以选择不将比预期最小长度长的消息排队。
• 如果 message_flags 的 option_channel_htlc_max 位为 0：
  • 必须认为 htlc_maximum_msat 不存在。
• 否则：
  • 如果 htlc_maximum_msat 不存在或大于 channel capacity：
    • 可以将此 node_id 列入黑名单
    • 应该在路由考虑期间忽略此通道。
  • 否则：
    • 应该在路由时考虑 htlc_maximum_msat。

理由

节点使用 timestamp 字段来修剪 channel_update，这些 channel_update 要么在未来太远，要么已经两周未更新；因此，将其设置为 UNIX 时间戳（即自 UTC 1970-01-01 以来的秒数）是有意义的。然而，这不能是一个硬性要求，因为可能存在在一秒钟内有两个 channel_update 的情况。

假设在一秒钟内多次更改通道参数的 channel_update 消息可能是 DoS 尝试，因此，负责 签名此类消息的节点可能会被列入黑名单。但是，节点可能会发送带有不同签名的相同 channel_update 消息（更改签名签名中的 nonce），因此会检查签名之外的字段，以查看通道 参数对于相同的时间戳是否已更改。同样重要的是要注意 ECDSA 签名是可延展的。因此，接收到 channel_update 消息的中间节点可以通过仅将签名的 s 分量更改为 -s 来重新广播它。 然而，这不应导致消息来源的 node_id 被列入黑名单。

显式的 option_channel_htlc_max 标志指示 htlc_maximum_msat 的存在（而不是通过消息长度暗示 htlc_maximum_msat）允许我们在将来使用不同的字段扩展 channel_update。由于在比特币中，通道被限制为 2^32-1 毫聪，因此 htlc_maximum_msat 具有相同的限制。

反对冗余 channel_update 的建议最大程度地减少了垃圾邮件网络，但有时这是不可避免的。例如，与不可达的对等方的通道最终会导致 channel_update 指示该通道已禁用，而当对等方重新建立联系时，另一个更新会重新启用该通道。由于 gossip 消息是批处理的并替换以前的消息，因此结果可能是一个看似冗余的更新。

查询消息

通过 init 协商 gossip_queries 选项启用了许多扩展查询，用于 gossip 同步。这些显式请求应该接收哪些 gossip。

有几个消息包含一个长的 short_channel_id 数组 (称为 encoded_short_ids)，因此我们包含一个编码字节，如果它们提供好处，该编码字节允许将来定义不同的编码方案。

编码类型：

• 0: short_channel_id 类型的未压缩数组，按升序排列。
• 1: 以前用于 zlib 压缩，此编码不得使用。

此编码也用于其他类型的数组（时间戳、标志...），并使用 encoded_ 前缀指定。例如，encoded_timestamps 是带有 0 前缀的时间戳数组。

可以通过启用以下功能来扩展查询消息，这些功能可以帮助减少同步路由表所需的消息数量：

• 基于时间戳的 channel_update 消息过滤：仅请求比你已有的 channel_update 消息更新的消息。
• 基于校验和的 channel_update 消息过滤：仅请求与你已有的消息携带不同信息的 channel_update 消息。

节点可以使用 gossip_queries_ex feature bit 来表示它们支持扩展的 gossip 查询。

query_short_channel_ids/reply_short_channel_ids_end 消息

1. type: 261 (`query_short_channel_ids`) (`gossip_queries`)
2. data:
    * [`chain_hash`:`chain_hash`]
    * [`u16`:`len`]
    * [`len*byte`:`encoded_short_ids`]
    * [`query_short_channel_ids_tlvs`:`tlvs`]

1. `tlv_stream`: `query_short_channel_ids_tlvs`
2. types:
    1. type: 1 (`query_flags`)
    2. data:
        * [`byte`:`encoding_type`]
        * [`...*byte`:`encoded_query_flags`]

encoded_query_flags 是一个 bitfield 数组，每个 bitfield 对应一个 bigsize，每个 short_channel_id 对应一个 bitfield。这些位具有以下含义：

位位置	含义
0	发送者想要 channel_announcement
1	发送者想要 节点 1 的 channel_update
2	发送者想要 节点 2 的 channel_update
3	发送者想要 节点 1 的 node_announcement
4	发送者想要 节点 2 的 node_announcement

查询标志必须以最小编码方式编码，这意味着一个标志将用单个字节编码。

1. 类型：262 (reply_short_channel_ids_end) (gossip_queries)
2. 数据：
   • [chain_hash:chain_hash]
   • [byte:full_information]

这是一种通用机制，允许节点查询特定通道（通过 short_channel_id 标识）的 channel_announcement 和 channel_update 消息。这通常用于以下情况： 节点看到一个它没有 channel_announcement 的 channel_update，或者 因为它从 reply_channel_range 获取了先前未知的 short_channel_id。

要求

发送方：

• 如果它已经向该对等方发送了先前的 query_short_channel_ids 并且没有收到 reply_short_channel_ids_end，则必须不发送 query_short_channel_ids。
• 必须将 chain_hash 设置为唯一标识 short_channel_id 所引用的链的 32 字节哈希值。
• 必须将 encoded_short_ids 的第一个字节设置为编码类型。
• 必须将整数个 short_channel_id 编码为 encoded_short_ids
• 如果它收到一个它没有 channel_announcement 的 short_channel_id 的 channel_update，则可以发送此消息。
• 如果所引用的通道不是未花费的输出，则不应发送此消息。
• 可以包含可选的 query_flags。如果是这样：
  • 必须设置 encoding_type，就像 encoded_short_ids 一样。
  • 每个查询标志都是一个最小编码的 bigsize。
  • 必须为每个 short_channel_id 编码一个查询标志。

接收方：

• 如果 encoded_short_ids 的第一个字节不是已知的编码类型：
  • 可以发送一个 warning。
  • 可以关闭连接。
• 如果 encoded_short_ids 没有解码为整数个 short_channel_id：
  • 可以发送一个 warning。
  • 可以关闭连接。
• 如果它尚未向来自此发送方的先前收到的 query_short_channel_ids 发送 reply_short_channel_ids_end：
  • 可以发送一个 warning。
  • 可以关闭连接。
• 如果传入消息包含 query_short_channel_ids_tlvs：
  • 如果 encoding_type 不是已知的编码类型：
    • 可以发送一个 warning。
    • 可以关闭连接。
  • 如果 encoded_query_flags 没有解码为每个 short_channel_id 恰好一个标志：
    • 可以发送一个 warning。
    • 可以关闭连接。
• 必须响应每个已知的 short_channel_id：
  • 如果传入消息不包含 encoded_query_flags：
    • 包含 channel_announcement 以及每个端的最新 channel_update
    • 必须接着发送每个 channel_announcement 的任何 node_announcement
  • 否则：
    • 我们将 encoded_short_ids 中第 N 个 short_channel_id 的 query_flag 定义为已解码的 encoded_query_flags 的第 N 个 bigsize。
    • 如果设置了 query_flag 的第 0 位：
      • 必须回复一个 channel_announcement
    • 如果设置了 query_flag 的第 1 位并且它已经从 node_id_1 收到了一个 channel_update：
      • 必须回复 node_id_1 的最新 channel_update
    • 如果设置了 query_flag 的第 2 位并且它已经从 node_id_2 收到了一个 channel_update：
      • 必须回复 node_id_2 的最新 channel_update
    • 如果设置了 query_flag 的第 3 位并且它已经从 node_id_1 收到了一个 node_announcement：
      • 必须回复 node_id_1 的最新 node_announcement
    • 如果设置了 query_flag 的第 4 位并且它已经从 node_id_2 收到了一个 node_announcement：
      • 必须回复 node_id_2 的最新 node_announcement
  • 不应等待下一次传出 gossip 刷新来发送这些。
• 应避免在响应单个 query_short_channel_ids 时发送重复的 node_announcements。
• 必须在这些响应之后发送 reply_short_channel_ids_end。
• 如果不维护 chain_hash 的最新通道信息：
  • 必须将 full_information 设置为 0。
• 否则：
  • 应将 full_information 设置为 1。

理由

未来的节点可能没有完整的信息; 它们肯定不会有关于未知 chain_hash 链的完整信息。虽然这个 full_information 字段（以前被错误地称为 complete）不可信，但 0 确实表明发送者应该在其他地方搜索额外的数据。

显式的 reply_short_channel_ids_end 消息意味着接收者可以表明它一无所知，并且发送者不需要依赖超时。它还会导致查询的自然速率限制。

query_channel_range 和 reply_channel_range 消息

1. 类型：263 (query_channel_range) (gossip_queries)

2. 数据：

   • [chain_hash:chain_hash]
   • [u32:first_blocknum]
   • [u32:number_of_blocks]
   • [query_channel_range_tlvs:tlvs]

3. tlv_stream: query_channel_range_tlvs

4. 类型：

   1. 类型：1 (query_option)
   2. 数据：
      • [bigsize:query_option_flags]

query_option_flags 是一个位域，表示为最小编码的 bigsize。位的含义如下：

位位置	含义
0	发送者想要时间戳
1	发送者想要校验和

虽然这是可能的，但不要求时间戳而要求校验和是没有意义的：接收节点可能具有具有不同校验和的旧 channel_update，要求它是没有用的。并且如果 channel_update 校验和实际上为 0（这是非常不可能的），则不会对其进行查询。

1. 类型：264 (reply_channel_range) (gossip_queries)

2. 数据：

   • [chain_hash:chain_hash]
   • [u32:first_blocknum]
   • [u32:number_of_blocks]
   • [byte:sync_complete]
   • [u16:len]
   • [len*byte:encoded_short_ids]
   • [reply_channel_range_tlvs:tlvs]

3. tlv_stream: reply_channel_range_tlvs

4. 类型：

   1. 类型：1 (timestamps_tlv)
   2. 数据：
      • [byte:encoding_type]
      • [...*byte:encoded_timestamps]
   3. 类型：3 (checksums_tlv)
   4. 数据：
      • [...*channel_update_checksums:checksums]

对于单个 channel_update，时间戳编码如下：

1. 子类型：channel_update_timestamps
2. 数据：
   • [u32:timestamp_node_id_1]
   • [u32:timestamp_node_id_2]

其中：

• timestamp_node_id_1 是 node_id_1 的 channel_update 的时间戳，如果没有来自该节点的 channel_update，则为 0。
• timestamp_node_id_2 是 node_id_2 的 channel_update 的时间戳，如果没有来自该节点的 channel_update，则为 0。

对于单个 channel_update，校验和编码如下：

1. 子类型：channel_update_checksums
2. 数据：
   • [u32:checksum_node_id_1]
   • [u32:checksum_node_id_2]

其中：

• checksum_node_id_1 是 node_id_1 的 channel_update 的校验和，如果没有来自该节点的 channel_update，则为 0。
• checksum_node_id_2 是 node_id_2 的 channel_update 的校验和，如果没有来自该节点的 channel_update，则为 0。

channel_update 的校验和是 RFC3720 中指定的 CRC32C 校验和，该校验和不包含其 signature 和 timestamp 字段。

这允许查询特定块内的通道。

要求

query_channel_range 的发送方：

• 如果它已经向该对等方发送了先前的 query_channel_range 并且没有收到所有 reply_channel_range 回复，则必须不发送此消息。
• 必须将 chain_hash 设置为唯一标识它希望 reply_channel_range 引用的链的 32 字节哈希值
• 必须将 first_blocknum 设置为它想要知道通道的第一个块
• 必须将 number_of_blocks 设置为 1 或更大。
• 可以附加一个额外的 query_channel_range_tlv，它指定了它想要接收的扩展信息的类型。

query_channel_range 的接收方：

• 如果它尚未向来自此发送方的先前收到的 query_channel_range 发送所有 reply_channel_range：
  • 可以发送一个 warning。
  • 可以关闭连接。
• 必须回复一个或多个 reply_channel_range：
  • 必须设置 chain_hash 等于 query_channel_range 的 chain_hash，
  • 必须将 number_of_blocks 限制为可以将结果放入 encoded_short_ids 的最大块数
  • 可以跨多个 reply_channel_range 拆分块内容。
  • 第一个 reply_channel_range 消息：
    • 必须将 first_blocknum 设置为小于或等于 query_channel_range 中的 first_blocknum
    • 必须设置 first_blocknum 加上 number_of_blocks 大于 query_channel_range 中的 first_blocknum。
  • 后续的 reply_channel_range 消息：
    • 必须具有等于或大于先前的 first_blocknum 的 first_blocknum。
  • 如果这不是最终的 reply_channel_range，必须将 sync_complete 设置为 false。
  • 最终的 reply_channel_range 消息：
    • 必须具有 first_blocknum 加上 number_of_blocks 等于或大于 query_channel_range first_blocknum 加上 number_of_blocks。
  • 必须将 sync_complete 设置为 true。

如果传入消息包含 query_option，则接收方可以将附加信息附加到其回复中：

• 如果设置了 query_option_flags 中的第 0 位，则接收方可以附加一个 timestamps_tlv，其中包含 encoded_short_ids 中所有 short_chanel_id 的 channel_update 时间戳
• 如果设置了 query_option_flags 中的第 1 位，则接收方可以附加一个 checksums_tlv，其中包含 encoded_short_ids 中所有 short_chanel_id 的 channel_update 校验和

理由

单个响应可能对于单个数据包来说太大了，因此可能需要多个回复。我们希望允许对等方存储（例如）1000 个块范围的罐头结果，因此回复可以超过请求的范围。但是，我们要求每个回复都相关（与请求的范围重叠）。

通过坚持回复按递增顺序排列，接收方可以轻松确定回复是否完成：只需检查 first_blocknum 加上 number_of_blocks 是否等于或超过它要求的 first_blocknum 加上 number_of_blocks。

时间戳和校验和字段的添加允许对等方省略查询冗余更新。

gossip_timestamp_filter 消息

1. 类型：265 (gossip_timestamp_filter) (gossip_queries)
2. 数据：
   • [chain_hash:chain_hash]
   • [u32:first_timestamp]
   • [u32:timestamp_range]

此消息允许节点将未来的 gossip 消息限制为特定范围。想要任何 gossip 消息的节点必须发送此消息，否则 gossip_queries 协商意味着不会收到任何 gossip 消息。

请注意，此过滤器会替换任何先前的过滤器，因此可以使用多次来更改来自对等方的 gossip。

要求

发送方：

• 必须将 chain_hash 设置为唯一标识它希望 gossip 引用的链的 32 字节哈希值。

接收方：

• 应发送所有 timestamp 大于或等于 first_timestamp 且小于 first_timestamp 加上 timestamp_range 的gossip 消息。
  • 可以等待下一次传出 gossip 刷新来发送这些。
• 应在生成gossip 消息时发送它们，而不管 timestamp 如何。
• 否则（中继gossip）：
  • 应将未来的gossip 消息限制为那些 timestamp 大于或等于 first_timestamp 且小于 first_timestamp 加上 timestamp_range 的消息。
• 如果 channel_announcement 没有相应的 channel_update：
  • 必须不发送 channel_announcement。
• 否则：
  • 必须将 channel_announcement 的 timestamp 视为相应 channel_update 的 timestamp。
  • 必须在收到第一个相应的 channel_update 后再考虑是否发送 channel_announcement。
• 如果发送了 channel_announcement：
  • 必须在任何相应的 channel_update 和 node_announcement 之前发送 channel_announcement。

理由

由于 channel_announcement 没有时间戳，我们生成一个可能的时间戳。如果没有 channel_update，则根本不会发送它，这很可能发生在修剪的通道中。

否则，channel_announcement 通常紧随其后的是 channel_update。理想情况下，我们将指定使用第一个（最旧的）channel_update 的时间戳作为 channel_announcement 的时间，但网络上的新节点不会有这个，并且进一步需要存储第一个 channel_update 时间戳。相反，我们允许使用任何更新，这很容易实现。

在仍然错过 channel_announcement 的情况下，可以使用 query_short_channel_ids 来检索它。

当节点有许多对等方时，可以使用 timestamp_filter 来减少它们的gossip 负载（例如，在最初的几个对等方之后将 first_timestamp 设置为 0xFFFFFFFF，假设传播是足够的）。对足够传播的这种假设不适用于节点本身直接生成的gossip 消息，因此它们应该忽略过滤器。

初始同步

如果节点需要gossip 消息的初始同步，它将在 init 消息中通过功能标志进行标记（BOLT #9）。

请注意，如果通过 init 协商了 gossip_queries 功能，则 initial_routing_sync 功能将被覆盖（并且应被视为等于 0）。

请注意，gossip_queries 不适用于旧节点，因此 initial_routing_sync 的值对于控制与它们的交互仍然很重要。

要求

一个节点：

• 如果协商了 gossip_queries 功能：
  • 必须不中继任何它自己没有生成的gossip 消息，除非明确要求。
• 否则：
  • 如果它需要对等方路由状态的完整副本：
    • 应将 initial_routing_sync 标志设置为 1。
  • 在收到 initial_routing_sync 标志设置为 1 的 init 消息后：
    • 应发送所有已知通道和节点的gossip 消息，就好像它们刚刚收到一样。
  • 如果 initial_routing_sync 标志设置为 0，或者如果初始同步已完成：
    • 应恢复正常操作，如以下 重新广播 部分中所述。

重新广播

要求

接收节点：

• 在收到新的 channel_announcement 或 channel_update 或具有更新的 timestamp 的 node_announcement 之后：
  • 应相应地更新其本地网络拓扑视图。
• 在应用公告中的更改之后：
  • 如果没有与相应的原始节点关联的通道：
    • 可以从其已知节点集中清除原始节点。
  • 否则：
    • 应更新适当的元数据 并且 存储与公告关联的签名。
      • 注意：这将稍后允许节点为其对等方重建公告。

一个节点：

• 如果协商了 gossip_queries 功能：
  • 在收到 gossip_timestamp_filter 之前，必须不发送它自己没有生成的gossip。
• 应每 60 秒刷新一次传出的gossip 消息，而与消息的到达时间无关。
  • 注意：这会导致独特的（未复制的）交错公告。
  • 不应 将gossip 消息转发给在 init 中发送 networks 并且未指定此gossip 消息的 chain_hash 的对等方。
• 可以定期重新公告其通道。
  • 注意：不鼓励这样做，以保持资源需求较低。
• 在建立连接后：
  • 应发送所有 channel_announcement 消息，然后发送最新的 node_announcement 并且 channel_update 消息。

理由

一旦gossip 消息被处理，它就会被添加到传出消息的列表中，这些消息将发送到处理节点的对等方，从而替换来自原始节点的任何旧更新。此gossip 消息列表将定期刷新; 这种存储和延迟转发广播称为交错广播。此外，这种批处理形成了具有低开销的自然速率限制。

在重新连接时发送所有gossip 消息是幼稚的，但很简单，并且允许新节点进行引导以及为已离线一段时间的节点进行更新。gossip_queries 选项允许更精细的同步。

HTLC 费用

要求

原始节点：

• 应接受支付等于或大于以下费用的 HTLC：
  • fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )
• 在发送 channel_update 后的合理时间内，应接受支付旧费用的 HTLC。
  • 注意：这允许任何传播延迟。

修剪网络视图

要求

一个节点：

• 应监控区块链中的资金交易，以识别正在关闭的通道。
• 如果一个通道的资金输出正在被花费：
  • 应从本地网络视图中删除 并且 被视为已关闭。
• 如果公告的节点不再有任何关联的开放通道：
  • 可以 从其本地视图中修剪通过 node_announcement 消息添加的节点。
    • 注意：这是 node_announcement 依赖于 channel_announcement 之前的一个直接结果。

关于修剪陈旧条目的建议

要求

一个节点：

• 如果一个通道的最旧 channel_update 的 timestamp 早于两周（1209600 秒）：
  • 可以修剪该通道。
  • 可以忽略该通道。
  • 注意：这是一个单独的节点策略，必须不通过转发对等方强制执行，例如，通过在收到过时的gossip 消息时关闭通道。

理由

几种情况可能导致通道变得不可用，并且其端点变得无法为这些通道发送更新。例如，如果两个端点都失去了对其私钥的访问权限，并且既不能签署 channel_update，也不能在链上关闭通道，则会发生这种情况。在这种情况下，通道不太可能成为计算路由的一部分，因为它们将与网络的其余部分分开; 但是，它们将保留在本地网络视图中，并将无限期地转发给其他对等方。

最旧的 channel_update 用于修剪通道，因为双方都需要处于活动状态才能使通道可用。这样做可以修剪通道，即使一方继续发送新的 channel_update，但另一方已经消失。

路由建议

在计算 HTLC 的路由时，需要同时考虑 cltv_expiry_delta 和费用：cltv_expiry_delta 会导致在最坏情况下的故障中资金将不可用的时间。这两个属性之间的关系尚不清楚，因为它取决于所涉及节点的可靠性。

如果通过简单地路由到预期的接收者并对 cltv_expiry_delta 求和来计算路由，那么中间节点可能会猜测它们在路由中的位置。了解 HTLC 的 CLTV、周围的网络拓扑和 cltv_expiry_delta 使攻击者可以猜测预期的接收者。因此，非常希望向预期接收者将收到的 CLTV 添加一个随机偏移量，这会提升沿路由的所有 CLTV。

为了创建一个合理的偏移量，原始节点可以在图上启动一个有限的随机游走，从预期的接收者开始并对 cltv_expiry_delta 求和，并将结果总和用作偏移量。这有效地创建了实际路由的影子路由扩展，并提供了比简单地选取一个随机偏移量更好的保护，防止这种攻击向量。

其他更高级的考虑因素包括路由选择的多样化，以避免单点故障和检测，以及本地通道的平衡。

路由示例

请考虑四个节点：

   B
  / \
 /   \
A     C
 \   /
  \ /
   D

每个节点在其每个通道的末尾都公布以下 cltv_expiry_delta：

1. A：10 个区块
2. B：20 个区块
3. C：30 个区块
4. D：40 个区块

C 在请求付款时也使用 9 的 min_final_cltv_expiry（默认值）。

此外，每个节点都有一套费用方案，用于其每个通道：

1. A：100 基础费用 + 1000 百万分之一
2. B：200 基础费用 + 2000 百万分之一
3. C：300 基础费用 + 3000 百万分之一
4. D：400 基础费用 + 4000 百万分之一

网络将看到八个 channel_update 消息：

1. A->B：cltv_expiry_delta = 10，fee_base_msat = 100，fee_proportional_millionths = 1000
2. A->D：cltv_expiry_delta = 10，fee_base_msat = 100，fee_proportional_millionths = 1000
3. B->A：cltv_expiry_delta = 20，fee_base_msat = 200，fee_proportional_millionths = 2000
4. D->A：cltv_expiry_delta = 40，fee_base_msat = 400，fee_proportional_millionths = 4000
5. B->C：cltv_expiry_delta = 20，fee_base_msat = 200，fee_proportional_millionths = 2000
6. D->C：cltv_expiry_delta = 40，fee_base_msat = 400，fee_proportional_millionths = 4000
7. C->B：cltv_expiry_delta = 30，fee_base_msat = 300，fee_proportional_millionths = 3000
8. C->D：cltv_expiry_delta = 30，fee_base_msat = 300，fee_proportional_millionths = 3000

B->C. 如果 B 要直接向 C 发送 4,999,999 毫聪，它既不会向自己收取费用，也不会添加自己的 cltv_expiry_delta，因此它将使用 C 请求的 min_final_cltv_expiry 9。据推测，它还会添加一个影子路由以额外提供 CLTV 42。此外，它可以在其他跳中添加额外的 CLTV delta，因为这些值表示最小值，但为了简单起见，此处不这样做：

• amount_msat: 4999999
• cltv_expiry: current-block-height + 9 + 42
• onion_routing_packet:
  • amt_to_forward = 4999999
  • outgoing_cltv_value = current-block-height + 9 + 42

A->B->C. 如果 A 要通过 B 向 C 发送 4,999,999 毫聪，则需要向 B 支付 B->C channel_update 中指定的费用，计算方式为 HTLC 费用：

    fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )

    200 + ( 4999999 * 2000 / 1000000 ) = 10199

类似地，它需要添加 B->C 的 channel_update cltv_expiry_delta (20)、C 请求的 min_final_cltv_expiry (9) 和 影子路由 的成本 (42)。因此，A->B 的 update_add_htlc 消息将是：

• amount_msat: 5010198
• cltv_expiry: current-block-height + 20 + 9 + 42
• onion_routing_packet:
  • amt_to_forward = 4999999
  • outgoing_cltv_value = current-block-height + 9 + 42

B->C 的 update_add_htlc 将与上面 B->C 的直接付款相同。

A->D->C. 最后，如果由于某种原因 A 选择了通过 D 的更昂贵的路由，则 A->D 的 update_add_htlc 消息将是：

• amount_msat: 5020398
• cltv_expiry: current-block-height + 40 + 9 + 42
• onion_routing_packet:
  • amt_to_forward = 4999999
  • outgoing_cltv_value = current-block-height + 9 + 42

D->C 的 update_add_htlc 将再次与上面 B->C 的直接付款相同。

<br> 本作品已获得 Creative Commons Attribution 4.0 International License 的许可。

• 原文链接： github.com/lightning/bol...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～