-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix batchopen fee calculation #8896
Fix batchopen fee calculation #8896
Conversation
Important Review skippedAuto reviews are limited to specific labels. Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 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? TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Additionally, you can add CodeRabbit Configuration File (
|
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.
Nice! Looks good, I think it would be great to add a check in the itest that the batched opening transaction has the right fee rate
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.
Cool I think this is now missing a release note and test, otherwise good to go.
In terms of testing, I think we can update one of the batch opening tests, with some modifications,
- set a fee rate for a targeted conf via
ht.SetFeeEstimateWithConf
- open it with the targeted conf
- validate the fee rate is used.
c3befc3
to
cef9954
Compare
cef9954
to
5cc2a18
Compare
Let me know if I should remove the |
5cc2a18
to
a364eab
Compare
cmd/lncli/cmd_open_channel.go
Outdated
@@ -953,6 +965,37 @@ func printChanOpen(update *lnrpc.OpenStatusUpdate_ChanOpen) error { | |||
return nil | |||
} | |||
|
|||
// printPendingChan prints the funding txID of the pending channel opening. | |||
func printPendingChan(pendingChan *lnrpc.ChannelPoint) error { |
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.
think we already have printChanPending
?
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.
renamed it to printPendingChanPoint
because on of them takes in a lnrpc.OpenStatusUpdate_ChanPending
the other a lnrpc.ChannelPoint
cmd/lncli/cmd_open_channel.go
Outdated
@@ -460,6 +460,22 @@ func openChannel(ctx *cli.Context) error { | |||
"combination with the --psbt flag") | |||
} | |||
|
|||
// In case we dont want to wait until the channel is fully confirmed | |||
// onchain we use the `OpenChannelSync` rpc call. |
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.
I think the current block
already does that?
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.
tried to explain it in the other comment:
Otherwise the for loop on the LND server is still running although the client already exited after receiving the PendingOpenRequest. So it is a slight improvement because the server side will only cancel the goroutine when the Channel is open (has the required confirmations).
verified it on regtest, we indeed keep the goroutine of the RPC server open even if we opened a channel in an "unblock" way, thats why we should use the sync call in this case:
goroutine 896 [select, 6 minutes]:
github.com/lightningnetwork/lnd.(*rpcServer).OpenChannel(0x1400018ca00, 0x14000d17e60, {0x1024e69d0, 0x1400074a140})
github.com/lightningnetwork/lnd/rpcserver.go:2408 +0x2a4
github.com/lightningnetwork/lnd/lnrpc._Lightning_OpenChannel_Handler({0x1024a6120, 0x1400018ca00}, {0x1024e1f70, 0x140023c78c0})
github.com/lightningnetwork/lnd/lnrpc/lightning_grpc.pb.go:2392 +0x120
github.com/grpc-ecosystem/go-grpc-prometheus.init.(*ServerMetrics).StreamServerInterceptor.func4({0x1024a6120, 0x1400018ca00}, {0x1024e1748, 0x14002862000}, 0x140025933f8, 0x1024b2fc0)
github.com/grpc-ecosystem/[email protected]/server_metrics.go:121 +0xc8
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.
moved to #8934
itest/lnd_funding_test.go
Outdated
require.NoError(ht, err) | ||
|
||
// Mine 1 block to confirm the funding transaction. | ||
block := ht.MineBlocksAndAssertNumTxes(1, 1)[0] |
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.
don't think we need to check whether the tx is found in the block or not since that's the only tx that could happen in this context. Meanwhile we can use h.GetNumTxsFromMempool
instead to get the tx
,
cmd/lncli/cmd_open_channel.go
Outdated
// In case we dont want to wait until the channel is fully confirmed | ||
// onchain we use the `OpenChannelSync` rpc call. | ||
if !ctx.Bool("block") { | ||
pendingChan, err := client.OpenChannelSync(ctxc, req) |
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.
Feels like this is unrelated to this PR.
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.
ok will move this change into its own new PR.
itest/lnd_funding_test.go
Outdated
// channel is still not confirmed but pending in the mempool. | ||
chanPoint := ht.OpenChannelSync(alice, bob, lntest.OpenChannelParams{ | ||
Amt: chanAmt, | ||
ConfTarget: fn.Some(int32(3)), |
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.
thanks for adding that test! to have different coverage than the batch open test, we could test for the sat per vbyte here
server.go
Outdated
@@ -4562,6 +4562,10 @@ func (s *server) OpenChannel( | |||
req.Err <- err | |||
return req.Updates, req.Err | |||
} | |||
|
|||
srvrLog.Infof("Funding fee rate was not set, using defaut "+ |
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.
does it make sense to remove the code above and error in case no fee rate was set? it's a bit strange that we deal with default target confirmations in two different places
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.
totally agree, let's error out if no feerate is specified.
671454a
to
14ebaed
Compare
So this PR needs to remove the |
14ebaed
to
c48ea4e
Compare
Moved the |
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.
Close! CI failed tho, need to update a few callsites as they were changed in master.
} | ||
req.FundingFeePerKw = feeRate | ||
req.Err <- fmt.Errorf("no FundingFeePerKw specified for " + | ||
"the channel opening transaction") |
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.
why do we change this? I think initially I did make it mandatory to include a conf target or feerate, then #8693 was added to revert it back - think we should move this change to a new commit in this PR if this is a bug fix.
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.
yes I think we can return an error here because we already do this in the parsing function.
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.
moved it into a separate commit, tho I want to mention this is not a bug fix, but just unifying the place where we inject a default setting.
lntest/harness.go
Outdated
@@ -1094,6 +1094,16 @@ func (h *HarnessTest) openChannelAssertPending(srcNode, | |||
return update.ChanPending, respStream | |||
} | |||
|
|||
// OpenChannelSync attempts to open a channel between srcNode and destNode with | |||
// the passed channel funding parameters. | |||
func (h *HarnessTest) OpenChannelSync(srcNode, |
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.
move to #8934?
itest/list_on_test.go
Outdated
@@ -101,6 +101,10 @@ var allTestCases = []*lntest.TestCase{ | |||
Name: "wallet rescan address detection", | |||
TestFunc: testRescanAddressDetection, | |||
}, | |||
{ | |||
Name: "open channel sync funding", | |||
TestFunc: testChannelOpeningSync, |
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.
let's move this to #8934 since it's not related to this PR?
c48ea4e
to
a474341
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 🎉
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🦾
Include the fee calculaltion for the psbt flow. Moreover include fee rate testing in the itest environment.
Setting default values for the channel opening fee rate is already done elsewhere therefore we remove on of those checks and return an error if no fee rate is specified.
a474341
to
eb7818a
Compare
Simple fix, though the underlying design probably needs some refactor because even for the batchopen flow we don't really need to do the fee-calculation for every channel but rather for the whole request.
Fixes #8895
Will add release-notes as soon as we decided in which release this will be included.