Expand description

Various utilities for building scripts and deriving keys related to channels. These are largely of interest for those implementing chain::keysinterface::Sign message signing by hand.

Structs

A pre-built Bitcoin commitment transaction and its txid.

One counterparty’s public keys which do not change over the life of a channel.

Per-channel data used to build transactions in conjunction with the per-commitment data (CommitmentTransaction). The fields are organized by holder/counterparty.

This class tracks the per-transaction information needed to build a closing transaction and will actually build it and sign.

This class tracks the per-transaction information needed to build a commitment transaction and will actually build it and sign. It is used for holder transactions that we sign only when needed and for transactions we sign for the counterparty.

Late-bound per-channel counterparty data used to build transactions.

Implements the per-commitment secret storage scheme from BOLT 3.

Static channel fields used to build transactions given per-commitment fields, organized by broadcaster/countersignatory.

Information about an HTLC as it appears in a commitment transaction

Information needed to build and sign a holder’s commitment transaction.

A wrapper on ClosingTransaction indicating that the built bitcoin transaction is trusted.

A wrapper on CommitmentTransaction indicating that the derived fields (the built bitcoin transaction and the transaction creation keys) are trusted.

The set of public keys which are used in the creation of one commitment transaction. These are derived from the channel base keys and per-commitment data.

Constants

The maximum length of a script returned by get_revokeable_redeemscript.

Functions

Build a closing transaction

Build the commitment secret from the seed and the commitment number

Builds an unsigned HTLC-Success or HTLC-Timeout transaction from the given channel and HTLC parameters. This is used by TrustedCommitmentTransaction::get_htlc_sigs to fetch the transaction which needs signing, and can be used to construct an HTLC transaction which is broadcastable given a counterparty HTLC signature.

Derives a per-commitment-transaction private key (eg an htlc key or delayed_payment key) from the base secret and the per_commitment_point.

Derives a per-commitment-transaction revocation key from its constituent parts.

Derives a per-commitment-transaction public key (eg an htlc key or a delayed_payment key) from the base point and the per_commitment_key. This is the public equivalent of derive_private_key - using only public keys to derive a public key instead of private keys.

Derives a per-commitment-transaction revocation public key from its constituent parts. This is the public equivalend of derive_private_revocation_key - using only public keys to derive a public key instead of private keys.

Gets the witnessScript for an anchor output from the funding public key. The witness in the spending input must be: <BIP 143 funding_signature> After 16 blocks of confirmation, an alternative satisfying witness could be: <> (empty vector required to satisfy compliance with MINIMALIF-standard rule)

Commitment transaction numbers which appear in the transactions themselves are XOR’d with a shared secret first. This prevents on-chain observers from discovering how many commitment transactions occurred in a channel before it was closed.

Gets the witness redeemscript for an HTLC output in a commitment transaction. Note that htlc does not need to have its previous_output_index filled.

A script either spendable by the revocation key or the broadcaster_delayed_payment_key and satisfying the relative-locktime OP_CSV constrain. Encumbering a to_holder output on a commitment transaction or 2nd-stage HTLC transactions.

Gets the weight for an HTLC-Success transaction.

Gets the weight for an HTLC-Timeout transaction.

Gets the redeemscript for a funding output from the two funding public keys. Note that the order of funding public keys does not matter.