<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
<bitcoin-git>
[bitcoin] pinheadmz opened pull request #32539: init: Configure reachable networks before we start the RPC server (master...rpcallowip-rfc4193) https://github.com/bitcoin/bitcoin/pull/32539
<bitcoin-git>
[bitcoin] furszy closed pull request #32538: restrict std::cerr to errors; use std::cout for warnings and info (master...2025_init_warning_msgs) https://github.com/bitcoin/bitcoin/pull/32538
<bitcoin-git>
qa-assets/main b2fc82e Murch: Add Murch’s inputs May 2025
<bitcoin-git>
qa-assets/main 4e64c5b maflcko: Merge pull request #225 from murchandamus/2025-05-murch-inputs
<bitcoin-git>
[bitcoin] furszy opened pull request #32538: restrict std::cerr to errors; use std::cout for warnings and info (master...2025_init_warning_msgs) https://github.com/bitcoin/bitcoin/pull/32538
<bitcoin-git>
[bitcoin] theStack opened pull request #32533: test: properly check for per-tx sigops limit (master...202505-test-exact_per_tx_sigopcost_check) https://github.com/bitcoin/bitcoin/pull/32533
<bitcoin-git>
[bitcoin] l0rinc opened pull request #32532: RFC: script: short-circuit `GetLegacySigOpCount` for known scripts (master...l0rinc/short-circuit-known-script-types) https://github.com/bitcoin/bitcoin/pull/32532
<bitcoin-git>
[bitcoin] darosior opened pull request #32530: node: cap `-maxmempool` and `-dbcache` values for 32-bit (master...2505_limit_mempool_32bit) https://github.com/bitcoin/bitcoin/pull/32530
<bitcoin-git>
[bitcoin] laanwj opened pull request #32529: [DONOTMERGE] subprocess: replace `fs::directory_iterator` with `readdir` (master...2025-05-fdclose-debug-ci-hang) https://github.com/bitcoin/bitcoin/pull/32529
<gmaxwell>
One of the reasons, I fear, is that the root 'concern' material is just not actually that sincere or authentic. I've found that opponents of the change *reliably* disingage in discussions as soon as I join them, in a most unusual way. plus the flood of "I just switched to knots" posts from accounts that have never before made a comment related to bitcoin. I think it's likely that someone
<bitcoin-git>
[bitcoin] darosior opened pull request #32521: policy: make pathological transactions packed with legacy sigops non-standard (master...2503_nonstd_tx_sigops) https://github.com/bitcoin/bitcoin/pull/32521
<Earnestly>
Is there a ml post (I can't subscribe, it probably just sits in mod queue forever) which goes over the rationale/reason (from bitcoin core's view) for why op_return is to be changed (and the option to configure it potentially removed in the future)?
<darosior>
glozow: I don't think an executive of a Bitcoin company will go read my thousand line detailed technical refutation of mostly tin foil hat stuff and made-up objections. They will read two paragraphs published officially on the Bitcoin Core website.
<Murch[m]>
Given that we are such a small group compared to the Bitcoin user base, more simply resources served highly visibly might significantly reduce our effort
<Murch[m]>
There also generally have been a few things that the community has felt very strongly about that Bitcoin Core has not addressed, so it’s just been piling up
<darosior>
Murch[m]: this is more than 3 weeks of time that is at stake. It should not be overstated but i think it shook the trust in Bitcoin Core to some extent.
<Murch[m]>
Someone actually recently approached me that they want to make some educational videos about Bitcoin Core
<Murch[m]>
I’ve been told by several people in the past couple months that they wish there were a way to contact Bitcoin Core if one had questions or support issues, and others have recommended that we might find a couple contributors that do public relations or developer advocacy in some form.
<Murch[m]>
Aye, I think we should generally think a bit more about public communication, and even how we support users of Bitcoin Core
<bitcoin-git>
[bitcoin] maflcko opened pull request #32519: ci: Enable feature_init and wallet_reorgsrestore in valgrind task (master...2505-ci-valgrind) https://github.com/bitcoin/bitcoin/pull/32519
<fanquake>
sipa: yea I think I'm missing the difference between "We believe many contributors feel" & "Bitcoin Core believes X",
<sipa>
It's a bit of a challenge I think to do this, as Bitcoin Core contributors are an ill-defined group and I think few people are comfortable speaking for others. But I can imagine a statement from some maintainers/regular contributors of the form "We believe many contributors feel the goal of relay/mempool/... should be", so rather than "Bitcoin Core believes X should happen", it is an observation
<darosior>
in the past weeks i think we should hold off the change for some time (if it's gonna be merged doesn't matter if it is now or in 2 weeks) and work on our communication. To this end i suggest we post on the website a broad view of how Bitcoin Core approaches relay policy, to be signed off by people working in this area of the codebase. It should be
<darosior>
Hi everyone. My proposal for the OP_RETURN standardness rule change has been severely mischaracterized online. This has led to genuine concerns from Bitcoin enthusiasts about the change itself, but also about Bitcoin Core. I do not think there is any ground for these concerns, but what is done is done. From my experience engaging with the community
<pinheadmz>
I think ideally qmlgui ends up with bitcoin/bitcoin as a git sub module
<bitcoin-git>
[bitcoin] maflcko opened pull request #32514: scripted-diff: Remove unused leading newline in RPC docs (master...2505-rpc-newline) https://github.com/bitcoin/bitcoin/pull/32514
<bitcoin-git>
[bitcoin] m3dwards opened pull request #32513: ci: remove 3rd party js from windows dll gha job (master...250515-remove-js-ci) https://github.com/bitcoin/bitcoin/pull/32513
<bitcoin-git>
[bitcoin] darosior closed pull request #32117: qa: make feature_assumeutxo.py test more robust (master...2503_more_assumeutxo_test_unbrittling) https://github.com/bitcoin/bitcoin/pull/32117
<bitcoin-git>
[bitcoin] maflcko opened pull request #32507: ci: Exclude failing wallet_reorgsrestore.py from valgrind task for now (master...2505-ci-valgrind) https://github.com/bitcoin/bitcoin/pull/32507
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32502: wallet: Drop unused fFromMe from CWalletTx (master...5-14-25-dead-code-removal) https://github.com/bitcoin/bitcoin/pull/32502
<bitcoin-git>
[bitcoin] BrandonOdiwuor opened pull request #32501: RPC: removeprunedfunds should take an array of txids (master...removeprunedfunds-array) https://github.com/bitcoin/bitcoin/pull/32501
<gmaxwell>
_aj_: I mean in terms of theoretical weakness/attacks, lets say that a 50 block reorg takes more than 10 minutes for most nodes to proces. And forever reason (attack, internet cut, etc) such a fork forms in Bitcoin-- the result may be that the system never reconverges to a single new chain without human intervention, or takes a very very long time.
<gmaxwell>
_aj_: yes it would, which is at least a theoretical problem, if there is a deep fork bitcoin can stop converging when the cost to switch starts approaching the interblock time. This actually was seen in practice in some shitty altcoin called 'liquid bitcoin' or something like that where it has a fixed difficulty-- the network shattered into a thousand forks once the reorg time exceeded the
<gmaxwell>
_aj_: I don't really think so, particularly given that the reorg is a very rare event... but someone having a significant theft as a result of reorg may be incredibly damaging to the miner. Like great you got 0.001 BTC more but the public drama means all the bitcoin you earned is now worth 10% less.
<bitcoin-git>
bitcoin/master 07350e2 Martin Zumsande: test: Fix intermittent failure in wallet_basic.py
<bitcoin-git>
[bitcoin] fanquake opened pull request #32496: depends: add Qt `-ltcg` for Darwin, drop it for Windows (master...depends_qt_ltcg) https://github.com/bitcoin/bitcoin/pull/32496
<bitcoin-git>
[bitcoin] fanquake opened pull request #32491: build: document why we check for `std::system` (master...document_std_system) https://github.com/bitcoin/bitcoin/pull/32491
<bitcoin-git>
[bitcoin] maflcko opened pull request #32490: refactor: Remove UB in prevector reverse iterators (master...2505-less-UB) https://github.com/bitcoin/bitcoin/pull/32490
2025-05-13
<bitcoin-git>
[gui] achow101 opened pull request #872: gui: Menu action to export a watchonly wallet (master...export-watchonly-wallet-gui) https://github.com/bitcoin-core/gui/pull/872
<bitcoin-git>
[bitcoin] achow101 opened pull request #32489: wallet: Add `exportwatchonlywallet` RPC to export a watchonly version of a wallet (master...export-watchonly-wallet) https://github.com/bitcoin/bitcoin/pull/32489
<bitcoin-git>
[bitcoin] l0rinc closed pull request #32084: doc: document workaround and fallback for macOS fuzzing (master...l0rinc/libfuzzer-nosan-mac) https://github.com/bitcoin/bitcoin/pull/32084
<bitcoin-git>
[bitcoin] maflcko opened pull request #32488: fuzz: Properly setup wallet in wallet_fees target (master...2505-fuzz-fix) https://github.com/bitcoin/bitcoin/pull/32488