This week in Bitcoin Core
Bitcoin Core contributor kevkevin covers some of the latest updates...
Hello 👋 folks, I'm kevkevin. I'm an open-source developer and reporter for The Insider Edition. This 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, 23 changes were merged. Here are some I thought were interesting from this week.
RPC: Return permitbaremultisig and maxdatacarriersize in getmempoolinfo #29954 by kristapsk
The
getmempoolrpc returns useful information about the state of your node’s mempool. Some of this information includes the number of transactions, the amount of memory used, and the minimum relay fee.
In this PR, Kristapsk added permitbaremultisig and maxdatacarriersize to the list of items returned. Themaxdatacarriersizerefers to the maximum number of bytes that can be used for theOP_RETURNoutputs in the mempoolcluster mempool: add TxGraph work controls #32263 by sipa
If you are not already aware, cluster mempool is an initiative to improve Bitcoin Core’s mempool by using clusters of transactions. In this pull request, sipa modifies the
TxGraph::DoWorkfunction, adding the parameter iters.
By adding the iters param, theDoWorkfunction will first get the clusters to an acceptable level and then, if more budget remains, attempt to get them to an optimal level. This is just one of the many changes required to get the cluster mempool ready for production use.wallet, rpc: add anti-fee-sniping to send and sendall #28944 by ishaanam
Currently, send and sendall don't do anti-fee-sniping because they don't use CreateTransaction. This PR adds anti-fee-sniping to these RPCs by calling
DiscourageFeeSnipingfromFinishTransactionwhen the user does not specify a locktime.
wallet: Fix relative path backup during migration. #32273 by davidgumberg
Support for wallets outside of the default wallet directory was added in #11687. In the RPC commands, there is no distinction between the wallet name and the wallet path. This led to a strange placement of the
wallet.legacy.bakfile.In this pull request davidgumberg implements the solution by placing backup files in the top-level of the node's walletdir directory using the folder name.
Open PR’s
There are always changes getting updated and reviewed in real time. Here are some notable PR’s that are still up and looking for reviews.
ci: Migrate CI to hosted Cirrus Runners #32989 by willcl-ark
This is a change to upgrade Bitcoin Core’s CI to hosted Cirrus Runners. This has a few benefits. We no longer need to self-host Cirrus Runners, making it easier for anyone with GitHub-style CI knowledge to maintain it, with improved scaling abilities, speed, GitHub workflow syntax, and reporting.
It is worth noting that these runners will likely be more expensive than the current self-hosted ones. This topic was also mentioned in the IRC meeting. The notes from willcl-ark are in the section below!wallet, rpc: add v3 transaction creation and wallet support #32896 by ishaanam
In this pull request, the use of v3 transactions is enabled in the wallet. The wallet will now throw errors if the user attempts to spend non-v3 UTXOs with v3 UTXOs. These RPCs now have a
versionargument to specify v3.createrawtransaction,walletcreatefundedpsbt,createpsbt,send, andsendall.
Here is a blurb from the release note:
Support has been added for spending version 3 transactions received bythe wallet. The wallet ensures that version 3 policy rules are beingmet. The wallet will throw an error if the user is trying to spend version 3 utxos with utxos of other versions. Additionally, the wallet will treat unconfirmed version 3 sibling transactions as mempool conflicts. The wallet will also ensure that transactions spending version 3 utxos meet the required size restrictions.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
Kernel WG Update (TheCharlatan)
There's some movement happening again on the API PR, currently scoping out approaches for making usage safer with reference counting.
It's also been attracting some new people to contribute, which is nice :)
Might have something more concrete to share again in a few weeks.
Stratum v2 WG Update (sjors)
MuSig2 WG Update (achow101)
“No changes since last week, #31244 is still probably rfm. I've pulled in several of the suggested followups into #29675” - achow101
“How long as #32144 been RFM when you say "it’s still probably rfm"?” - Murch[m]
“3 or 4 weeks” - achow101
“Any idea who should add their review or take a look at that for it to get merged?” - Murch[m]
“Anyone who is familiar with descriptors, or it could be merged. It does have ACKs from w0xlt, rkrux, theStack, and Sjors” - achow101
orphan resolution WG Update (glozow)
still looking to get #32941 in for v30
QML GUI WG Update (jarolrod, johnny9dev)
“We're making good progress on patching remaining issues with moving the project to submodule, cmake, and qt6. Deer gee has ported over his AssumeUTXO PR over to the new structure already (bitcoin-core/gui-qml#485) . I should have my previous PRs ported over this weekend.” - johnny9dev
“I believe that PR will also require an upstream PR to expose some utxo snapshot thing in the interface” - pinheadmz
“It will. I suggested we maintain a patch until then” - johnny9dev
“so thatll be the new, somewhat frustrating, process but i think the separation of interests there is good” - pinheadmz
“Anyway we're almost caught up with previous functionality. That's all from gui-qml” - johnny9dev
dbwrapper read/write asymmetry (l0rinc)
dbwrapper writes currently pretend to return bool but always return true, while real errors surface via exceptions – #33042 makes that explicit, but we need to decide the canonical error path
`read` catches the exception and returns, but `write` always returned `true`, while throwing in the background
CI migration to Cirrus Runners (willcl-ark)
Myself and @m3dwards have been working on a change to migrate to our CI to hosted Cirrus Runners. This is now open in #32989.
The benefits and various tradeoffs of such a move are detailed in the top comment in the PR, but in summary it should make the CI maintainable by more people, not be reliant on the current infrastructure, and also provide "easier scaling"; if you want to scale more machines, just throw more $$ at the problem. These are fleshed out further in the PR, and we'd welcome feedback there.
Moving to our own runners also has a knock-on effect that all the (current) "cirrus" jobs will run on your own forks slower, on GH free runners, so self-hosting a cirrus runner may no longer be necessary if speed it not an issue for you. Forks (like inquisition) would be able to buy their own runners if they wanted faster runners for their repos too, and enable with a trivial patch.
I wanted to highlight it in a meeting just to try and alert as many people to it as possible, in case there was any opposition to it which hadn't been raised yet. Naturally, we are also looking for more reviewers too! So if anyone has any interest, then feel free to consider this a review-beg as well :)
ibd recalculating block hashes (phantomcircuit)
so i instrumented cblockheader::gethash to count how many times we reclculate the headers hash and i got some extreme outliers like 800+ times, i think this has to do with receiving blocks out of order during IBD and the behavior of activatebestchain
Following this comment, there was a longer discussion, which you can view in the full logs
For the full IRC meeting, check out the meeting in minutes
Releases
This release includes various bug fixes and performance improvements, as well as updated translations.
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
 | A guest post by
|