Indicates an error on the client's part ( usually some variant of attempting to use too-low or too high values)

Optional Channel limits which are applied during channel creation. These limits are only applied to our counterparty's limits, not our own

see bolt2 for the detail. This is mainly used when the channel funding tx is not confirmed in to the blockchain. After confirmation, ShortChannelId is used

Set of lightning keys needed to operate a channel as describe in BOLT 3

set of static pubkeys for each channel. corresponds to ChannelPrivKeys in case of our own keys.

48-bit incrementing counter for each commitment transaction This is set to commitment tx locktime (in obscured form), see bolt03-transactions for more detail.

set of pubkeys which get rotated for every commitment in the channel. Generated from ChannelPubKeys and PerCommitmentPoint

Seed to generate all other PerCommitmentSecret. The generation algorithm is described in bolt03

elliptic curve point (a.k.a. pubkey) to derive [remote|local]_delayedpubkey. This is static for each channel and it is negotiated during channel opening. We don't want to use same pubkeys for each commitments more than once, so the key derivation needs new PerCommitmentPoint for each HTLCs. see bolt03 for more detail.

secret which corresponds to DelayedPaymentBasepoint This is not part of the p2p msg, and it must be kept secret for whole channel lifetime.

The private key which corresponds to DelayedPaymentPubKey.

The pubkey used for to_self output in htlc-success/htlc-timeout tx.

Type wrapper to annotate that this privkey corresponds to the pubkey which is locking the funding txo.

Type wrapper to annotate that this pubkey is used for locking the funding txo with 2-of-2 multisig. Which is exchanged in open_channel to create funding tx.

Heap is an ordered linear structure where the ordering is ascending or descending. "head" inspects the first element in the ordering, "tail" takes the remaining structure after head, and "insert" places elements within the ordering. PriorityQueue is available as an alternate interface. According to Okasaki the time complexity of the heap functions in this Heap implementation (based on the "pairing" heap) have resisted time complexity analysis.

elliptic curve point (a.k.a. pubkey) to derive [remote|local]_htlcpubkey. This is static for each channel and it is negotiated during channel opening. We don't want to use same pubkeys for each commitments more than once, so the key derivation needs new PerCommitmentPoint for each HTLCs. see bolt03 for more detail.

secret which corresponds to DelayedPaymentBasepoint This is not part of the p2p msg, and it must be kept secret for whole channel lifetime.

The private key which corresponds to HtlcPubKey.

The pubkey used in htlc output to ensure that no one else other than the 2-party can have chance to claim the htlc.

Based on FSharpx's PriorityQueue refs: https://github.com/fsprojects/FSharpx.Collections/blob/master/src/FSharpx.Collections/PriorityQueue.fs

Port from LightMoney class in BTCPayServer.Lightning Represents millisatoshi amount of money

This is the node-wide master key which is also used for transport-level encryption. The channel's keys can be derived from this via BIP32 key derivation. It is basically NodeSecret + "ChainCode (an entropy for deriving the children)"

Private key which corresponds to NodeId 1-by-1. Which is necessary for ECDH key exchange for transport encryption.

An actual value set to commitment tx locktime.

TODO: rename?

elliptic curve point (a.k.a. pubkey) to derive remotepubkey. This is static for each channel and it is negotiated during channel opening. We don't want to use same pubkeys for each commitments more than once, so the key derivation needs new PerCommitmentPoint for each HTLCs. see bolt03 for more detail.

In case of option_static_remotekey feature bit is negotiated, this corresponds to remotepubkey which the public key that counterparty gets paid to when the channel closes.

secret which corresponds to PaymentBasepoint This is not part of the p2p msg, and it must be kept secret for whole channel lifetime.

Private key corresponds to PaymentPubKey. Usually not part of the p2p messaging. and it is only for spending the funds after channel closure.

The pubkey for to_local or to_remote output scriptpubkey. Usually rotated for each new HTLC, but it corresponds directly to PaymentBasepoint in case that option_static_remotekey feature bit is negotiated. Thus static for whole channel lifetime.

Instead of sending actual pubkeys necessary for commitment, Lighting Nodes send per_commitment_point for each commitment which enables to derive all other pubkeys. This is a type to annotate such commitment point, an actual value is elliptic curve point (a.k.a. public key).

per_commitment_secret in bolt. By revealing this value to counterparty, you can revoke the commitment. And thus complete the state transition in LN channel.

Type wrapper for revocation_basepoint. Which is exchange in channel creation, and used later to create revocationpubkey see bolt03 For the detail.

The secret which corresponds to RevocationBasepoint.

Privkey corresponds to RevocationPubKey. Which is necessary in a dirty-close (that is, when the counterparty tries to cheat by publishing an old commitment tx.) This can be derived from PerCommitmentSecret, thus your node doesn't have to remember this. Instead, use PerCommitmentSecretStore to remember PerCommitmentSecret and derive this from it.

PubKey which is necessary for each new commitment tx. Which can be derived from RevocationBasepoint and PerCommitmentPoint The corresponding privkey (i.e. RevocationPrivKey) can be derived when The counterparty reveals the per_commitment_secret Thus ensures the revocation Of the commitment. (Which is a crucial step for LN payment.) See bolt03 For more detail.

This should not exceed 20 (as a protocol rule).

A hop in route

Configuration for router module.

A SeqParser is a parser for sequences. It wraps a function which takes a sequence and optionally returns a value successfully-parsed from the start of the sequence along with the rest of the sequence. If parsing fails it returns None.

You can construct a SeqParser using the seqParser computation expression. The bind operation of the computation expression will return the value parsed from the sequence and advance the sequence to the position where the next value can be parsed from. For example, given a parser parseValue, you can construct a parser which parses three values like this:

1: 
2: 
3: 
4: 
5: 
6: 

seqParser {
   let! value0 = parseValue()
   let! value1 = parseValue()
   let! value2 = parseValue()
   return (value0, value1, value2)
}

You can also call SeqParser.next and SeqParser.abort from within a seqParser to pop the next element of the sequence or to abort parsing respectively.

The function SeqParser.parseToCompletion takes a sequence and a SeqParser and will attempt to parse the sequence to completion.

Simple wrapper type for transaction id. Its only purpose is to annotate the inner hash is a txid and nothing else

Integral type to represent the commitment number. The commitment number is a number set to commitment tx locktime (in obscured form), see bolt03-transactions for more detail.