staticaddr: channel funding with deposits#1040
staticaddr: channel funding with deposits#1040hieblmi wants to merge 8 commits intolightninglabs:masterfrom
Conversation
Summary of ChangesHello @hieblmi, 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 significantly extends the functionality of static addresses by enabling them to be used as a source for funding Lightning channels. It introduces a new Highlights
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. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. 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 introduces a new openchannel subcommand for static addresses, allowing users to fund channels from their deposits. The implementation is comprehensive, covering the command-line interface, RPC definitions, daemon logic, and documentation.
My review focuses on the new cmd/loop/openchannel.go file, where I've identified a few issues related to context handling, input validation, and error wrapping. These are important for ensuring the robustness and maintainability of the new command.
The refactoring to move utility functions into a staticutil package is a great improvement for code organization and reuse. The protocol changes to use PSBT for withdrawals are also a solid enhancement.
Overall, this is a well-structured PR that adds significant functionality. Addressing the feedback will further improve its quality.
hieblmi
force-pushed
the
static-open-channel
branch
4 times, most recently
from
f9b49dc to
9d37fca
Compare
hieblmi
force-pushed
the
static-open-channel
branch
9 times, most recently
from
94f45cc to
375cf47
Compare
hieblmi
force-pushed
the
static-open-channel
branch
9 times, most recently
from
2b9378a to
5b6631d
Compare
|
@gemini-code-assist review |
There was a problem hiding this comment.
Code Review
This pull request introduces a significant new feature: funding channels from static address deposits via a new openchannel subcommand. The changes are extensive, touching the CLI, daemon, RPC definitions, and state management logic. The implementation appears well-structured, reusing existing components from lnd and internal logic where appropriate. I've identified a few issues: one regarding error handling in the CLI, a potential resource leak in the deposit state machine, and a minor typo in a test function name. Overall, this is a solid contribution that adds valuable functionality.
hieblmi
force-pushed
the
static-open-channel
branch
from
5b6631d to
48bb35e
Compare
|
@gemini-code-assist review |
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable new feature, allowing users to open channels funded by static address deposits. The implementation is well-structured, following existing patterns in the codebase and reusing functionality from lnd where appropriate. The new openchannel command is comprehensive, offering a user experience similar to lncli openchannel. The changes to the state machine and RPC definitions are correct and consistent. I have one suggestion regarding test file location to improve maintainability.
| // TestCalculateFundingTxValues tests the calculateFundingTxValaues function | ||
| // with various scenarios. | ||
| func TestCalculateFundingTxValues(t *testing.T) { |
There was a problem hiding this comment.
For better code organization and maintainability, this test for withdraw.CalculateWithdrawalTxValues should be moved to the staticaddr/withdraw package. Since staticaddr/withdraw/manager_test.go does not exist, you could create it for this and future tests related to the withdraw manager.
hieblmi
force-pushed
the
static-open-channel
branch
from
48bb35e to
b671859
Compare
hieblmi
force-pushed
the
static-open-channel
branch
3 times, most recently
from
6083c1d to
ca2fc66
Compare
Make our own type StaticAddressLoopInRequest which has a single field of type lnrpc.OpenChannelRequest. Removed copy-pasted lnrpc types which are needed for OpenChannelRequest.
hieblmi
force-pushed
the
static-open-channel
branch
2 times, most recently
from
e18703f to
68474b0
Compare
hieblmi
force-pushed
the
static-open-channel
branch
from
68474b0 to
0e07e19
Compare
sputn1ck
left a comment
sputn1ck
left a comment
There was a problem hiding this comment.
Review notes (short):
- Any error after PSBT finalize currently transitions deposits back to Deposited. If finalize already handed tx to lnd (NoPublish=false), we can end up reusing spent deposits. Can we gate rollback once finalize is sent or persist txid/reconcile?
- On recover, OpeningChannel just self-loops with no action. If we restart mid-flow, deposits can remain locked forever. Should we reconcile against lnd pending channels or on-chain spends?
- We estimate fee twice when sat_per_vbyte is unset (calc vs PSBT build). Funding amount can be computed with one rate and PSBT built with another. Can we thread a single fee rate through?
- MinConfs is effectively ignored (hard-coded to 1), but checkPsbtFlags only checks !=1/SpendUnconfirmed. Should we validate and reject unsupported MinConfs explicitly before locking deposits?
- SelectDeposits doesn’t account for fees. We lock deposits based only on local_amt + dust, then may fail when fee is applied. Worth a fee-aware selection or pre-check before OnOpeningChannel.
|
|
||
| if req.LocalFundingAmount != 0 { | ||
| deposits, err = staticutil.SelectDeposits( | ||
| deposits, req.LocalFundingAmount, |
There was a problem hiding this comment.
SelectDeposits isn’t fee-aware. We lock deposits based on local_amt + dust, then may fail once fees are applied. Worth a fee-aware selection or pre-check before OnOpeningChannel.
| // are opening the channel. | ||
| err = m.cfg.DepositManager.TransitionDeposits( | ||
| ctx, deposits, deposit.OnOpeningChannel, deposit.OpeningChannel, | ||
| ) |
There was a problem hiding this comment.
Once deposits move to OpeningChannel there’s no recovery path here. On restart, these can stay locked indefinitely unless something else reconciles. Should we reconcile with lnd pending chans / on-chain spends?
| if req.SatPerVbyte == 0 { | ||
| // Get the fee rate for the withdrawal sweep. | ||
| feeRate, err = m.cfg.WalletKit.EstimateFeeRate( | ||
| ctx, defaultConfTarget, |
There was a problem hiding this comment.
We estimate fee rate here, but CreateFinalizedWithdrawalTx estimates again when sat_per_vbyte is unset. That can skew funding amt vs PSBT build. Can we thread a single fee rate through?
| MinHtlcMsat: req.MinHtlcMsat, | ||
| RemoteCsvDelay: req.RemoteCsvDelay, | ||
| MinConfs: defaultUtxoMinConf, | ||
| SpendUnconfirmed: req.SpendUnconfirmed, |
There was a problem hiding this comment.
MinConfs is hard-coded to 1. If caller sets MinConfs !=1, we silently ignore it. Should we validate/reject unsupported MinConfs before locking deposits?
| if err != nil { | ||
| log.Infof("error opening channel: %v", err) | ||
| err2 := m.cfg.DepositManager.TransitionDeposits( | ||
| ctx, deposits, fsm.OnError, deposit.Deposited, |
There was a problem hiding this comment.
Any error after PSBT finalize currently transitions deposits back to Deposited. If finalize already handed the tx to lnd (NoPublish=false), we can reuse spent deposits. Can we gate rollback once finalize is sent or persist txid/reconcile?
3 participants
This PR introduces a
openchannelsubcommand to static addresses.It provides the same experience as
lncli openchannel.Exmples:
Open a channel with all available deposits:
Open a channel with specified local funding amount, coin-selected from available deposits under fee and dust considerations.
Open a channel from two deposits AAA and BBB while taking their combined value(fundmax) as funding amount and considering fees and dust limit.
Open a channel from two deposits AAA and BBB while taking a specified amount(local_amt) as funding amount and considering fees and dust limit.
TODOs: