闪电网络设计说明书

Posted mutourend

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了闪电网络设计说明书相关的知识，希望对你有一定的参考价值。

1. 引言

比特币闪电网络论文笔记参见：

闪电网络实际实现参见设计文档 Basis of Lightning Technology (BOLT) ：

BOLT设计文档分为10个子部分：

  • BOLT #1：Base Protocol
  • BOLT #2：Peer Protocol for Channel Management
  • BOLT #3：Bitcoin Transaction and Script Formats
  • BOLT #4：Onion Routing Protocol
  • BOLT #5：Recommendations for On-chain Transaction Handling
  • BOLT #7：P2P Node and Channel Discovery
  • BOLT #8：Encrypted and Authenticated Transport
  • BOLT #9：Assigned Feature Flags
  • BOLT #10：DNS Bootstrap and Assisted Node Location
  • BOLT #11：Invoice Protocol for Lightning Payments

1.1 闪电网络关键技术简介

闪电网络为使用通道网络实现比特币快速支付的协议。
闪电网络中使用的核心技术有：

  • 1）Channels通道
    两个参与者创建闪电支付通道，往通道内存入一定数额的比特币（如0.1BTC），通道内的比特币金额会锁定在Bitcoin主网上，仅有双方签名才可消费。
    最初，他们各自持有一个比特币交易，可将所有金额（如0.1BTC）全部发送回一方。
    稍后，他们可签名新的比特币交易，将资金拆分，如0.09BTC给一方，0.01BTC给另一方，然后设置之前的比特币交易为无效的——即之前的比特币交易不可再消费。
    – 通道创建的信息，可参看 BOLT #2：Channel Establishment。
    – 创建通道时的比特币交易格式，可参看 BOLT #3：Funding Transaction Output。
    – 当参与方不同意或失败时，必须消费cross-signed bitcoin transaction，详细的处理流程可参看 BOLT #5：Recommendations for On-chain Transaction Handling。

  • 2）Conditional Payments 有条件支付
    一个闪电通道仅支持两个参与者之间支付，但是很多通道连接成网络，将支持网络内的所有用户之间进行支付。这其中用到的技术为：有条件支付——可附加在通道上，如，“若你能在6小时内公开某个秘密，你将获得0.01BTC”。一旦接收方公开了秘密，则该笔比特币交易将被一个缺少有条件支付的交易所替代，并将相应的资金添加到接收方的output中。
    – 某一方添加有条件支付交易的命令格式，详细参见 BOLT #2：Adding an HTLC，完整的比特币交易格式可参见 BOLT #3：Commitment Transaction。

  • 3）Forwarding 转发
    有条件支付可 以lower time limit的方式安全地转发给另一参与者，如“若你能在5小时内公开某个秘密，你将获得0.01BTC”【”5小时“ < 之前的”6小时“】。一旦接收方公开了秘密，则该笔比特币交易将被一个缺少有条件支付的交易所替代，并将相应的资金添加到接收方的output中。
    – 转发支付的详情参见 BOLT #2：Forwarding HTLCs
    – 如何传送支付指令参见 BOLT #4：Packet Structure

  • 4）Network Topology 网络拓扑
    要进行支付，参与者需要知道可通过哪些通道进行发送。参与者相互告知频道和节点的创建及更新信息。
    – 详细的通讯协议参见 BOLT #7：P2P Node and Channel Discovery
    – 初始的网络bootstrap参见 BOLT #10：DNS Bootstrap and Assisted Node Location

  • 5）Payment Invoicing 支付费用清单
    参与者会收到支付清单，以告知他该支付什么。
    – 描述收款对象及支付目的的协议，以便付款人以后能证明支付成功，协议详情见 BOLT #11：Invoice Protocol for Lightning Payments

