- 
                Notifications
    You must be signed in to change notification settings 
- Fork 421
Ensure transactions_confirmed is idempotent #1861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure transactions_confirmed is idempotent #1861
Conversation
In the next commit we'll add some checks that redundant transactions aren't confirmed in different blocks, which would cause test_htlc_ignore_latest_remote_commitment to fail. Here we fix it to avoid the issue.
a16d4ca    to
    a005bf0      
    Compare
  
    In `ChannelMonitor`s, when a transaction containing a spend of a revoked remote output reaches 6 confs, we may have no other tracking of that txid remaining. Thus, if we see that transaction again (because a user duplicatively confirms it), we'll generate a redundant spendable output event for it. Here we simply explicitly track all txids of transactions which confirm with a spendable output, allowing us to check this condition in the next commit.
a005bf0    to
    315d120      
    Compare
  
    | Codecov ReportBase: 90.61% // Head: 90.95% // Increases project coverage by  
 
 Additional details and impacted files@@            Coverage Diff             @@
##             main    #1861      +/-   ##
==========================================
+ Coverage   90.61%   90.95%   +0.34%     
==========================================
  Files          90       91       +1     
  Lines       47623    50270    +2647     
  Branches    47623    50270    +2647     
==========================================
+ Hits        43152    45723    +2571     
- Misses       4471     4547      +76     
 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. | 
315d120    to
    a65a816      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, would be ready for the squashing from my side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also LGTM for squash.
In many complexity-reduced implementations of chain syncing using esplora `transactions_confirmed` may be called redundantly for transactions which were already confirmed. To ensure this is idempotent we add two new `ConnectionStyle`s in our tests which (a) call `transactions_confirmed` twice for each call, ensuring simple idempotency is ensured and (b) call `transactions_confirmed` once for each historical block every time we're connecting a new block, ensuring we're fully idempotent even if every call is repeated constantly. In order to actually behave correctly this requires a simple already-confirmed check in `ChannelMonitor`, which is included.
At the end of our `monitor_tests`, which test `ChannelMonitor` `SpendableOutputs` and claimable `Balance`s, add new checks that ensure that, if we're using the new `ConnectStyle::HighlyRedundantTransactionsFirstSkippingBlocks`, we can replay the full chain without getting redundant events or `Balance`s.
a65a816    to
    cd315d5      
    Compare
  
    | Squashed without changes. | 
In many complexity-reduced implementations of chain syncing using
esplora
transactions_confirmedmay be called redundantly fortransactions which were already confirmed. To ensure this is
idempotent we add two new
ConnectionStyles in our tests which(a) call
transactions_confirmedtwice for each call, ensuringsimple idempotency is ensured and (b) call
transactions_confirmedonce for each historical block every time we're connecting a new
block, ensuring we're fully idempotent even if every call is
repeated constantly.
In order to actually behave correctly this requires a simple
already-confirmed check in
ChannelMonitor, which is included.Example #53,637,290 of the old adage "that which isn't tested is broken".