Add payment hash to ClaimHtlcSuccessTx
#2101
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pm47
reviewed
Dec 14, 2021
eclair-core/src/main/scala/fr/acinq/eclair/wire/internal/channel/version0/ChannelCodecs0.scala
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## master #2101 +/- ##
==========================================
+ Coverage 87.57% 87.61% +0.04%
==========================================
Files 165 165
Lines 12757 12761 +4
Branches 543 538 -5
==========================================
+ Hits 11172 11181 +9
+ Misses 1585 1580 -5
|
pm47
reviewed
Dec 14, 2021
eclair-core/src/main/scala/fr/acinq/eclair/transactions/Transactions.scala
Show resolved
Hide resolved
This can be useful to match a preimage to a given claim-htlc-success transaction without going through the process of re-creating the transaction from scratch. We already include the payment hash in htlc-success transactions for that reason.
This ensures we handle the case where the payment hash is missing, and the compiler will help us enforce it.
t-bast
force-pushed
the
claim-htlc-success-payment-hash
branch
from
83029b0 to
4dbbca7
Compare
pm47
approved these changes
Dec 16, 2021
t-bast
added a commit
that referenced
this pull request
Apr 24, 2025
We have this legacy class in the `ClaimHtlcTx` hierarchy for legacy cases that didn't store the `paymentHash` with the transaction. This was introduced to ensure that nodes who upgraded while a force-close was happening would still be able to finish force-closing the channel and get their funds back. This was introduced in #2101 which was released in eclair v0.7.0 on 01/02/2022. Since we've made several important bug fixes since then, it should be safe to assume that we don't care about node operators who update from this very old version while a channel is closing, the remote commit got confirmed, and some HTLCs must be claimed with the preimage on-chain.
t-bast
added a commit
that referenced
this pull request
Apr 25, 2025
We have this legacy class in the `ClaimHtlcTx` hierarchy for legacy cases that didn't store the `paymentHash` with the transaction. This was introduced to ensure that nodes who upgraded while a force-close was happening would still be able to finish force-closing the channel and get their funds back. This was introduced in #2101 which was released in eclair v0.7.0 on 01/02/2022. Since we've made several important bug fixes since then, it should be safe to assume that we don't care about node operators who update from this very old version while a channel is closing, the remote commit got confirmed, and some HTLCs must be claimed with the preimage on-chain.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This can be useful to match a preimage to a given
claim-htlc-successtransaction without going through the process of re-creating the transaction from scratch.We already include the payment hash in
htlc-successtransactions for that reason.Fortunately our codecs system is now very flexible: this was prefixed with a type, so we can easily decode old data and encode with the new codec. Code that depends on this will need to explicitly handle the case where
paymentHash == ByteVector32.Zeroes.This shouldn't be a an issue in practice though: these transactions are re-generated when calling
handleRemoteSpentCurrentwhich happens when nodes restart as we replayWatchFundingSpent, so we should always have the payment hash available.