fr.acinq.eclair.channel.Helpers
Closing
Related Doc:
package Helpers
Claim all the HTLCs that we've received from our current commit tx.
Claim all the HTLCs that we've received from our current commit tx. This will be done using 2nd stage HTLC transactions
our commitment data, which include payment preimages
a list of transactions (one per HTLC that we can claim)
Claim our Main output only
Claim our Main output only
either our current commitment data in case of usual remote uncooperative closing or our outdated commitment data in case of data loss protection procedure; in any case it is used only to get some constant parameters, not commitment data
the remote perCommitmentPoint corresponding to this commitment
the remote commitment transaction that has just been published
a list of transactions (one per HTLC that we can claim)
Claim all the HTLCs that we've received from their current commit tx
Claim all the HTLCs that we've received from their current commit tx
our commitment data, which include payment preimages
the remote commitment data to use to claim outputs (it can be their current or next commitment)
the remote commitment transaction that has just been published
a list of transactions (one per HTLC that we can claim)
Claims the output of an HtlcSuccessTx or HtlcTimeoutTx transaction using a revocation key.
Claims the output of an HtlcSuccessTx or HtlcTimeoutTx transaction using a revocation key.
In case a revoked commitment with pending HTLCs is published, there are two ways the HTLC outputs can be taken as punishment: - by spending the corresponding output of the commitment tx, using HtlcPenaltyTx that we generate as soon as we detect that a revoked commit as been spent; note that those transactions will compete with HtlcSuccessTx and HtlcTimeoutTx published by the counterparty. - by spending the delayed output of HtlcSuccessTx and HtlcTimeoutTx if those get confirmed; because the output of these txes is protected by an OP_CSV delay, we will have time to spend them with a revocation key. In that case, we generate the spending transactions "on demand", this is the purpose of this method.
When an unexpected transaction spending the funding tx is detected: 1) we find out if the published transaction is one of remote's revoked txs 2) and then: a) if it is a revoked tx we build a set of transactions that will punish them by stealing all their funds b) otherwise there is nothing we can do
When an unexpected transaction spending the funding tx is detected: 1) we find out if the published transaction is one of remote's revoked txs 2) and then: a) if it is a revoked tx we build a set of transactions that will punish them by stealing all their funds b) otherwise there is nothing we can do
a RevokedCommitPublished object containing penalty transactions if the tx is a revoked commitment
In CLOSING state, any time we see a new transaction, we try to extract a preimage from it in order to fulfill the corresponding incoming htlc in an upstream channel.
In CLOSING state, any time we see a new transaction, we try to extract a preimage from it in order to fulfill the corresponding incoming htlc in an upstream channel.
Not doing that would result in us losing money, because the downstream node would pull money from one side, and the upstream node would get refunded after a timeout.
a set of pairs (add, fulfills) if extraction was successful:
This helper function tells if the utxo consumed by the given transaction has already been irrevocably spent (possibly by this very transaction)
This helper function tells if the utxo consumed by the given transaction has already been irrevocably spent (possibly by this very transaction)
It can be useful to:
a tx with only one input
a map of known spent outpoints
true if we know for sure that the utxos consumed by the tx have already irrevocably been spent, false otherwise
Checks if a channel is closed (i.e.
Checks if a channel is closed (i.e. its closing tx has been confirmed)
channel state data
additional confirmed transaction; we need this for the mutual close scenario because we don't store the closing tx in the channel state
the channel closing type, if applicable
As soon as a tx spending the funding tx has reached min_depth, we know what the closing type will be, before the whole closing process finishes(e.g.
As soon as a tx spending the funding tx has reached min_depth, we know what the closing type will be, before the whole closing process finishes(e.g. there may still be delayed or unconfirmed child transactions). It can save us from attempting to publish some transactions.
Note that we can't tell for mutual close before it is already final, because only one tx needs to be confirmed.
channel state data
the channel closing type, if applicable
A local commit is considered done when: - all commitment tx outputs that we can spend have been spent and confirmed (even if the spending tx was not ours) - all 3rd stage txes (txes spending htlc txes) have been confirmed
A remote commit is considered done when all commitment tx outputs that we can spend have been spent and confirmed (even if the spending tx was not ours).
A remote commit is considered done when all commitment tx outputs that we can spend have been spent and confirmed (even if the spending tx was not ours).
This helper function returns the fee paid by the given transaction.
This helper function returns the fee paid by the given transaction.
It relies on the current channel data to find the parent tx and compute the fee, and also provides a description.
a tx for which we want to compute the fee
current channel data
if the parent tx is found, a tuple (fee, description)
Indicates whether local has anything at stake in this channel
Indicates whether local has anything at stake in this channel
true if channel was never open, or got closed immediately, had never any htlcs and local never had a positive balance
As soon as a local or remote commitment reaches min_depth, we know which htlcs will be settled on-chain (whether or not they actually have an output in the commitment tx).
As soon as a local or remote commitment reaches min_depth, we know which htlcs will be settled on-chain (whether or not they actually have an output in the commitment tx).
a transaction that is sufficiently buried in the blockchain
If a local commitment tx reaches min_depth, we need to fail the outgoing htlcs that only us had signed, because they will never reach the blockchain.
If a local commitment tx reaches min_depth, we need to fail the outgoing htlcs that only us had signed, because they will never reach the blockchain.
Those are only present in the remote's commitment.
In CLOSING state, when we are notified that a transaction has been confirmed, we analyze it to find out if one or more htlcs have timed out and need to be failed in an upstream channel.
In CLOSING state, when we are notified that a transaction has been confirmed, we analyze it to find out if one or more htlcs have timed out and need to be failed in an upstream channel.
a tx that has reached mindepth
a set of htlcs that need to be failed upstream
In CLOSING state, when we are notified that a transaction has been confirmed, we analyze it to find out if one or more htlcs have timed out and need to be failed in an upstream channel.
In CLOSING state, when we are notified that a transaction has been confirmed, we analyze it to find out if one or more htlcs have timed out and need to be failed in an upstream channel.
a tx that has reached mindepth
a set of htlcs that need to be failed upstream
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the local commit scenario and keep track of it.
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the local commit scenario and keep track of it.
We need to keep track of all transactions spending the outputs of the commitment tx, because some outputs can be spent both by us and our counterparty. Because of that, some of our transactions may never confirm and we don't want to wait forever before declaring that the channel is CLOSED.
a transaction that has been irrevocably confirmed
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the remote commit scenario and keep track of it.
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the remote commit scenario and keep track of it.
We need to keep track of all transactions spending the outputs of the commitment tx, because some outputs can be spent both by us and our counterparty. Because of that, some of our transactions may never confirm and we don't want to wait forever before declaring that the channel is CLOSED.
a transaction that has been irrevocably confirmed
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the revoked commit scenario and keep track of it.
In CLOSING state, when we are notified that a transaction has been confirmed, we check if this tx belongs in the revoked commit scenario and keep track of it.
We need to keep track of all transactions spending the outputs of the commitment tx, because some outputs can be spent both by us and our counterparty. Because of that, some of our transactions may never confirm and we don't want to wait forever before declaring that the channel is CLOSED.
a transaction that has been irrevocably confirmed