1.2 词汇及术语指南

  • Announcement：peers之间发送的gossip message，用于发现通道或节点。
  • chain_hash：目标区块链的唯一标识hash值（通常为genesis hash值）。chain_hash允许节点在多个区块链上创建和引用通道。节点将忽略来源于其未引用的chain_hash 消息。与bitcoin-cli不同，该hash值不是反向的，而是可直接使用的。
    比特币主网的chain_hash值为：6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
  • Channel：在2个peers之间实现快速链下交互。为了进行资金交互，peers交换签名来创建updated commitment transaction。
    channel通道支持mutual close，revoked transaction close以及unilateral close (单方关闭)。
  • Closing transaction：为mutual close时生成的交易之一。Closing transaction与commitment transaction类似，但是没有pending payments。
  • Commitment number：用于每个commitment transaction中，为48位递增计数器。通道内每个peer的计数器是独立的，都从0开始。
  • Commitment revocation（废除） private key：每一个commitment transaction都有一个唯一的commitment revocation private-key value，另一方若拥有该key value值，则可立马花费所有outputs中的金额：通过reveal该key value值，即可废除 old commitment transaction。为了支持废除，每个commitment transaction都引用了废除该commitment对应的public key。
  • Commitment transaction：为花费funding transaction的transaction。每个peer都拥有对方对该笔交易的签名，因此，各自都有一个可花费的commitment transaction。当有新的commitment transaction时，老的将被废除。
  • Final node：一笔支付由初始节点发起，经由多个中间节点（hops），到达的最终接收方。同时为链路中的最终接收节点。
  • Funding transaction：为不可逆的链上交易，在一个通道内向2个peers付费。只有在双方同意的情况下才能使用。
  • Hop：一种节点。通常为起始节点和最终节点之间的中间节点。
  • HTLC：Hashed Time Locked Contract。
    为2个peers之间的有条件支付：接收方通过展示其签名和支付preimage来获得相应金额，否则付款人可在指定时间后取消该付款合约。这些以commtiment transaction outputs的方式实现。
  • Invoice：A request for funds on the Lightning Network, possibly。费用清单中包含：支付类型、支付金额、过期时间以及其他信息。这是闪电网络内的支付形式，而不是使用比特币式地址。
  • It’s ok to be odd：为某些数域内的规则，表示对某种feature的可选或强制支持。偶数表示2个endpoints都必须支持所讨论的feature，而技术表示endpoint可忽略该feature。
  • MSAT：为一个millisatoshi，常用作field name。
  • Mutual close：对通道的合作式关闭，通过广播一个unconditional spend of the funding transaction with an ouput to each peer（除非某个output太小才可不包含在内）。
  • Node：作为闪电网络一部分的计算机或其他设备。
  • Origin node：为一笔支付的初始节点，经由数个hops，到达最终节点。Origin node为链路上的第一个发送peer。
  • Outpoint：唯一标识unspent transaction output的transaction hash和output index。需作为输入来组成一笔新的交易。
  • Payment hash：HTLC中包含了payment hash，payment hash为payment preimage的hash值。
  • Payment preimage：为付款已收到的证明，由最终接收方持有。只有最终接收方知道该秘密。最终接收方为了release funds，需release该preimage。支付preimage 在HTCL中以payment hash的方式存在。
  • Peers：为两个相互通讯的节点。2个peers在建立通道之前可相互gossip。2个peers可通过建立通道来相互交易。
  • Penalty transaction：通过使用commitment revocation private key来消费revoked commitment transaction中所有outputs的交易。若某peer试图通过广播一个废弃的commitment transaction的方式来作弊，则另一peer可发起penalty transaction。
  • Per-commitment secret：每个commitment transaction都基于a per-commitment secret来派生keys，通过该方式，所有之前commitments的一系列per-commitment secrets都可以压缩的方式存储。
  • Processing node：为正在处理a packet的节点。该packet由origin node发起，路由发往final node。Processing node作为receiving peer来接收消息，作为sending peer来发送packet。
  • Receiving node：为正在receiving 消息的节点。
  • Revoked commitment transaction：为已废弃的old commitment transaction。因为已产生新的commitment transaction。
  • Revoked transaction close：为一个无效的通道关闭，广播的是废弃的commitment transaction。由于另一peer知道该commitment revocation secret key，可发起penalty transaction。
  • Route：为闪电网络中的路径，允许由初始节点发起的支付，经由一个或多个hops，到达最终节点。
  • Sending node：为正在sending消息的节点。
  • Sending peer：为正在给直接连接的peer发送消息的节点。
  • Unilateral close：（单方关闭）为通道的不合作关闭方式。通过广播commitment transaction来实现。该交易比closing transaction更大（即更低效），commitment被广播的peer在预设时间内，无法访问其自身的outputs。

2. BOLT #1: Base Protocol

此协议假定一个底层的经过身份验证且有序的传输机制，该机制负责对单个消息进行帧处理。详细实现可参见 BOLT #8，也可替代为其他传输机制。
默认的TCP端口为9735，对应的16进制表示为0x2607，为 the Unicode code point for LIGHTNING。
除非明确指出，所有数据field都是以unsigned big-endian形式存储。（默认SHA2和比特币公钥都是以big endian的方式编码的。）

每个peer有一个单独的连接（connection），通道信息（其中包含channel ID）应可在单个连接上复用。

2.1 闪电消息格式

解密后，所有的闪电消息格式为：

  • 1）type：为2字节的big-endian field，表明消息的类型。
  • 2）payload：为可变长度的payload，包含了剩余message的内容，其格式与type类型匹配。
  • 3）extension：为可选的 TLV（Type-Length-Value Format） stream。

不同的type类型，其解析payload的方式也不同。type类型遵循”It’s ok to be odd“规则，若不确定接收方是否理解，可发送奇数类型。（”It’s ok to be odd“规则 允许将来的可选extension扩展，而不需要协商，也不需要在客户端进行特殊编码。在可选扩展中，未来可包含额外的TLV data。注意，只有当payload长度不等于65535最大长度时，才可附加extension field。）

闪电消息类型逻辑上可分为5类，由最高有效位的值来区分：

  • Setup & Control (类型值为0-31)：表示建立连接、control、supported features以及error reporting相关的消息。Setup类型对应有init消息和error消息；Control类型对应有ping消息和pong消息
  • Channel （类型值为31-127）：用于建立和关闭微支付通道的消息。
  • Commitment（类型值为128-255）：用于更新当前commitment transaction的消息，包括adding、revoking、settling HTLCS以及更新费用和交换签名。
  • Routing（类型值为256-511）：节点和通道声明消息，以及任意的active route exploration消息。
  • Custom（类型值为32768-65535）：为测试和应用相关消息。

应传输层要求，message的size应为2字节的unsigned int，因此消息的最大size为65535 bytes。（可借助密码学wrapping技术来保证消息长度不超过65535字节。实际实现时，可将message数据以8字节对齐的方式存储，但是额外附加6个字节被认为是一种浪费，因此只在对message解码到buffer中时才做一个6字节的pre-padding。）

对于sending node：

  • 未经事先协商，不得发送此处未列出的evenly-typed message。
  • 未经事先协商，不得在extension中发送evenly-typed TLV records。
  • 协商中的可选项：必须包含该可选项中注释的所有字段。
  • 当定义custom messages时：为避免与其他custom type冲突，应选择随机type值；应不与此处列出的其他测试值冲突；当要求regular nodes可忽略additional data时，应选择奇数type值；当regular node可拒绝消息并关闭连接时，应选择偶数type值。

对于receiving node：

  • 当接收到奇数或未知type值时，必须忽略所接收到的消息；
  • 当接收到偶数或未知type值时，必须关闭连接，可fail通道。
  • 当接收到已知消息，但其内容长度不够时：必须关闭连接，可fail通道。
  • 当接收到的消息包含extension时：可忽略该extension；或者若该extension为invalid的，必须关闭连接，可fail通道。

2.2 TLV (Type-Length-Value Format)

当在现有消息类型中添加新的field时，为了向后兼容，可使用TLV。
tlv_record表示一个单独的field，其编码格式为：

  • [bigsize: type]：type以BigSize格式编码。为64位标识。
  • [bigsize: length]：以BigSize格式编码，表示value的字节大小。
  • [length: value]：根据type类型来编解码。

