staticaddr: channel funding with deposits#1040
staticaddr: channel funding with deposits#1040hieblmi wants to merge 17 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 |
hieblmi
force-pushed
the
static-open-channel
branch
5 times, most recently
from
d2d2a88 to
ffa9e9e
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.
Block-based deposit fetching from the internal lnd wallet was susceptible to wallet syncing issues. Replace it with interval-based polling. Reconciliation errors are now logged instead of being fatal, improving resilience during transient failures.
hieblmi
force-pushed
the
static-open-channel
branch
from
ffa9e9e to
75a263b
Compare
|
Hi @sputn1ck, I addressed some more findings, namely:
|
| err = m.cfg.DepositManager.TransitionDeposits( | ||
| ctx, deposits, deposit.OnChannelPublished, | ||
| deposit.ChannelPublished, | ||
| ) | ||
| if err != nil { | ||
| log.Errorf("error transitioning deposits to "+ | ||
| "ChannelPublished: %v", err) | ||
| } |
There was a problem hiding this comment.
TransitionDeposits errors are logged but the function still returns success, leaving deposits stuck in OpeningChannel while the channel is actually pending. This should be returned to the caller or retried.
There was a problem hiding this comment.
The current approach is to just log the transition error and return the chanOutpoint since the transition error might be a recurring error that isn't solved without intervention.
So the approach is to reconcile these OpeningChannel states after a restart in recoverOpeningChannelDeposits.
There was a problem hiding this comment.
What do we do with TransitionDeposits errors? Can we retry TransitionDeposits several times and if it still fails, run recoverOpeningChannelDeposits? And if it also fails, return hard error.
Which errors TransitionDeposits can return? Don't we hide anything important when skipping the errors?
Protect the shimPending variable with a sync.Mutex since it is accessed from multiple goroutines: the main loop goroutine and the server error handling goroutine. Without synchronization this is a data race.
Return an error instead of just logging when chainhash.NewHash fails in the ChanPending handler. The hash variable would be nil and crash on the subsequent String() call.
…ublished Both OpeningChannel and ChannelPublished lacked OnExpiry transitions. handleBlockNotification fires OnExpiry on every new block once the deposit is expired, regardless of the current state. Since both states use NoOpAction or FinalizeDepositAction which release the FSM mutex briefly, an OnExpiry SendEvent can sneak in. Add self-transitions so the event is safely absorbed.
Duplicate outpoints in the request lead to fee miscalculation and an invalid PSBT with the same input listed twice. Validate early and return a clear error message.
Remove unreachable error check after filterNewDeposits which does not return an error. The err variable was already handled from the ListUnspent call above and could never be non-nil at this point.
If the PSBT finalize step succeeds but the stream fails before ChanPending, deposits would remain stuck in OpeningChannel until the next daemon restart. Run the recovery logic immediately so deposits are resolved without requiring a restart.
Add tests for the following edge cases requested in review: - Reorg: channel tx reorged, UTXOs reappear as unspent, deposits return to Deposited state. - Daemon restart during channel opening: deposits in OpeningChannel recovered based on UTXO status (spent → ChannelPublished, unspent → Deposited). - Mempool eviction: tx evicted, UTXOs unspent, deposits return to Deposited. - Mempool rejection: tx never accepted, same recovery as eviction. - Stream errors: lnd stream fails before PSBT finalize, error returned without errPsbtFinalized so deposits can be safely rolled back. - PSBT finalize then stream abort: finalize succeeds but stream dies before ChanPending, error wrapped with errPsbtFinalized so caller triggers recovery instead of blind rollback. - Duplicate outpoints: already covered by TestOpenChannelDuplicateOutpoints.
Change StaticOpenChannelResponse to return channel_open_outpoint in "txid:index" format instead of just the tx hash. This includes the output index so callers don't have to guess it, which is important for potential future batch opens.
hieblmi
force-pushed
the
static-open-channel
branch
from
75a263b to
f345933
Compare
| openChanRequest := &lnrpc.OpenChannelRequest{ | ||
| NodePubkey: req.NodePubkey, | ||
| LocalFundingAmount: int64(chanFundingAmt), | ||
| PushSat: req.PushSat, | ||
| Private: req.Private, | ||
| MinHtlcMsat: req.MinHtlcMsat, | ||
| RemoteCsvDelay: req.RemoteCsvDelay, | ||
| MinConfs: defaultUtxoMinConf, | ||
| SpendUnconfirmed: false, | ||
| CloseAddress: req.CloseAddress, | ||
| RemoteMaxValueInFlightMsat: req.RemoteMaxValueInFlightMsat, | ||
| RemoteMaxHtlcs: req.RemoteMaxHtlcs, | ||
| MaxLocalCsv: req.MaxLocalCsv, | ||
| CommitmentType: chanCommitmentType, | ||
| ZeroConf: req.ZeroConf, | ||
| ScidAlias: req.ScidAlias, | ||
| BaseFee: req.BaseFee, | ||
| FeeRate: req.FeeRate, | ||
| UseBaseFee: req.UseBaseFee, | ||
| UseFeeRate: req.UseFeeRate, | ||
| RemoteChanReserveSat: req.RemoteChanReserveSat, | ||
| Memo: req.Memo, | ||
| } |
There was a problem hiding this comment.
Most of the fields are copied from req.
Could we just clone req and then adjust few fields (SpendUnconfirmed, MinConfs, etc).
Or even better accept req as-is and apply checks on its fields. E.g. demand the correct value of LocalFundingAmount, MinConfs, SpendUnconfirmed) in the input req.
Note that some fields are silently ignored or skipped when passing to LND:
- target_conf: ignored (not used for fee selection, not rejected).
- sat_per_byte (deprecated): ignored (not used, not rejected).
- node_pubkey_string (deprecated): ignored by this path (only node_pubkey bytes are used).
- funding_shim: ignored/overwritten (manager always builds its own PSBT shim).
- sat_per_vbyte: used locally for withdrawal/funding fee math, but not forwarded to lnd OpenChannel request.
- fund_max, outpoints: consumed by Loop’s own deposit-selection logic, not forwarded.
- min_confs: normalized to 1 for PSBT flow (0 accepted as default/unset).
Shouldn't we pass fund_max to LND? It affects channel size selection.
4 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: