docs: explain rbf cooperative close flow#10749
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request improves the documentation for the RBF (Replace-By-Fee) cooperative close functionality within the Lightning Network daemon. By updating the CLI and RPC documentation, it provides clearer guidance to users and developers on how to properly initiate and bump fees for cooperative channel closures, ensuring that the necessary configuration flags and peer requirements are well-understood. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds documentation for RBF cooperative close fee bumping to the CLI and RPC interfaces. The review feedback focuses on improving the clarity and accuracy of this documentation, specifically by using more appropriate terminology for the CLI context and clarifying the relationship between confirmation targets and fee rates to avoid user confusion.
| RBF cooperative close fee bumping requires starting lnd with | ||
| --protocol.rbf-coop-close enabled and only works if the remote peer also | ||
| supports the protocol. When the initial cooperative close attempt is in | ||
| progress, the same closechannel RPC can be reissued with a higher fee |
There was a problem hiding this comment.
In the context of CLI documentation, it is more appropriate to refer to closechannel as a "command" rather than an "RPC". Users interacting with lncli are executing commands, and the underlying RPC is an implementation detail. This aligns with the goal of maintaining readable and user-friendly documentation.
| progress, the same closechannel RPC can be reissued with a higher fee | |
| progress, the same closechannel command can be reissued with a higher fee |
References
- Readable code is the most important requirement for any commit created. (link)
| RBF cooperative close fee bumping requires starting lnd with | ||
| `--protocol.rbf-coop-close` enabled and only works if the remote peer also | ||
| supports the protocol. While a cooperative close is already in progress, | ||
| callers can reissue CloseChannel with a higher fee target or fee rate to |
There was a problem hiding this comment.
The term "higher fee target" is potentially confusing because a "higher" value for the target_conf field (more blocks) actually results in a lower fee. It would be clearer to use "more aggressive confirmation target" to avoid ambiguity regarding the direction of the value change.
| callers can reissue CloseChannel with a higher fee target or fee rate to | |
| callers can reissue CloseChannel with a more aggressive confirmation target or fee rate to |
| // cooperative close retry, callers can increase this value (or the target | ||
| // fee rate) and reissue CloseChannel to request a higher-fee replacement. |
There was a problem hiding this comment.
The term "target fee rate" is slightly ambiguous as it conflates "confirmation target" and "fee rate". Since this refers to the sat_per_vbyte field, it's better to just use "fee rate". Additionally, mentioning that the confirmation target can also be adjusted provides a more complete picture of the RBF options.
| // cooperative close retry, callers can increase this value (or the target | |
| // fee rate) and reissue CloseChannel to request a higher-fee replacement. | |
| // cooperative close retry, callers can increase this value (or the fee | |
| // rate / confirmation target) and reissue CloseChannel to request a higher-fee replacement. |
github-actions
Bot
added
the
severity-high
|
🟠 PR Severity: HIGH (severity-high)
High severity file (1):
Medium severity file (1):
Analysis: The cmd/commands/commands.go file is CLI client code under cmd/* and is classified as MEDIUM per policy: cmd/* files are always MEDIUM even if the filename references a server-side package name. No severity bump applies: only 2 non-test/non-generated files changed (threshold: >20) and only 18 lines changed (threshold: >500). To override, add a severity-override-{critical,high,medium,low} label. |
|
User spamming the repo with LLM generated prs. |
2 participants
Summary
closechannelcommand and RPC surfaces--protocol.rbf-coop-closerequirement and the peer-support requirementCloseChannelwith a higher fee target or fee rate to request an RBF bump, and whatmax_fee_per_vbytemeans in that flowTesting
git diff --checkCloses #9771