tlv_stream表示0个或多个tlv_record，直接将tlv_record串接在一起。当用于扩展现有消息时，tlv_stream通常位于现有所有定义fields之后。

2.3 基础类型

基础类型有：

  • byte: an 8-bit byte
  • u16: a 2 byte unsigned integer
  • u32: a 4 byte unsigned integer
  • u64: an 8 byte unsigned integer

TLV record中的类型有：

  • tu16: a 0 to 2 byte unsigned integer
  • tu32: a 0 to 4 byte unsigned integer
  • tu64: a 0 to 8 byte unsigned integer

同时，有一些自定义类型：

  • chain_hash: a 32-byte chain identifier (see BOLT #0)
  • channel_id: a 32-byte channel_id (see BOLT #2)
  • sha256: a 32-byte SHA2-256 hash
  • signature: a 64-byte bitcoin Elliptic Curve signature
  • point: a 33-byte Elliptic Curve point (compressed encoding as per SEC 1 standard)
  • short_channel_id: an 8 byte value identifying a channel (see BOLT #7)
  • bigsize: a variable-length, unsigned integer similar to Bitcoin’s CompactSize encoding, but * big-endian. Described in BigSize.

3. BOLT #2: Peer Protocol for Channel Management

某些消息会使用channel_id来标识通道。channel_id派生自funding transaction，结合了funding_txid 和 funding_output_index，采用了big-endian异或操作（即，funding_output_index改变了最后2个字节）。
在通道建立之前，使用的是随机nonce值 temporary_channel_id。注意，不同节点之间可能存在相同的temporary_channel_id值。若在创建funding transaction之前，通过channel_id来引用通道的API是不安全的，同时该API产生的交易即使确认了也是不持久的。而且除非你知道对应funding output对应的script pubkey，否则没有办法来避免channel id重复的问题。在funding_created之前，由协议提供并交换的channel标识为(source_node_id, destination_node_id, temporary_channel_id) tuple。

3.1 建立通道

在对连接进行认证（BOLT #8）和初始化（BOLT #1）之后，就可开始建立通道。
具体流程为：

  • 1）funding node (funder) 发送open_channel消息。
  • 2）另一node (fundee) 发送accept_channel消息。
  • 3）在锁定通道参数的情况下，funder可创建funding transaction和2个版本的commitment transaction（具体见BOLT #3）。然后funder将funding output的outpoint、funding_created消息、签名给fundee版本的commitment transaction 发送给fundee。
  • 4）一旦fundee收到了该funding output，其可生成签名给funder版本的commitment transaction，并将其岁funding_signed消息发给funder。
  • 5）当funder收到funding_signed消息，其必须将funding transaction广播至比特币主链上。
  • 6）当发送/收到funding_signed消息之后，双方都需等待funding transaction交易上链并达到指定的深度（区块确认数）。当书房都发出了funding_locked消息之后，通道建立完成，即可进行normal operation了。
    funding_locked消息中包含了用于构建channel authentication proof的信息。

若在以上任一环节失败，或某节点判定另一节点提供的通道条件不合适，则通道建立失败。

注意，多个通道可并行操作，所有的通道的消息要么以temporary_channel_id（在funding transaction 创建之前）标记，要么以channel_id（派生自funding transaction）标记。

    +-------+                              +-------+
    |       |--(1)---  open_channel  ----->|       |
    |       |<-(2)--  accept_channel  -----|       |
    |       |                              |       |
    |   A   |--(3)--  funding_created  --->|   B   |
    |       |<-(4)--  funding_signed  -----|       |
    |       |                              |       |
    |       |--(5)--- funding_locked  ---->|       |
    |       |<-(6)--- funding_locked  -----|       |
    +-------+                              +-------+

    - where node A is 'funder' and node B is 'fundee'

3.2 关闭通道

节点可协商以mutual close的方式关闭连接，与unilateral close不同，mutual close支持双方以更低的手续费立刻获取各自的资金。

关闭发生在2种阶段：

  • 1） 一方表示希望清理通道（因此不再接受新的HTLCs）
  • 2）当所有的HTLCs都处理完毕后，可开始协商最终的通道关闭。
 +-------+                              +-------+
 |       |--(1)-----  shutdown  ------->|       |
 |       |<-(2)-----  shutdown  --------|       |
 |       |                              |       |
 |       | <complete all pending HTLCs> |       |
 |   A   |                 ...          |   B   |
 |       |                              |       |
 |       |--(3)-- closing_signed  F1--->|       |
 |       |<-(4)-- closing_signed  F2----|       |
 |       |              ...             |       |
 |       |--(?)-- closing_signed  Fn--->|       |
 |       |<-(?)-- closing_signed  Fn----|       |
 +-------+                              +-------+

mutual close关闭通道的流程为：

  • Closing Initiation：shutdown ：任一节点或2个节点发送shutdown消息来启动关闭，shutdown消息会附带其希望收款的scriptpubkey。
  • Closing Negotiation：closing_signed：一旦shutdown完成，且通道内没有HTLCs，即the final current commitment transaction中没有HTLCs，即可开始closing fee 协商。Funder可选择一个自认为公平的费率，然后使用shutdown消息中附带的scriptpubkey值来对closing transaction和其自认公平的费率进行签名，并发送该签名。另一节点以类似的方式响应，使用其自认公平的费率。这种交互持续到直到双方达成相同的费率或者某一方fail the channel。

3.3 正常的通道操作

当节点双方交换完funding_locked之后（也可为announcement_signatures），通道将可借助Hashed Time Locked Contracts来发起支付。

批量修改：在commitment_signed消息之前，发送一个或多个update_消息，具体流程为：

    +-------+                               +-------+
    |       |--(1)---- update_add_htlc ---->|       |
    |       |--(2)---- update_add_htlc ---->|       |
    |       |<-(3)---- update_add_htlc -----|       |
    |       |                               |       |
    |       |--(4)--- commitment_signed --->|       |
    |   A   |<-(5)---- revoke_and_ack ------|   B   |
    |       |                               |       |
    |       |<-(6)--- commitment_signed ----|       |
    |       |--(7)---- revoke_and_ack ----->|       |
    |       |                               |       |
    |       |--(8)--- commitment_signed --->|       |
    |       |<-(9)---- revoke_and_ack ------|       |
    +-------+                               +-------+

一个节点仅需将这些updates添加到其自身的commitment transaction中，而远程的节点通过回复revoke_and_ack的方式来承认这些更新。

每次更新都会遍历以下状态：

  • 1）pending on the receiver
  • 2）在receiver的最新commitment transaction中
  • 3）废弃了receiver之前的commitment transaction，同时the update is pending on the sender
  • 4）在sender最新的commitment transaction中
  • 5）废弃了sender之前的commitment transaction。

由于2个节点是独立更新的，所以这2个commitment transaction可能会无限期地不同步。这没有关系，重要的是双发欧是否不可撤销地致力于某一特定的更新。

3.3.1 转发HTLCs

通常，节点发送HTLC的原因有2种：

  • 发起其自身的支付
  • 转发另一节点的支付。

在转发情况下，必须注意确保传出的HTLC不能被赎回，除非传入的HTLC可以被赎回。在下列情况下，HTLC的相应增加或删除可被视为是不可撤销committed的：

  • 1）with/without commitment transaction由通道内的2个节点commit了，且任何之前的without/with commitment transaction均已废弃。或者
  • 2）with/without commitment transaction已不可逆地提交上链了。

3.3.2 选择cltv_expiry_delta

一旦HTLC超时，它可以被完成或者超时；无论是提供的还是收到的HTLC，都必须注意这个过渡。
考虑下面的场景，其中A发送HTLC到B，转发给C，一旦收到付款，就立即交付货物:

  • 1）C需要确认B发来的HTLC不会超时，即使B不响应。即，B在链上使该HTLC超时之前，C可在链上完成该incoming HTLC。
  • 2）B必须确保C所完成的HTLC来自于B，B完成的incoming HTLC来自于A。即，B可get the preimage from C，且fulfill the incoming HTLC on-chain before A can time it out on-chain。

这其中涉及的关键设置有：

  • BOLT #7 中的cltv_expiry_delta：为转发情况下（B）的minimum difference in HTLC CLTV timeouts.
  • BOLT #9 中的min_final_cltv_expiry：为终端情况下（C）的minimum difference between HTLC CLTV timeout and the current block height。

3.3.3 添加HTLC：update_add_htlc

通道内的任一节点都可发送update_add_htlc来给另一方提供HTLC，该HTCL与a payment preimage交换。
支付金额以millisatoshi为单位，尽管链上执行的金额需大于dust limit（在commitment中，该金额会按BOLT #3 进行四舍五入）。

3.3.4 移除HTLC：update_fulfill_htlc，update_fail_htlc，update_fail_malformed_htlc

节点仅可移除由其它节点添加的HTLCs。
移除HTLC通常有4种原因：

  • 已提供了payment preimage
  • HTLC已超时
  • HTLC路由失败
  • HTLC格式错误

3.3.5 迄今为止的Committing Updates：commitment_signed

当节点为远程的commitment完成了修改后，其可应用该远程commitment，签名the resulting transaction（根据BOLT #3中定义），并发送commitment_signed消息。

3.3.6 Completing the Transition to the Updated State：revoke_and_ack

一旦收到commitment_signed，对签名进行验证并确认其为有效的新commitment transaction之后，在回复的revoke_and_ack消息中附加the commitment preimage for the previous commitment transaction。

可将revoke_and_ack简单理解为是对收到commitment_signed之后的响应，因此对于commitment_signed sender来说，其在发送消息和更新任何pending updates之间存在逻辑上的时间差。

3.3.7 更新费用：update_fee

update_fee消息决定的是节点支付的比特币交易费。与其他update类似，其首先commit to the receiver’s commitment transaction，然后收到相应后commit to the sender’s。
与HTLC不同，update_fee永不关闭，仅是简单的替换。

存在竞争的可能性，因为接收者可以在收到更新费之前添加新的htlc。在这种情况下，一旦接收方最终确认了更新费用，发送方就可能无法支付其自己的承诺交易的费用。在这种情况下，费用将低于费率，如BOLT # 3 所述。

3.4 消息重传：channel_reestablish

由于通讯传输是不可靠的，可能需不时地进行重连，所以传输的设计已经明确地从协议中分离出来。

具体加BOLT #7。

4. BOLT #3: Bitcoin Transaction and Script Formats

transactions outputs的排序规则为：

  • 首先根据transaction outputs的值（以整数satoshi为单位，注意HTLC outputs中的millisatoshi必须忽略）；
  • 接着是scriptpubkey，使用memcmp比较common-length prefix的字典顺序，然后选择更短的script；
  • 最后，对于HTLC outputs，按cltv_expiry升序排列。

闪电网络中的大多数交易outputs都为 pay-to-witness-script-hash (P2WSH) outputs：即P2SH的Segwit版本。

为了消费这些outputs，witness stack中的最后一个元素必须为the actual script that was used to generate the P2WSH output that is being spent。

Funding Transaction Output 为P2WSH to :（其中pubkey1为词典序更小的funding_pubkey，pubkey2为词典序更大的。）

2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG

4.1 Commitment Transaction

commitment transaction格式为：

  • version: 2
  • locktime：高8位为0x20，低24位为模糊的commitment number
  • txin count: 1
    – txin[0] outpoint: txid and output_index from funding_created message
    – txin[0] sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment number
    – txin[0] script bytes: 0
    – txin[0] witness: 0 <signature_for_pubkey1> <signature_for_pubkey2>

The 48-bit commitment number is obscured by XOR with the lower 48 bits of:

SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)

该值可让2节点根据index快速找到某废弃的commitment transaction。

Commitment Transaction Outputs：可支持penalty transactions，必须等待to_selft_delay 个blocks。该等待操作可通过second-stage HTLC交易来实现（HTLC-success for HTLCs accepted by the local node, HTLC-timeout for HTLCs offered by the local node——这样拆分的原因是，HTLC-timeout可在等待期内完成）。

Commitment Transaction Outputs类型有：

  • to_local Output
  • to_remote Output
  • to_local_anchor and to_remote_anchor Output (option_anchor_outputs)
  • Offered HTLC Outputs
  • Received HTLC Outputs
  • Trimmed Outputs：每个节点设置dust_limit_satoshis，不产生低于该值的outputs。这些不该产生的outputs标记为“trimmed”。

4.2 HTLC-Timeout and HTLC-Success Transactions

HTLC-Timeout 和 HTLC-Success 交易几乎一样，除了HTLC-Timeout交易为timelocked。
HTLC-Timeout 和 HTLC-Success 交易均可作为valid penalty transaction来花费。

4.3 Closing Transaction

注意每个节点有2种可能的变体：

  • version: 2
  • locktime: 0
  • txin count: 1
    – txin[0] outpoint: txid and output_index from funding_created message
    – txin[0] sequence: 0xFFFFFFFF
    – txin[0] script bytes: 0
    – txin[0] witness: 0 <signature_for_pubkey1> <signature_for_pubkey2>
  • txout count: 0, 1 or 2
    – txout amount: final balance to be paid to one node (minus fee_satoshis from closing_signed, if this peer funded the channel)
    – txout script: as specified in that node’s scriptpubkey in its shutdown message

4.4 费用

commitment transaction和HTLC transaction的费用需基于当前的feerate_per_kw和交易期望的重量来计算。

commitment transaction的交易金额和交易费均从funder账号扣除。

4.5 交易中所使用key的派生规则

每个commitment transaction都使用唯一的localpubkey和remotepubkey。
HTLC-success和HTLC-timeout 交易使用local_delayedpubkey和revocationpubkey。

每个交易的这些key会根据per_commitment_point修改。

要求每笔交易的key是变化的，是为了可外包trustless watching for revoked transaction。

考虑效率问题，这些key基于由单个种子产生的一系列per-commitment secrets来生成，使得receiver可对这些秘密进行压缩存储：

localpubkey, local_htlcpubkey, remote_htlcpubkey, local_delayedpubkey, and remote_delayedpubkey Derivation

5. BOLT #5: Recommendations for On-chain Transaction Handling

闪电网络支持2方（a local node和a remote node），通过给每一方一个cross-signed commitment transaction，用于描述通道内的当前状态（通常为当前balance）的方式，来实现链下交易。每当有新的支付时，该commitment transaction都将更新，且总是spendable的。

关闭通道的方式通常有3种：

  • 最好的方式——mutual close：local node和remote node同时同意关闭通道。他们发起closing transaction（与commitment transaction类似，但是没有任何的pending payments），并将该closing transaction广播上链。
  • 不好的方式——unilateral close：出了问题，可能双方都没有恶意。比如说，可能有一方崩溃了。一方公布最新承诺交易。
  • 最不好的方式——revoked transaction close：某一方试图作弊，广播过期的commitment transaction。

闪电网络为trustless的，可有效处理以上3种情况。

任何unspent output 可认为是unresolved。可通过resoling transaction来花费unspent output。
当output在链上记录的深度超过100个区块，即可认为该output是resolved的。100个区块大于目前已知的比特币分叉高度，同时等于矿工激励等待的确认数。

以上是关于闪电网络设计说明书的主要内容，如果未能解决你的问题，请参考以下文章

闪电网络和雷电网络 是什么 区别

如何连接两个变量并分配给闪电网络组件中闪电卡的标签属性

闪电网络（Lightning Network）学习总结

闪电网络

Flalsh Lighting Network（闪电网络）

科普 | 闪电网络和雷电网络是什么，有什么关系？