<gmaxwell>
I think in general private wallet use is an important area, since just using a wallet privately is a big reason to use bitcoin core. Essentially all other wallet approaches (except perhaps obscure ones) end up identifying you to third parties even when you're not sending a txn. Best you can do is use them over tor which has pretty significant limitations for long lived usage.
<bitcoin-git>
[bitcoin] rkrux opened pull request #32603: wallet, rpc: clarify wallet version in getwalletinfo help (master...wallet-version) https://github.com/bitcoin/bitcoin/pull/32603
<gmaxwell>
I stumbled into this somewhat old PR https://github.com/bitcoin/bitcoin/issues/28272 I think it's a moderately severe privacy problem. Consider a wallet in blocksonly mode. An attacker can race to send it an unsolicited compact block to determine what transactions the node sent. There is a straightforward fix: drop or treat as header messages any compact block where you hadn't asked the peer
<bitcoin-git>
[bitcoin] marcofleon opened pull request #32602: fuzz: Add target for coins database (master...2025/05/coins-view-db-fuzztest) https://github.com/bitcoin/bitcoin/pull/32602
<bitcoin-git>
[bitcoin] hebasto closed pull request #32577: subprocess: Let shell parse command on non-Windows systems (master...250521-subprocess-split) https://github.com/bitcoin/bitcoin/pull/32577
<bitcoin-git>
[bitcoin] hebasto opened pull request #32601: test: Fix `system_tests/run_command` test (master...250523-run-comand-test) https://github.com/bitcoin/bitcoin/pull/32601
<bitcoin-git>
[bitcoin] achow101 opened pull request #32598: walletdb: Log additional exception error messages for corrupted wallets (master...loadwallet-log-runtime_error) https://github.com/bitcoin/bitcoin/pull/32598
<bitcoin-git>
[bitcoin] achow101 opened pull request #32597: wallet: Always set descriptor cache upgraded flag for new wallets (master...desc-cache-is-upgraded) https://github.com/bitcoin/bitcoin/pull/32597
2025-05-22
<w473rm3l0n>
I don't think any such post will make a difference, because some people are unhappy with the way bitcoin core development works and their concerns or perception go beyond just OP_RETURN.
<bitcoin-git>
[bitcoin] theStack opened pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
<bitcoin-git>
[bitcoin] achow101 opened pull request #32593: wallet, rpc: Move (Un)LockCoin WalletBatch creation out of RPC (master...improve-lockcoin-interface) https://github.com/bitcoin/bitcoin/pull/32593
<gmaxwell>
my comment about coinbase attributing bitcoin's decenteralization to anyone being able to open a pull request.
<gmaxwell>
implementations in Bitcoin today, the thing that replaced the BCH 'reference implementation' was created in response to the adverse change)
<gmaxwell>
I dunno how to manage it though because all this openness and inclusiveness are fantastic tools for making good software, and also important to people's good feelings towards the project. But they just simply can't be where Bitcoin's security comes from.
<gmaxwell>
'cause at the day it's not the developers being great people that protects bitcoin (thoug they are!) -- great people can still have guns held to their heads (figuritively or litterally!) or can go crazy.
<gmaxwell>
one of the few positive oppturnities in this recent turmoil I think is an chance for people to learn to apply a diff and run a patched copy. That's a skill that any serious bitcoin power user ought to have. and while (IMO) completely unjustified for the current issue, it's exactly what people might need to do in the face of an adverse change.
<gmaxwell>
The fact that the current alternatives aren't so impressive is just a product that they are driven by their own motivations that don't have much/anything to do with specific bad choices in bitcoin core.
<gmaxwell>
lightlike: re serious alternatives: the code the user is running *right now* is a serious alternative to a future release. A future release with whatever adverse change backed out is a serious alternative -- even a moderately technical user can now reverse apply a diff and build bitcoin core with the help of an LLM. :) And of course people will make alternatives. And especially if the issue
<gmaxwell>
So at least for that specific purpose, it would have been better if contributing.md just said "Stuff goes in here if Achow likes it, you can use this repo if you like it, otherwise take a hike" :P ... cause if coinbases lawyers saw that they'd go okay obviously *this* isn't where bitcoin's properties arise. And instead would have made the case that no one controls the software users run and in
<gmaxwell>
So I agree to you to at least that extent. But I've absolutely seen it go wrong, including e.g. one coinbase filing in litigation explaining that bitcoin was decenteralized because anyone can make a pull request. ... and I don't really blame coinbase, it's easy to see how the very elaborate pesudogovernmental procedures in the project got mistaken for the origin of Bitcoin's properties.
<bitcoin-git>
[bitcoin] theuni opened pull request #32592: threading: remove ancient CRITICAL_SECTION macros (master...remove-critsect) https://github.com/bitcoin/bitcoin/pull/32592
<gmaxwell>
I think I feel somewhat the opposite, the whole point of bitcoin is defeated if other people control your usage. So trying to act like a pseudogovernment isn't in Bitcoin's interest, as some people will mistake the pomp and circumstance of power with actual power that should not and must not exist.
<lightlike>
gmaxwell: that is certainly what open source projects in general should default to - but even if in theory everyone can run their own software, in practice bitcoin core is still the de-facto reference implementation, which makes it a bit unique. As long as most other node impls are not serious alternatives I'd argue that implies at least some additional responsibilities other projects don't have - only up to some point though (e.g. we
<gmaxwell>
and this is my view because simply if it doesn't work that way it will be replaced with something that does. Exactly like this IRC channel, which functionally replaced #bitcoin-dev, because the other wasn't maintained in a way that preserved the participation of the major participants.
<gmaxwell>
The underlying principle I, personally, would keep in mind is that the repository exists so that its significant contributors can collaborate and produce the best bitcoin software they can. It does not exist to be fair, inclusive, friendly, to anyone -- except to the (very significant!) extent that those things help to produce good bitcoin software.
<gmaxwell>
lightlike: to clarify the 'asked to leave' comment from earlier. In watching PRs and bitcoin related traffic on social media, I've seen repeated participation from people who are overtly hostile to the project, it's activities, and contributors... including stuff that would get them immediately ejected from any professional enviroment. And while constructive criticism about proposals is
<bitcoin-git>
[bitcoin] fanquake merged pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
<bitcoin-git>
[bitcoin] fanquake merged pull request #32467: checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage (master...checkqueue_control_mandatory) https://github.com/bitcoin/bitcoin/pull/32467
<glozow>
perhaps unpopular opinion, but maybe the website repo should have stricter contribution requirements than the bitcoin/bitcoin repo
<TheCharlatan>
"> Note that this is not condoning non-financial data block space usage." this is what the issue seems to boil down to for users of Bitcoin Core, but I feel like this is not clear enough.
<sipa>
I've written a short statement about the relation between Bitcoin Core developments and transaction relay policy, with the help of darosior and glozow
<hebasto>
To improve our chances, I encourage anyone with a microsoft account to consider upvoting issue reports related to Bitcoin Core.
<hebasto>
To compile Bitcoin Core on Windows, there is currently only one supported option: MSVC.
<johnny9dev>
This following week we'll be focused on getting bitcoin-core/gui-qml#450 mergable, implementing more of the Receive page, and adding input validation and error strings on to the Send page.
<johnny9dev>
Christoph has been doing work on the Animations for the wallet and fixed the main transition easing with bitcoin-core/gui-qml#453
<johnny9dev>
For me, I implemented the initialization states for the WalletQmlController and added the first instance of the Skeleton loading animation that Christoph proposed last week. bitcoin-core/gui-qml#454
<johnny9dev>
This week we onboarded a new contributor, goqusan. He will be helping implement the QML components in the wallet views. He's starting with the receive page and added QR encoding. bitcoin-core/gui-qml#454
<corebot>
https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
<corebot>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] maflcko opened pull request #32588: util: Abort on failing CHECK_NONFATAL in debug builds (master...2505-abort-debug-check-nonfatal) https://github.com/bitcoin/bitcoin/pull/32588
<bitcoin-git>
[bitcoin] i-am-yuvi opened pull request #32587: [WIP] test: Fix reorg patterns in mempool tests to use proper fork-based approach (master...2025-05-update_test_reorg_behaviour) https://github.com/bitcoin/bitcoin/pull/32587
<bitcoin-git>
[bitcoin] maflcko opened pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
<bitcoin-git>
[bitcoin] fanquake merged pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400
<bitcoin-git>
[bitcoin] fanquake opened pull request #32584: depends: hard-code necessary c(xx)flags rather than setting them per-host (master...depends_hard_code_flags) https://github.com/bitcoin/bitcoin/pull/32584
<bitcoin-git>
[bitcoin] dergoegge opened pull request #32581: allocators: Apply manual ASan poisoning to `PoolResource` (master...2025-05-pool-poison) https://github.com/bitcoin/bitcoin/pull/32581
<bitcoin-git>
[bitcoin] rkrux opened pull request #32580: wallet, test: best block locator matches scan state follow-ups (master...wallet-locator) https://github.com/bitcoin/bitcoin/pull/32580
<bitcoin-git>
[bitcoin] hodlinator opened pull request #32579: headerssync: Keep tests ahead of increasing params (master...2025/05/headerssync_params) https://github.com/bitcoin/bitcoin/pull/32579
<bitcoin-git>
[bitcoin] l0rinc closed pull request #32457: bench: replace benchmark block with more representative one (413567 → 784588) (master...l0rinc/bench-block-413567-to-784000) https://github.com/bitcoin/bitcoin/pull/32457
<bitcoin-git>
[bitcoin] fanquake merged pull request #32475: wallet: Use `util::Error` throughout `AddWalletDescriptor` instead of returning `nullptr` for some errors (master...addwalletdescriptor-util-error) https://github.com/bitcoin/bitcoin/pull/32475
<bitcoin-git>
bitcoin/master 785e140 Ava Chow: wallet: Use util::Error throughout AddWalletDescriptor
<bitcoin-git>
bitcoin/master 87ec923 merge-script: Merge bitcoin/bitcoin#32475: wallet: Use `util::Error` throughout `AddWall...
<bitcoin-git>
[bitcoin] fjahr closed pull request #32133: RFC: Accept non-std transactions in Testnet4 by default again (master...2025-03-nonstd-testnet) https://github.com/bitcoin/bitcoin/pull/32133
<bitcoin-git>
[bitcoin] fjahr opened pull request #32575: RFC: refactor: Split multithreaded case out of CheckInputScripts (master...2025-05-CheckInputScript-split) https://github.com/bitcoin/bitcoin/pull/32575
<gmaxwell>
I'd like to hope that bitcoin core is secure against an extended threat model where a social engineer can convince a user to make safe sounding settings changes and the result is hopefully no worse than a denial of service.
<gmaxwell>
yeah I wouldn't be surprised if ~no one uses them in practice. There are a bunch of bitcoin core features that are probably unused, but it's not really possible to tell beyond removing it and seeing who complains. :P
<bitcoin-git>
[bitcoin] maflcko closed pull request #32501: RPC: removeprunedfunds should take an array of txids (master...removeprunedfunds-array) https://github.com/bitcoin/bitcoin/pull/32501
<bitcoin-git>
[bitcoin] fanquake opened pull request #32568: depends: use "mkdir -p" when installing xproto (master...alpine_MKDIRPROG) https://github.com/bitcoin/bitcoin/pull/32568
<bitcoin-git>
[bitcoin] fanquake merged pull request #29868: Reintroduce external signer support for Windows (master...240414-win-subprocess) https://github.com/bitcoin/bitcoin/pull/29868
<bitcoin-git>
bitcoin/master 6e5fc2b Hennadii Stepanov: test: Reintroduce Windows support in `system_tests/run_command` test
<bitcoin-git>
bitcoin/master 719fa9f Hennadii Stepanov: build: Re-enable external signer support for Windows
<bitcoin-git>
bitcoin/master 3a18075 Hennadii Stepanov: ci: Drop `-DENABLE_EXTERNAL_SIGNER=ON` configure option
<hacker4web3bitco>
Hi folks, I'm new to learn bitcoin core, ask a question, is there any doc about the cluster mempool implementation? I'm reading the code but struggles with the data structures relationship (bwtween like TxGraph, Cluster, DepGraph etc)
<darosior>
FYI i started drafting something this weekend regarding the "Bitcoin Core on relay policy" letter or however we'd want to call it. I haven't come up with something i consider satisfactory: i feel what i have addresses current drama too directly. I think this would be counterproductive to do. An alternative approach would be to make a more detailed
<bitcoin-git>
[gui] hebasto merged pull request #875: Use WitnessV0KeyHash in TestAddAddressesToSendBook (master...2505-qt-addr-test) https://github.com/bitcoin-core/gui/pull/875
<bitcoin-git>
bitcoin/master fa982f1 MarcoFalke: Use WitnessV0KeyHash in TestAddAddressesToSendBook
<bitcoin-git>
bitcoin/master 98ff38a laanwj: rpc: Perform HTTP user:pass split once in `RPCAuthorized`
<bitcoin-git>
[bitcoin] hebasto closed pull request #32537: Set minimum supported Windows version to 1903 (May 2019 Update) (master...250516-win-min-ver) https://github.com/bitcoin/bitcoin/pull/32537
<bitcoin-git>
[bitcoin] laanwj opened pull request #32566: Use subprocess library for notifications (master...2025-05-subprocess-system) https://github.com/bitcoin/bitcoin/pull/32566
<d33tah>
hi! is there the right channel to ask about setting up a Bitcoin node? a friend of mine is trying to diagnose why nobody is connecting to him via tor and asked me for help. i'm looking for someone who could help me diagnose the issue. according to https://bitnodes.io/, both the IP and onion address are reachable correctly
<bitcoin-git>
[gui] maflcko opened pull request #875: Use WitnessV0KeyHash in TestAddAddressesToSendBook (master...2505-qt-addr-test) https://github.com/bitcoin-core/gui/pull/875
<corebot>
https://github.com/bitcoin/bitcoin/issues/30039 | dbwrapper: Bump LevelDB max file size to 32 MiB to avoid system slowdown from high disk cache flush rate by maciejsszmigiero · Pull Request #30039 · bitcoin/bitcoin · GitHub
<PaperSword>
10:01:36 AM - sipa: bitcoin core can very aggressively cache the UTXO data cache in its application-level cache though […]
<sipa>
bitcoin core can very aggressively cache the UTXO data cache in its application-level cache though, which may or may not impact what gains are possible at all due to the database layer
<bitcoin-git>
[bitcoin] theStack opened pull request #32544: scripted-diff: test: remove 'descriptors=True' argument for `createwallet` calls (master...202505-scripted-diff-remove_descriptors_false_args) https://github.com/bitcoin/bitcoin/pull/32544
<bitcoin-git>
[bitcoin] TheCharlatan opened pull request #32543: kernel: Remove dependency on clientversion (master...kernelRmClientversion) https://github.com/bitcoin/bitcoin/pull/32543
<bitcoin-git>
bitcoin-detached-sigs/28.x 4902836 Matthew Zipkin: 28.2: osx signature for rc1