Transactions
- Source:
- Transactions.scala
Type members
Classlikes
Commitment format that adds anchor outputs to the commitment transaction and uses custom sighash flags for HTLC transactions to allow unilateral fee bumping (https://github.com/lightningnetwork/lightning-rfc/pull/688).
Commitment format that adds anchor outputs to the commitment transaction and uses custom sighash flags for HTLC transactions to allow unilateral fee bumping (https://github.com/lightningnetwork/lightning-rfc/pull/688).
- Companion:
- object
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
Represent a link between a commitment spec item (to-local, to-remote, anchors, htlc) and the actual output in the commit tx
Represent a link between a commitment spec item (to-local, to-remote, anchors, htlc) and the actual output in the commit tx
- Value parameters:
- commitmentOutput
commitment spec item this output is built from
- output
transaction output
- redeemScript
redeem script that matches this output (most of them are p2wsh)
- Companion:
- object
- Source:
- Transactions.scala
Commitment format as defined in the v1.0 specification (https://github.com/lightningnetwork/lightning-rfc/tree/v1.0).
Commitment format as defined in the v1.0 specification (https://github.com/lightningnetwork/lightning-rfc/tree/v1.0).
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
It's important to note that htlc transactions with the default commitment format are not actually replaceable: only anchor outputs htlc transactions are replaceable. We should have used different types for these different kinds of htlc transactions, but we introduced that before implementing the replacement strategy. Unfortunately, if we wanted to change that, we would have to update the codecs and implement a migration of channel data, which isn't trivial, so we chose to temporarily live with that inconsistency (and have the transaction replacement logic abort when non-anchor outputs htlc transactions are provided). Ideally, we'd like to implement a dynamic commitment format upgrade mechanism and depreciate the pre-anchor outputs format soon, which will get rid of this inconsistency. The next time we introduce a new type of commitment, we should avoid repeating that mistake and define separate types right from the start.
It's important to note that htlc transactions with the default commitment format are not actually replaceable: only anchor outputs htlc transactions are replaceable. We should have used different types for these different kinds of htlc transactions, but we introduced that before implementing the replacement strategy. Unfortunately, if we wanted to change that, we would have to update the codecs and implement a migration of channel data, which isn't trivial, so we chose to temporarily live with that inconsistency (and have the transaction replacement logic abort when non-anchor outputs htlc transactions are provided). Ideally, we'd like to implement a dynamic commitment format upgrade mechanism and depreciate the pre-anchor outputs format soon, which will get rid of this inconsistency. The next time we introduce a new type of commitment, we should avoid repeating that mistake and define separate types right from the start.
- Source:
- Transactions.scala
- Source:
- Transactions.scala
Owner of a given transaction (local/remote).
Owner of a given transaction (local/remote).
- Companion:
- object
- Source:
- Transactions.scala
This commitment format may be unsafe where you're fundee, as it exposes you to a fee inflating attack. Don't use this commitment format unless you know what you're doing! See https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html for details.
This commitment format may be unsafe where you're fundee, as it exposes you to a fee inflating attack. Don't use this commitment format unless you know what you're doing! See https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html for details.
- Source:
- Transactions.scala
This commitment format removes the fees from the pre-signed 2nd-stage htlc transactions to fix the fee inflating attack against UnsafeLegacyAnchorOutputsCommitmentFormat.
This commitment format removes the fees from the pre-signed 2nd-stage htlc transactions to fix the fee inflating attack against UnsafeLegacyAnchorOutputsCommitmentFormat.
- Source:
- Transactions.scala
Types
Type alias for a collection of commitment output links
Type alias for a collection of commitment output links
- Source:
- Transactions.scala
Value members
Concrete methods
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
Fee paid by the commit tx (depends on which HTLCs will be trimmed).
Fee paid by the commit tx (depends on which HTLCs will be trimmed).
- Source:
- Transactions.scala
- Source:
- Transactions.scala
While on-chain amounts are generally computed in Satoshis (since this is the smallest on-chain unit), it may be useful in some cases to calculate it in MilliSatoshi to avoid rounding issues. If you are adding multiple fees together for example, you should always add them in MilliSatoshi and then round down to Satoshi.
While on-chain amounts are generally computed in Satoshis (since this is the smallest on-chain unit), it may be useful in some cases to calculate it in MilliSatoshi to avoid rounding issues. If you are adding multiple fees together for example, you should always add them in MilliSatoshi and then round down to Satoshi.
- Source:
- Transactions.scala
This is a trick to split and encode a 48-bit txnumber into the sequence and locktime fields of a tx
This is a trick to split and encode a 48-bit txnumber into the sequence and locktime fields of a tx
- Value parameters:
- txnumber
commitment number
- Returns:
(sequence, locktime)
- Source:
- Transactions.scala
- Value parameters:
- fee
tx fee
- weight
tx weight
- Returns:
the fee rate (in Satoshi/Kw) for this tx
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Value parameters:
- commitTx
commit tx
- isInitiator
true if local node initiated the channel open
- localPaymentBasePoint
local payment base point
- remotePaymentBasePoint
remote payment base point
- Returns:
the actual commit tx number that was blinded and stored in locktime and sequence fields
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
We already have the redeemScript, no need to build it
We already have the redeemScript, no need to build it
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Value parameters:
- commitTxNumber
commit tx number
- isInitiator
true if local node initiated the channel open
- localPaymentBasePoint
local payment base point
- remotePaymentBasePoint
remote payment base point
- Returns:
the obscured tx number as defined in BOLT #3 (a 48 bits integer)
- Source:
- Transactions.scala
Offered HTLCs below this amount will be trimmed.
Offered HTLCs below this amount will be trimmed.
- Source:
- Transactions.scala
- Source:
- Transactions.scala
Received HTLCs below this amount will be trimmed.
Received HTLCs below this amount will be trimmed.
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
- Source:
- Transactions.scala
Concrete fields
Default public key used for fee estimation
Default public key used for fee estimation
- Source:
- Transactions.scala
This default sig takes 72B when encoded in DER (incl. 1B for the trailing sig hash), it is used for fee estimation It is 72 bytes because our signatures are normalized (low-s) and will take up 72 bytes at most in DER format
This default sig takes 72B when encoded in DER (incl. 1B for the trailing sig hash), it is used for fee estimation It is 72 bytes because our signatures are normalized (low-s) and will take up 72 bytes at most in DER format
- Source:
- Transactions.scala
these values are specific to us (not defined in the specification) and used to estimate fees
these values are specific to us (not defined in the specification) and used to estimate fees
- Source:
- Transactions.scala