Skip to content
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

[7/5]contractcourt: make use of the new sweeper params #8514

Merged

Conversation

yyforyongyu
Copy link
Collaborator

@yyforyongyu yyforyongyu commented Mar 2, 2024

Decided to open this final PR that makes use of the new sweeper params, so we can focus on deciding the proper deadlines and budgets to be used here.

TODO: add detailed docs here.

Depends on,


This change is Reviewable

Copy link
Contributor

coderabbitai bot commented Mar 2, 2024

Important

Auto Review Skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository.

To trigger a single review, invoke the @coderabbitai review command.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@saubyk saubyk added this to the v0.18.0 milestone Mar 3, 2024
@yyforyongyu yyforyongyu marked this pull request as ready for review March 19, 2024 04:59
@yyforyongyu yyforyongyu force-pushed the arbitrator-use-sweeper branch 2 times, most recently from cf30795 to 43fa9fa Compare March 20, 2024 09:33
@yyforyongyu yyforyongyu changed the base branch from elle-sweeper-fee-bump to master March 20, 2024 09:33
@yyforyongyu yyforyongyu changed the base branch from master to elle-sweeper-fee-bump March 20, 2024 09:34
@yyforyongyu yyforyongyu force-pushed the elle-sweeper-fee-bump branch 2 times, most recently from 4e5cfb8 to f420f90 Compare March 20, 2024 10:56
@yyforyongyu yyforyongyu force-pushed the arbitrator-use-sweeper branch 2 times, most recently from 3a6b9e4 to 8bbadc1 Compare March 21, 2024 02:19
@yyforyongyu yyforyongyu force-pushed the elle-sweeper-fee-bump branch 2 times, most recently from 39bdd14 to 6280f73 Compare March 21, 2024 06:31
@yyforyongyu yyforyongyu force-pushed the arbitrator-use-sweeper branch 2 times, most recently from 0ed10be to 3f47dde Compare March 21, 2024 12:35
@yyforyongyu yyforyongyu changed the base branch from elle-sweeper-fee-bump to elle-sweeper-finalize March 25, 2024 13:00
@yyforyongyu yyforyongyu changed the title [6/5]contractcourt: make use of the new sweeper params [7/5]contractcourt: make use of the new sweeper params Mar 25, 2024
This commit removes the method `CreateSweepTx` and makes sure when
sweeping the htlc output via the direct-preimage spend, it's offered via
the `SweepInput` interface.
Previously we don't allow confTarget to be 0, which ended up the final
position being never reached. We fix it here by allowing confTarget to
be 0 in case the deadline has already been passed for a given input.
This commit adds a new config method `QueryIncomingCircuit` that can be
used to query the payment's incoming circuit for giving its outgoing
circuit key.
This commit moves the offering of second-level outputs one block
earlier. The sweeper will check the required locktime and wait until it
matures. This is needed so the second-level outputs can be aggregated
properly.
If anything happens during the fee bumping process, and causes the input
to be failed, we should be able to mark it as `PublishFailed`.
This commit adds an itest case that focuses on validating the CPFP logic
in anchor sweeping.
@yyforyongyu yyforyongyu force-pushed the arbitrator-use-sweeper branch 2 times, most recently from 0f530eb to 8d55db8 Compare April 12, 2024 17:59
The old commitment deadline is removed as it's no longer relevant.
This commit adds a new check for neutrino backend - when the inputs in
the sweeping tx are spent by a third party, we will send back a
`TxFailed` event to free the rest of the inputs for re-grouping.
Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🫡

@Roasbeef Roasbeef merged this pull request into lightningnetwork:elle-new-sweeper Apr 12, 2024
19 of 27 checks passed
@yyforyongyu yyforyongyu deleted the arbitrator-use-sweeper branch April 13, 2024 06:44
Copy link
Collaborator

@ziggie1984 ziggie1984 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fwiw still left some comments.

Comment on lines +62 to +51
if s.NoDeadlineConfTarget < 144 {
return fmt.Errorf("nodeadlineconftarget must be at least 144")
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to have the limit not restricted. One argument for having a limit is that eventually we want to have this outputs confirmed. I was just referring to the fact, that all non-timesenstive-funds can always be recovered even if the node crashes and only the chanbackup is available.

; fees when sweeping it.
; sweeper.budget.tolocalratio=0.5

; The amount in satoshis to allocate as the budget to pay fees when CPFPing a
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it might be more intuitive, we only CPFP if there are HTLCs at risk, so I thought it would make sense to just use their budget limit as a Cap ?

Comment on lines +1737 to +1788
// TODO(yy): If there's no corresponding incoming HTLC, it
// means we are the first hop, hence the payer. This is a
// tricky case - unlike a forwarding hop, we don't have an
// incoming HTLC that will time out, which means as long as we
// can learn the preimage, we can settle the invoice (before it
// expires?).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, but how would we cancel the htlc from the commitment as a sender ?

c.cfg.ChanPoint, deadline, deadlineMinHeight, heightHint)
// Calculate the value left after subtracting the budget used for
// sweeping the time-sensitive HTLCs.
valueLeft := totalValue - calculateBudget(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so I was thinking that the buget value would cap a specific htlc rather than be considered as bundling all htlcs together and then considering the budget. I suggested taking every htlc separately into account and calculating the remaining value for every htlc with a single DeadlineHTLC , and then summing up the values for the remaining amount..

c.cfg.Budget.DeadlineHTLC,
)

log.Debugf("ChannelArbitrator(%v): calculated valueLeft=%v, "+
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Can we explain this value valueLeft or maybe substitute it for the difference htlcamt-budget, otherwise I find it very hard to reason about it when reading the logs.

Comment on lines +1355 to +1373
budget := calculateBudget(
value, c.cfg.Budget.AnchorCPFPRatio,
c.cfg.Budget.AnchorCPFP,
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok understand, so I think capping the anchors is good. Wdyt about calculating the value under protection by considering every htlc separately. Lets say you have 2 0.2 BTC HTLCs on a 1 BTC channel with the HTLC_Budget_Cap 0.1 and a ratio of 50%. The left value would be: 0.4*0.5 = 0.2BTC, capped at 0.1BTC. So it suggests that the budget is only 0.1, tho when sweeping the htlcs, a budget of 0.1 each will be used for every htlc separately so the real budget would be 0.2BTC.

@@ -349,6 +349,25 @@ func (h *htlcSuccessResolver) broadcastReSignedSuccessTx() (
"height %v", h, h.htlc.RHash[:], waitHeight)
}

// Deduct one block so this input is offered to the sweeper one block
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still needed I guess although we force sweeps now ?

// The above mined block will trigger Carol's sweeper to publish the
// anchor sweeping tx.
//
// TODO(yy): should instead cancel the broadcast of the anchor sweeping
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure whether I understand this TODO correctly, we cannot remove the anchor-cpfp, so you want to RBF the wallet input it consumes ?


// Do a non-blocking read to see if the output has been spent.
select {
case spend, ok := <-spendEvent.Spend:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the time lacking in the RegisterSpendNtfn rescan logic could cause problems here during restarts here?

contractcourt/commit_sweep_resolver.go Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants