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.

Sign up for GitHub

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

Jump to bottom

fundchannel with feerate=urgent leads to transaction getting stuck in mempool #6129

Closed
lightningorb opened this issue Mar 27, 2023 · 4 comments · Fixed by #6170
Closed

fundchannel with feerate=urgent leads to transaction getting stuck in mempool #6129

lightningorb opened this issue Mar 27, 2023 · 4 comments · Fixed by #6170
Assignees
@rustyrussell
Labels
bug docs
Milestone
v23.05

Comments

@lightningorb
Copy link
Contributor

fundchannel with a feerate set to 'urgent' leads to 5 sat/vb which, given the current state of the mempool leads to the transaction getting stuck in the mempool.

It seems these:

  • slow
  • normal
  • urgent

feerate values are not being calculated properly given the current state of the mempool. The documentation states that urgent (aim for next block) which is not the case.
@lightningorb
Copy link
Contributor Author

Also the documentation for setting the feerate manually is not clear:

Otherwise, feerate is a number, with an optional suffix: perkw means the number is interpreted as satoshi-per-kilosipa (weight), and perkb means it is interpreted bitcoind-style as satoshi-per-kilobyte. Omitting the suffix is equivalent to perkb.

It's not straightforward translating sat per vb from mempool.space into fundchannel feerate values. Could you please provide some examples.

@lightningorb
Copy link
Contributor Author

Example this is a batch open performed with feerate=urgent

image

@lightningorb
Copy link
Contributor Author

https://mempool.space/tx/3395923947ba732261aae82d275f806357bbbbdab8d83c56f34a6959b0938e60

@rustyrussell
Copy link
Contributor

fundchannel with a feerate set to 'urgent' leads to 5 sat/vb which, given the current state of the mempool leads to the transaction getting stuck in the mempool.

It seems these:

* `slow`

* `normal`

* `urgent`

feerate values are not being calculated properly given the current state of the mempool. The documentation states that urgent (aim for next block) which is not the case.

Indeed, it's actually using the 6 block estimate for "urgent". This was an accidental side-effect of lowering fee estimates for v0.10.1! 😬

The next release allows "2blocks" so you can control this more sanely, and I will fix the documentation for "urgent" to be correct. I'll also add docs about pervB -> perkb!

@rustyrussell rustyrussell added this to the v23.05 milestone Apr 11, 2023
@rustyrussell rustyrussell self-assigned this Apr 11, 2023
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Apr 11, 2023
@rustyrussell
doc: give helpful examples for feerate values.
97dfa05 
mempool.info gives sat/vB, which is 1000 too low for us!

See-also: ElementsProject#6161 (complains setting feerate to 5 doesn't work)

See-also: ElementsProject#6129
Suggested-by: @lightingorb
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Apr 11, 2023
@rustyrussell
doc: document that urgent doesn't use the 2-block estimate, but the 6…
ca5976a 
…-block.

Turns out this was accidentally changed for v0.10.1 in
d8e6889 where we made fee levels less
aggressive.

Oops.  I guess we can fix the docs.  And we now have "2blocks" if you
want it really fast!

Closes: ElementsProject#6129
Changelog-Fixed: JSON-RPC: `feerates` document correctly that urgent means 6 blocks (not 2), and give better feerate examples.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@ShahanaFarooqui ShahanaFarooqui linked a pull request Apr 11, 2023 that will close this issue
Fix feerate docs #6170
Merged
ShahanaFarooqui pushed a commit that referenced this issue Apr 11, 2023
@rustyrussell @ShahanaFarooqui
doc: give helpful examples for feerate values.
49b7afe 
mempool.info gives sat/vB, which is 1000 too low for us!

See-also: #6161 (complains setting feerate to 5 doesn't work)

See-also: #6129
Suggested-by: @lightingorb
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ShahanaFarooqui pushed a commit that referenced this issue Apr 11, 2023
@rustyrussell @ShahanaFarooqui
doc: document that urgent doesn't use the 2-block estimate, but the 6…
3f95b55 
…-block.

Turns out this was accidentally changed for v0.10.1 in
d8e6889 where we made fee levels less
aggressive.

Oops.  I guess we can fix the docs.  And we now have "2blocks" if you
want it really fast!

Closes: #6129
Changelog-Fixed: JSON-RPC: `feerates` document correctly that urgent means 6 blocks (not 2), and give better feerate examples.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
gkrizek pushed a commit to voltagecloud/lightning that referenced this issue Apr 26, 2023
@rustyrussell @gkrizek
doc: give helpful examples for feerate values.
ba047aa 
mempool.info gives sat/vB, which is 1000 too low for us!

See-also: ElementsProject#6161 (complains setting feerate to 5 doesn't work)

See-also: ElementsProject#6129
Suggested-by: @lightingorb
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
gkrizek pushed a commit to voltagecloud/lightning that referenced this issue Apr 26, 2023
@rustyrussell @gkrizek
doc: document that urgent doesn't use the 2-block estimate, but the 6…
8024fd5 
…-block.

Turns out this was accidentally changed for v0.10.1 in
d8e6889 where we made fee levels less
aggressive.

Oops.  I guess we can fix the docs.  And we now have "2blocks" if you
want it really fast!

Closes: ElementsProject#6129
Changelog-Fixed: JSON-RPC: `feerates` document correctly that urgent means 6 blocks (not 2), and give better feerate examples.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ddustin pushed a commit to ddustin/lightning that referenced this issue May 12, 2023
@rustyrussell @ddustin
doc: give helpful examples for feerate values.
7bc269d 
mempool.info gives sat/vB, which is 1000 too low for us!

See-also: ElementsProject#6161 (complains setting feerate to 5 doesn't work)

See-also: ElementsProject#6129
Suggested-by: @lightingorb
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ddustin pushed a commit to ddustin/lightning that referenced this issue May 12, 2023
@rustyrussell @ddustin
doc: document that urgent doesn't use the 2-block estimate, but the 6…
5c3984a 
…-block.

Turns out this was accidentally changed for v0.10.1 in
d8e6889 where we made fee levels less
aggressive.

Oops.  I guess we can fix the docs.  And we now have "2blocks" if you
want it really fast!

Closes: ElementsProject#6129
Changelog-Fixed: JSON-RPC: `feerates` document correctly that urgent means 6 blocks (not 2), and give better feerate examples.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rustyrussell rustyrussell

Labels
bug docs
Projects
None yet
Milestone
v23.05
Development

Successfully merging a pull request may close this issue.

Fix feerate docs rustyrussell/lightning
2 participants
@rustyrussell @lightningorb