<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] 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
<pinheadmz>
the main moderaiton problems we had with comments on the first PR is questions like "is concept NACK a technical argument with no other substance?" and are comments like "no more spam on bitcoin" duplicates since they add no new information
<vasild>
IMO the current handling of OP_RETURN on Bitcoin Core side is technically sound, but a PR (as in public relationship) nightmare. That's logical - we are developers, not PR people...
<bitcoin-git>
[bitcoin] achow101 opened 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
<laanwj>
sliv3r__: they're intentionally not on the site, to not clutter the documentation with a lot of commands that aren't useful to end users, but bitcoind itself knows about them: `bitcoin-cli help <command>`
<bitcoin-git>
[gui-qml] hebasto closed pull request #434: Move various state computations from the UI to the NodeModel (main...compute-states-in-nodemodel) https://github.com/bitcoin-core/gui-qml/pull/434
<bitcoin-git>
[bitcoin] theuni opened 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
<bitcoin-git>
[bitcoin] theuni opened pull request #32466: threading: drop CSemaphore in favor of c++20 std::counting_semaphore (master...modernize-semaphore) https://github.com/bitcoin/bitcoin/pull/32466
<bitcoin-git>
[bitcoin] theuni opened pull request #32465: thread-safety: fix annotations with REVERSE_LOCK (master...fix-reverselock) https://github.com/bitcoin/bitcoin/pull/32465
2025-05-09
<bitcoin-git>
[bitcoin] achow101 merged pull request #32155: miner: timelock the coinbase to the mined block's height (master...2502_height_in_cb_locktime) https://github.com/bitcoin/bitcoin/pull/32155
<bitcoin-git>
bitcoin/master c76dbe9 Antoine Poinsot: qa: timelock coinbase transactions created in fuzz targets
<bitcoin-git>
bitcoin/master 9c94069 Antoine Poinsot: contrib: timelock coinbase transactions in signet miner
<bitcoin-git>
bitcoin/master a5f52cf Antoine Poinsot: qa: timelock coinbase transactions created in functional tests
<corebot>
https://github.com/bitcoin/bitcoin/issues/29136 | wallet: `addhdkey` RPC to add just keys to wallets via new `unused(KEY)` descriptor by achow101 · Pull Request #29136 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] ismaelsadeeq opened pull request #32463: test: fix an incorrect `feature_fee_estimation.py` subtest (master...05-2025-fix-incorrect-fee-estimator-test) https://github.com/bitcoin/bitcoin/pull/32463
<bitcoin-git>
[bitcoin] l0rinc opened 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] andrewtoth opened pull request #32451: contrib: add xor-blocks tool to obfuscate blocks directory (master...xor-blocks) https://github.com/bitcoin/bitcoin/pull/32451
<bitcoin-git>
[bitcoin] fanquake opened pull request #32450: randomenv: remove some `/proc/` accesses (master...remove_randomenv_proc) https://github.com/bitcoin/bitcoin/pull/32450
<_aj_>
laanwj: work out whether the bitcoin core logo is black (x.com/bitcoincoreorg, github.com/bitcoin) or orange (github.com/bitcoin-core, bitcoincore.org)...
<_aj_>
laanwj: change the display name to "Bitcoin Core", add links to other resources/clients in the org description
<laanwj>
we could also move everything from bitcoin-core to bitcoin instead lol
<kanzure>
tons of users have been completely fooled by bitcoin.com
<fjahr>
Murch[m]: we still have headaches to not loose bitcoin/bitcoin so the org split isn't really going away imo and the third is philosophical. Seemed to me that the first issue was what started this discussion and bothered people the most. That's why it seemed like the highest priority to me.
<kanzure>
we have absolutely not coped well with bitcoin.com are you kidding me
<_aj_>
Murch[m]: (we've coped pretty well with bitcoin.com, bitcoin.org, twitter.com/bitcoin, reddit.com/bitcoin not necessarily being "bitcoin", why should github.com/bitcoin be that different?)
<bitcoin-git>
[bitcoin] furszy opened pull request #32449: wallet: init, don't error out when loading legacy wallets (master...2025_init_skip_legacy_wallets) https://github.com/bitcoin/bitcoin/pull/32449
<Murch[m]>
It would fix that bans by Bitcoin Core affect BIPs, but it would not fix the org split that Bitcoin Core has currently, nor disclaim that Bitcoin Core is Bitcoin
<stickies-v>
kanzure: we could purposefully break the redirect in x years to ensure any people still relying on bitcoin/bitcoin move, almost entirely eliminating the hostile takeover risk
<kanzure>
_aj_: unfortunately gh namespace 'bitcoin' owners have essentially a moral obligation to not abandon it to the wolves due to long-term security issues, such as release spoofing, tag spoofing, issue rewriting, comment rewriting... etc.
<hodlinator>
I think it might help perception to "concede" that bitcoin-core is not bitcoin, but it's hard to predict.
<jonatack>
FWIW, I don't see how anti-core sentiment would be further fueled by moving to bitcoin-core
<laanwj>
in a way moving bips is more controversial than moving bitcoin core, as bips does belong with the global network/blockchain and is shared between implementations
<_aj_>
"bitcoin org is the network, not an implementation" doesn't really match the "but we'll keep bitcoin/bitcoin pointing at bitcoin-core/whatever forever"
<jonatack>
achow101: bitcoin-core/bitcoin-core sgtm too
<achow101>
jonatack: shall we bikeshed the name of the repo? I prefer bitcoin-core/bitcoin-core
<jonatack>
"may indeed be a good idea" -> bips migration to bitcoin-bips