Skip to content

Conversation

@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 14, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33189.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK davidgumberg, instagibbs, ajtowns

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

@DrahtBot
Copy link
Contributor

🚧 At least one of the CI tasks failed.
Task multiprocess, i686, DEBUG: https://github.com/bitcoin/bitcoin/runs/48115164025
LLM reason (✨ experimental): The CI failure is caused by a compilation error in mining.cpp due to an unimplemented pure virtual method in an abstract class marked 'final', leading to build failure.

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

@fanquake
Copy link
Member

https://github.com/bitcoin/bitcoin/pull/33189/checks?check_run_id=48115164025:

[14:51:10.997] In file included from /ci_container_base/src/ipc/capnp/mining-types.h:11:
[14:51:10.997] /ci_container_base/ci/scratch/build-i686-pc-linux-gnu/src/ipc/capnp/mining.capnp.proxy.h:317:8: error: abstract class is marked 'final' [-Werror,-Wabstract-final-class]
[14:51:10.997]   317 | struct ProxyClient<ipc::capnp::messages::Mining> final : public ProxyClientCustom<ipc::capnp::messages::Mining, interfaces::Mining>
[14:51:10.997]       |        ^
[14:51:10.997] /ci_container_base/src/interfaces/mining.h:137:22: note: unimplemented pure virtual method 'GetBlockMinFee' in 'ProxyClient'
[14:51:10.997]   137 |     virtual CFeeRate GetBlockMinFee() const = 0;
[14:51:10.997]       |                      ^
[14:51:10.997] 1 error generated.

@glozow glozow force-pushed the 2025-08-minrelay branch 2 times, most recently from a0ccaf7 to 0dba9eb Compare August 15, 2025 15:29
@glozow glozow marked this pull request as ready for review August 15, 2025 16:52
glozow added 4 commits August 15, 2025 13:36
Clarify that the purpose of some parameters are to ensure identical
transactions are not created. Also, strengthen the test to catch these cases.
@@ -594,7 +594,7 @@ def test_incremental_relay_feerates(self):
node = self.nodes[0]
for incremental_setting in (0, 5, 10, 50, 100, 234, 1000, 5000, 21000):
incremental_setting_decimal = incremental_setting / Decimal(COIN)
self.log.info(f"-> Test -incrementalrelayfee={incremental_setting_decimal:.8f}sat/kvB...")
self.log.info(f"-> Test -incrementalrelayfee={incremental_setting:.8f}sat/kvB...")
Copy link
Member

Choose a reason for hiding this comment

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

In 636fa21 "test fixups"

Can drop the .8f, otherwise these are printed with 8 decimal places of 0's that are not necessary.

Copy link
Member

Choose a reason for hiding this comment

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

personal opinion only but printing 8 places always to easily eyeball the rate is better, so -0 on this suggestion

Copy link
Member

Choose a reason for hiding this comment

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

None of the settings have decimals though

Copy link
Contributor

Choose a reason for hiding this comment

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

-> Test -incrementalrelayfee=100.00000000sat/kvB... doesn't seem very useful indeed.

mining_basic reports -> Test -blockmintxfee=0.00000500 (500 sat/kvB)... which seems strictly better, as it gives a value that can actually be used with the config param as well as a sats figure?

Copy link
Contributor

@davidgumberg davidgumberg left a comment

Choose a reason for hiding this comment

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

ACK daa40a3

@@ -429,6 +429,7 @@ static RPCHelpMan getmininginfo()
{RPCResult::Type::STR_HEX, "target", "The current target"},
{RPCResult::Type::NUM, "networkhashps", "The network hashes per second"},
{RPCResult::Type::NUM, "pooledtx", "The size of the mempool"},
{RPCResult::Type::STR_AMOUNT, "blockmintxfee", "Minimum feerate of packages selected for block inclusion in " + CURRENCY_UNIT + "/kvB"},
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe a release note?

Copy link
Member

Choose a reason for hiding this comment

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

small note with explanation on how miners can use it would be nice since some miners are opting out of mining such low feerates for now

@@ -583,7 +583,7 @@ def test_replacement_relay_fee(self):
tx = self.wallet.send_self_transfer(from_node=self.nodes[0])['tx']

# Higher fee, higher feerate, different txid, but the replacement does not provide a relay
# fee conforming to node's `incrementalrelayfee` policy of 1000 sat per KB.
# fee conforming to node's `incrementalrelayfee` policy of 100 sat per KB.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit:

Suggested change
# fee conforming to node's `incrementalrelayfee` policy of 100 sat per KB.
# fee conforming to node's `incrementalrelayfee` policy of 100 sat per kvB.

@fanquake fanquake added this to the 30.0 milestone Aug 20, 2025
Copy link
Member

@instagibbs instagibbs left a comment

Choose a reason for hiding this comment

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

ACK daa40a3

@@ -594,7 +594,7 @@ def test_incremental_relay_feerates(self):
node = self.nodes[0]
for incremental_setting in (0, 5, 10, 50, 100, 234, 1000, 5000, 21000):
incremental_setting_decimal = incremental_setting / Decimal(COIN)
self.log.info(f"-> Test -incrementalrelayfee={incremental_setting_decimal:.8f}sat/kvB...")
self.log.info(f"-> Test -incrementalrelayfee={incremental_setting:.8f}sat/kvB...")
Copy link
Member

Choose a reason for hiding this comment

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

personal opinion only but printing 8 places always to easily eyeball the rate is better, so -0 on this suggestion

@@ -429,6 +429,7 @@ static RPCHelpMan getmininginfo()
{RPCResult::Type::STR_HEX, "target", "The current target"},
{RPCResult::Type::NUM, "networkhashps", "The network hashes per second"},
{RPCResult::Type::NUM, "pooledtx", "The size of the mempool"},
{RPCResult::Type::STR_AMOUNT, "blockmintxfee", "Minimum feerate of packages selected for block inclusion in " + CURRENCY_UNIT + "/kvB"},
Copy link
Member

Choose a reason for hiding this comment

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

small note with explanation on how miners can use it would be nice since some miners are opting out of mining such low feerates for now

@l0rinc
Copy link
Contributor

l0rinc commented Aug 21, 2025

Not everyone knows what "33106" is. To avoid it being interpreted as trying to hide something, could you please detail the changes in the PR title and description to help the reviewers and provide full transparency?

@dergoegge
Copy link
Member

Not everyone knows what "33106" is

"33106" refers to the pull request with that number: #33106, which is also linked in the PR description (only 12 times). It's common practice to link to a related PR like this (e.g. for a followup) in the PR title. Hope this helps.

@l0rinc
Copy link
Contributor

l0rinc commented Aug 22, 2025

Hope this helps.

Why do you think that exactly? You didn't say anything new, my comment was about making it obvious from the PR's title what it's about (without having to open it) - and not only to ones who already know what 33106 was about.

@maflcko
Copy link
Member

maflcko commented Aug 28, 2025

Could remove the outdated comment as well, after 3eab8b7?

diff --git a/test/functional/test_framework/mempool_util.py b/test/functional/test_framework/mempool_util.py
index 9ffd934f5a..3c4609c0b4 100644
--- a/test/functional/test_framework/mempool_util.py
+++ b/test/functional/test_framework/mempool_util.py
@@ -57,8 +57,7 @@ def fill_mempool(test_framework, node, *, tx_sync_fun=None):
     """Fill mempool until eviction.
 
     Allows for simpler testing of scenarios with floating mempoolminfee > minrelay
-    Requires -maxmempool=5 and assumes -minrelaytxfee
-    is 1 sat/vbyte.
+    Requires -maxmempool=5.
     To avoid unintentional tx dependencies, the mempool filling txs are created with a
     tagged ephemeral miniwallet instance.
     """

@ajtowns
Copy link
Contributor

ajtowns commented Aug 28, 2025

"33106" refers to the pull request with that number: #33106, which is also linked in the PR description (only 12 times). It's common practice to link to a related PR like this (e.g. for a followup) in the PR title.

Can we please make this not common practice anymore? Memorising PR numbers is no fun. "Followups for min fee changes" would have been fine.

@ajtowns
Copy link
Contributor

ajtowns commented Aug 28, 2025

ACK daa40a3 ; cursory review, seems reasonable

@fanquake fanquake merged commit 6ff2d42 into bitcoin:master Aug 28, 2025
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants