Is Cluster Mempool Finished? - This week in Bitcoin Core #32
This week we tell miners to cool down right after IBD...
Hello 👋 folks, I’m kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo. Here’s what I found notable.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, 19 changes were merged. Here are some I thought were interesting from this week.
mining: add cooldown to createNewBlock() immediately after IBD by Sjors
If a mining client connected to a Bitcoin Node in IBD or catching up on the last 24 hours, they would receive a flood of new templates.
This change modifies createNewBlock() from a method that can return quickly to one that can be blocked for a few minutes. This is because, instead of returning quickly, the cooldown waits for IBD to finish. Then, as the tip moves forward, it waits a few seconds to see if the tip is updated. If so, then the timer is restarted.
The cooldown is optional because it should not be used for internal non-IPC code, and also should not halt when testing the IPC client in some situations, like Signet.
Sjors has been working on improving the IPC interface, and this is another installment of his changes!miniscript: Use Func and Expr when parsing keys, hashes, and locktimes by achow101
Miniscript has a parser, and it currently only looks for the next “)” when parsing key, hash, or locktime expressions. This causes failures when the expression contains a nested expression. Currently, nested expressions are only possible with musig() inside key expressions. Achow101 noticed that this pattern could be generalized to handle hahses and locktimes, so they implemented that as well.
Cluster mempool: SFL cost model (take 2) by sipa
This is part of the cluster mempool tracking issue. This change improves the accuracy of the cost model for spanning forest linearization (SFL). The SFL cost model controls how much CPU time is spent in the algorithm for clusters that cannot be linearized within a reasonable amount of time. The goal is to have a metric for the amount of work performed. We want to impose a lower bound and an upper bound on how much work is done while linearizing.
There are conflicting design goals. On one had it is ideal if the metric is closely correlated to actual CPU time, but at the same time, it can be a nightmare to make it system-dependent because then it would be hard to predict/reason network-wide.
There are multiple solutions which are listed in the PR, but Sipa went the middle ground, counting function calls/branches/loops with weights that were determined through benchmarking.
You can read the full specification in the PR.
There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.
This PR adds a submitBlock method to the IPC Mining interface, equivalent to the submitblock RPC. It accepts a serialized block over IPC, validates/processes it via the normal block-processing path.
The method uses the same result shape as checkBlock: bool + reason/debug out-params. It reports duplicate, inconclusive, and invalid-block rejection details, and initializes reason/debug on every call.
Closes #34626
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
16:01:37 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:02:21 <sipa> I have closed #30289. Sadly, that also means dissolving the cluster mempool WG.
16:02:34 <fjahr> RIP!
16:02:52 <sipa> Thanks everyone for getting us this far.
16:03:29 <sipa> that’s it :)
16:03:45 <fjahr> Congrats on getting this far and thanks!
16:03:55 <instagibbs> well fought project, congrats
16:04:17 <andrewtoth_> congrats sipa!
16:04:47 <sipa> just over 3 years since sdaftuar and I started talking about it :)16:03:47 <fjahr> #topic Kernel WG Update (sedited)
16:04:45 <sedited> another RFC PR for improving blockmap and cchain concurrency was opened in #34654
16:04:54 <sedited> that’s all from me.16:05:16 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:05:39 <andrewtoth_> #34165 was merged, thanks everyone!
16:05:46 <andrewtoth_> I rebased #31132 for that as well as furszy’s ThreadPool. I’m hopeful we can merge that soon after v31 branch off
16:06:18 <andrewtoth_> Not sure if l0rinc is here, but he opened #34641 after last week’s meeting. Would be nice to get that in for v31
16:06:29 <andrewtoth_> that’s it from meReleases
No releases this week
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
If there are any comments, suggestions, or errors, do not hesitate to reach out or comment