New Private Broadcast Working Group - This Week in Bitcoin Core #43
This week inside Bitcoin Core the devs go on vacation somewhere unknown
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.
A new working group was created this week for Private Broadcast. Normally, new working groups are done in an IRC channel, but this one is being done in a Signal Group chat. You can find the signal group in the full meeting logs.
Private broadcast is the idea of opening a temporary Tor or I2P connection, sending the transaction then closing the connection.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, 11 changes were merged. Here are some I found interesting this week.
wallet: addhdkey RPC to add just keys to wallets via new unused(KEY) descriptor by achow101
Ava Chow added an RPC method named addhdkey. This allows a BIP 32 extended key to be added to the wallet without needing to import it as part of a separate descriptor. It is sometimes useful for the wallet to have keys that it can sign with, but are not (initially) involved in any scripts.
Ryan Ofsky initially suggested adding an unused (KEY) descriptor, but this PR implemented it and was merged into master.build: Add a compiler minimum feature check by polespinasa
As the title says, this change adds a compiler minimum feature check. This helps developers save time by failing early and explaining why, instead of having to chase down version errors.
This change makes it easier for developers to build the project without wasting time.
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.
validation: fetch block inputs on parallel threads by andrewtoth
Problem
Currently, when fetching inputs in `ConnectBlock`, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during `ConnectBlock`, we can fetch all inputs of a block in parallel on multiple threads while connecting.
Solution
We add a ThreadPool to CoinsViewOverlay to fetch block inputs in parallel. The block is passed to the `CoinsViewOverlay` view before entering `ConnectBlock`, which kicks off the worker threads to begin fetching the inputs. The cache returns fetched coins as they become available via the overridden `FetchCoinFromBase` method. If not available yet, the main thread also fetches coins as it waits.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: nothing from my side
stickies-v: #topic Net Split WG Update (cfields)
cfields: No update this week. I’m currently paused on the net refactor while working on some other projects (primarily multi_index replacement). Maybe best to take me out of the rotation for now?
stickies-v: alright, will do, lmk when you’d like me to re-add it, or just update the wiki when you want to!stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
cfields: 👍
l0rinc: #35156 was merged and a few other similar ones experimented with - nothing else from my side
_andrewtoth_: worked with dergoegge to run #31132 in antithesis using drive to construct blocks with missing inputs and other things. No issues found.
stickies-v: no issues is good
_andrewtoth_: Working on creating a fresh PR with the changes, since there’s over 600 comments and most are no longer relevant
_andrewtoth_: that’s it from mestickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: So it was suggested to create a project board last meeting so i worked towards that as it was a great idea
johnny9dev: and at coredev i setup the official one with all of the tasks i collected
johnny9dev: https://github.com/orgs/bitcoin-core/projects/1/views/3
stickies-v: that’s a well populated project board!
johnny9dev: it can be found here and we have a plan towards releasing. It is prioritized with “Preview” being our first build to get feedback on which should be sometime in June. “Beta” will be our target list for creating the PR sometime this fall. And “v1.0” is everthing is good to merge into bitcoin/bitcoin
jarolrod: wanted to scoot in and say: i’ll be around more formally from now on, to help qml gui ship
jarolrod: glad to be back :)
stickies-v: we’ll send over the paperwork shortly
johnny9dev: yes! excited for more contributors
stickies-v: good to see you back jarolrod!
jarolrod: 🥂
johnny9dev: epicleafies: any status?
epicleafies: Yeah, I’ve worked on implementing watch only wallet along with a few bug fixes.
johnny9dev: great. that is all for qmlstickies-v: #topic Libevent removal (pinheadmz, fjahr)
pinheadmz: Working on #35182, ironing out edge cases.
pinheadmz: Restarted fuzz testing with latest commits.
pinheadmz: About to post some benchmarking I did, just running the functional test suite on all three platforms to compare timing with master (~1-2% slower than master). Debug builds are even slower because libevent is always compiled with optimization.
pinheadmz: Passed integration testing with LND, which revealed the most significant breaking change: `debugexclude=libevent` will prevent startup since the logging category is removed. Any thoughts about this? It’ll be in the release notes but we could also band-aid that for now.
fjahr: on the go but no updates from me, still need to address latest feedback on CLI pull
sipa: Should probably just leave it in, as a category with no messages associated.
cfields: pinheadmz: leave the category in and mark it deprecated?
sipa: And give a warning on startup if it’s specified.
stickies-v: that sounds like the best approach to me too, with deprecation warning log yeah
sipa: The cost of keeping it around is tiny until we run out of log category bits, right?
pinheadmz: ok janb84 and i had some back and forth about what to do with the logging category but i didnt realize at that time it would actually prevent startup
pinheadmz: so i will make that change
pinheadmz: and thats all 4 me
stickies-v: Anything else to discuss?
_andrewtoth_: We’ve started a private broadcast working group channel. Feel free to join https ://signal.group/#CjQKIIBs79NZA9NAwuNXzBteyKUWxOEWu3QqaiQSMMJZCl2hEhD80HdpVUYNB_AGrMMTZFdu
stickies-v: not to dictate my personal comms preferences on people, but i think it’d be cool if people would consider continue to use dedicated irc channels to keep public logs for posterity
stickies-v: anyway, separate topic i guess
stickies-v: looks like we’re done here, thanks for the updates everyone
_andrewtoth_: stickies-v noted thanksRead here for the full meeting
Releases
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