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

multi: configurable anchor commitment conf target #6025

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ellemouton
Copy link
Collaborator

In this commit, a new config option is added so that users can set the
confirmation target to be used for anchor commitments. The default value
is set to 6. Before this commit, a conf target of 3 was used.

cc @ziggie1984

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.

Good Job, thanks for putting me in cc :)

config.go Show resolved Hide resolved
@@ -1104,10 +1108,17 @@ func (l *channelLink) htlcManager() {
continue
}

// For normal channels, we use a conf target of 3 to
// determine the current network fee.
confTarget := uint32(3)
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: would be cool to have also a constant for this variable like for example: defaultCommitmentConfTarget = 3? Why are we using 3, is it just a common agreement ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good idea, I will move it out to a constant.
Yes i think using 3 was just the norm.

@ellemouton
Copy link
Collaborator Author

!lightninglabs-deploy mute 2022-Jan-01

@carlaKC carlaKC self-requested a review January 11, 2022 08:38
Copy link
Collaborator

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

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

Great PR, only minor comments!

@@ -1104,10 +1113,17 @@ func (l *channelLink) htlcManager() {
continue
}

// For normal channels, we use a conf target of 3 to
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: I wouldn't hardcode 3 here in case we bump defaultCommitmentConfTarget.

// chain in within the given confirmation target. The returned value is
// expressed in fee-per-kw, as this is the native rate used when computing the
// fee for commitment transactions, and the second-level HTLC transactions.
func (l *channelLink) sampleNetworkFee(confTarget uint32) (chainfee.SatPerKWeight, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

wrap at 80 while we're here?

config.go Outdated
@@ -348,6 +352,8 @@ type Config struct {

MaxCommitFeeRateAnchors uint64 `long:"max-commit-fee-rate-anchors" description:"The maximum fee rate in sat/vbyte that will be used for commitments of channels of the anchors type. Must be large enough to ensure transaction propagation"`

AnchorsCommitConfTarget uint32 `long:"anchors-commit-conf-target" description:"The target number of blocks to be used to estimate the fee to use for anchor commitments"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Difficult to express succinctly, but can we add a note clarifying that this is only for commitments/force closes? I can see end user confusion thinking that we'll use this for cooperative close, which is not the case?

func (l *channelLink) sampleNetworkFee() (chainfee.SatPerKWeight, error) {
// We'll first query for the sat/kw recommended to be confirmed within 3
// blocks.
feePerKw, err := l.cfg.FeeEstimator.EstimateFeePerKW(3)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since anchors are the default channel type in lnd, we're effectively dropping our fee rates for all our commitments to conf target = 3 to 6 with this change. Are we good with that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah good question. Perhaps we should leave it at 3 for now and let those who want to change it change it?
Just seems weird to use anchor channels and then still set a high conf target. But maybe it is best to leave it as is while we wait for package relay? thoughts @Roasbeef ?

Copy link
Contributor

@arshbot arshbot Feb 15, 2022

Choose a reason for hiding this comment

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

we're effectively dropping our fee rates

Wouldn't we be increasing our fee rates bc faster conf time?

NVM, thought we were going from 6 -> 3

Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking we should stick to 3 as default unless we have a reason to change. It's 3 for autopilot

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah i'm happy to change it back. The thinking was just that it is kinda weird to have anchor commitment fees be so high since it kinda defeats the purpose since, no? or do we ideally not want to have to bump the fee? thoughts appreciated @Roasbeef & @carlaKC

@Roasbeef Roasbeef added this to the v0.15.0 milestone Jan 21, 2022
@Roasbeef Roasbeef added commitments Commitment transactions containing the state of the channel config Parameters/arguments/config file related issues/PRs labels Jan 21, 2022
@Roasbeef Roasbeef added this to In progress in v0.15.0-beta via automation Feb 2, 2022
@Roasbeef Roasbeef moved this from In progress to Blocked / Chopping Block / Up For Adoption in v0.15.0-beta Feb 2, 2022
In this commit, a new config option is added so that users can set the
confirmation target to be used for anchor commitments. The default value
is set to 6. Before this commit, a conf target of 3 was used.
Copy link
Collaborator Author

@ellemouton ellemouton left a comment

Choose a reason for hiding this comment

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

Thanks for the review @carlaKC 🚀 updated as per suggestion. Good question re dropping from a 3 to 6 conf target for our default chan type, will defs get a second opinion re than

func (l *channelLink) sampleNetworkFee() (chainfee.SatPerKWeight, error) {
// We'll first query for the sat/kw recommended to be confirmed within 3
// blocks.
feePerKw, err := l.cfg.FeeEstimator.EstimateFeePerKW(3)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah good question. Perhaps we should leave it at 3 for now and let those who want to change it change it?
Just seems weird to use anchor channels and then still set a high conf target. But maybe it is best to leave it as is while we wait for package relay? thoughts @Roasbeef ?

@Roasbeef Roasbeef added the P3 might get fixed, nice to have label Feb 14, 2022
func (l *channelLink) sampleNetworkFee() (chainfee.SatPerKWeight, error) {
// We'll first query for the sat/kw recommended to be confirmed within 3
// blocks.
feePerKw, err := l.cfg.FeeEstimator.EstimateFeePerKW(3)
Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking we should stick to 3 as default unless we have a reason to change. It's 3 for autopilot

@@ -365,6 +365,10 @@
; propagation (default: 10)
; max-commit-fee-rate-anchors=5

; The confirmation target to be used to estimate the fee to be used for anchor
; commitment transactions. (default: 6)
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe mention anchor commitment txs are default and modifying this setting will apply to all channels? users may avoid this setting because it looks scary and technical unless told otherwise

@Roasbeef Roasbeef removed this from Blocked / Chopping Block / Up For Adoption in v0.15.0-beta Mar 7, 2022
@Roasbeef Roasbeef modified the milestones: v0.15.0, v0.16.0 Mar 7, 2022
@lightninglabs-deploy
Copy link

@ellemouton, remember to re-request review from reviewers when ready

@ellemouton
Copy link
Collaborator Author

!lightninglabs-deploy mute 2022-April-04

@Roasbeef Roasbeef modified the milestones: v0.16.0, v0.17.0 Aug 23, 2022
@saubyk saubyk removed this from the Low Priority milestone Aug 8, 2023
@Roasbeef
Copy link
Member

Roasbeef commented Jan 5, 2024

I think this is no longer needed (?) now that we'll not sweep anchors until we actually need to? Then once their swept, BumpFee can be used to increase the CPFP rate.

@ellemouton
Copy link
Collaborator Author

I think this is no longer needed (?) now that we'll not sweep anchors until we actually need to? Then once their swept, BumpFee can be used to increase the CPFP rate.

but doesnt that require a user to actively go and bump it then? This just allows them to set the default target if they want.

happy to close though - lemme know what you think

@ziggie1984
Copy link
Collaborator

So I think it makes sense to distinguish between anchor and non-anchor channels but I probably think we should just make sure we always use the min_relay_fee for anchors, but not only ours but taking the ones of our peers into account as well (relates to #8302)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
commitments Commitment transactions containing the state of the channel config Parameters/arguments/config file related issues/PRs P3 might get fixed, nice to have
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants