Lightning Network BOLT Specifications

Route blinding is a technique used to provide recipient anonymity by blinding an arbitrary number of hops at the end of an onion path. Unlike rendezvous routing, it replaces the public keys of nodes in a route with random public keys while allowing senders to choose the data in the onion for each hop.

Common Use Cases:

• Onion Messages: Providing sender and recipient anonymity.
• Bolt 12 Offers: Providing recipient anonymity.
• Payments: Providing recipient anonymity when receiving payments.
• Unannounced Channels: Using unannounced channels in invoices without revealing them.
• Intermediary Control: Forcing a payment to go through a specific set of intermediaries that can witness the payment.

Core Mechanism: A recipient chooses an introduction point and a route to itself. The recipient blinds each node and channel along that route using ECDH. The recipient then shares the blinded route details and cryptographic material (via a Bolt 11 invoice or Bolt 12 offer) with the sender, enabling the sender to build an onion that allows blinded nodes to incrementally unblind the next hop.

BOLT #4 defines an onion routing protocol used to route payments from an origin node to a final node through a series of intermediate nodes called hops.

Key characteristics:

• Privacy: Intermediate nodes can verify packet integrity and identify the next hop, but they cannot learn the total route length, their position in the route, or any nodes other than their immediate predecessor and successor.
• Obfuscation: The packet is obfuscated at each hop to prevent network-level attackers from associating packets belonging to the same route via correlating information (though traffic analysis remains a risk).
• Security Construction: Based on the Sphinx construction, using ECDH to create shared secrets between the origin node and every node in the route (intermediate and final).
• Version Handling: If a node receives a packet with a version higher than the one it implements, it MUST report a route failure to the origin node and MUST discard the packet.

BOLT #3 defines several critical transaction types used in the Lightning Network to manage channel state and liquidity:

• Funding Transaction: The initial transaction that opens a channel by moving funds into a multi-signature output.
• Commitment Transaction: A transaction used to update the channel state. It typically contains outputs for both the local and remote nodes, representing their respective balances. These transactions are often 'untrimmed' to include extra outputs for fees or specific state requirements.
• Penalty Transaction: A transaction used to resolve disputes. If a peer behaves maliciously, the other party can broadcast a penalty transaction to claim the entire channel balance.

Commitment Transaction Outputs can be directed to:

• A remote node with a revocation key: Used during normal state updates.
• A local node via an HTLC-timeout transaction: A timelocked path used to recover funds if a specific condition (like an HTLC timeout) is met.

During channel establishment v2, peers use interactive transaction construction to build the funding transaction.

tx_add_input Requirements:

• If the receiver set require_confirmed_inputs in any negotiation message (open_channel2, accept_channel2, tx_init_rbf, or tx_ack_rbf), the sender MUST NOT send a tx_add_input containing an unconfirmed input.

tx_add_output Requirements:

• The opener MUST send at least one tx_add_output containing the channel's funding output.

tx_complete Requirements: Upon receipt of consecutive tx_complete messages, the receiving node must follow these rules:

• If the receiver is the accepter:
  • MUST fail if no funding output was received.
  • MUST fail if the funding output value $\neq$ (open_channel2.funding_satoshis + accept_channel2.funding_satoshis).
  • MUST fail if the funding output value is less than the dust_limit.
  • If this is an RBF attempt: MUST fail if the transaction's total fees are less than the last successfully negotiated transaction's fees, or if it doesn't share at least one input with each previous funding transaction.
  • If require_confirmed_inputs was set: MUST fail if any input added by the other peer is unconfirmed.

Note on Channel Reserve: The channel reserve is fixed at 1% of the total channel balance (open_channel2.funding_satoshis + accept_channel2.funding_satoshis) rounded down to the nearest whole satoshi or the dust_limit_satoshis, whichever is greater.

Channel Establishment v2 allows the accepter (non-initiator) to contribute inputs to the funding transaction via interactive transaction construction.

Workflow Overview:

1. Initiation: Node A (opener/initiator) sends open_channel2 to Node B (accepter/non-initiator).
2. Acceptance: Node B responds with accept_channel2.
3. Commitment Exchange: Both peers exchange commitment_signed messages for the first commitment transaction (which must have zero HTLCs).
4. Signature Exchange: Peers exchange tx_signatures for the funding transaction.
5. RBF (Optional): If needed, peers can perform a Replace-By-Fee (RBF) collaboration using tx_init_rbf, tx_ack_rbf, and subsequent commitment/signature exchanges.
6. Completion: Once signatures are exchanged and the transaction is ready, both nodes exchange channel_ready messages to finalize the channel.

+-------+                              +-------+
        |       |--(1)--- open_channel2  ----->|       |
        |       |<-(2)--- accept_channel2 -----|       |
        |       |                              |       |
    --->|       |      <tx collaboration>      |       |
    |   |       |                              |       |
    |   |       |--(3)--  commitment_signed -->|       |
    |   |       |<-(4)--  commitment_signed ---|       |
    |   |   A   |                              |       |
    |   |       |<-(5)--  tx_signatures -------|       |
    |   |       |--(6)--  tx_signatures ------>|       |
    |   |       |                              |       |
    |   |       |--(a)--- tx_init_rbf -------->|       |
    ----|       |<-(b)--- tx_ack_rbf ----------|       |
        |       |                              |       |
        |       |    <tx rbf collaboration>    |       |
        |       |                              |       |
        |       |--(c)--  commitment_signed -->|       |
        |       |<-(d)--  commitment_signed ---|       |
        |       |                              |       |
        |       |<-(e)--  tx_signatures -------|       |
        |       |--(f)--  tx_signatures ------>|       |
        |       |                              |       |
        |       |--(7)--- channel_ready  ----->|       |
        |       |<-(8)--- channel_ready  ------|       |
        +-------+                              +-------+