<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 a5f52cf Antoine Poinsot: qa: timelock coinbase transactions created in functional tests
<bitcoin-git>
bitcoin/master 9c94069 Antoine Poinsot: contrib: timelock coinbase transactions in signet miner
<bitcoin-git>
bitcoin/master c76dbe9 Antoine Poinsot: qa: timelock coinbase transactions created in fuzz targets
<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/master 1656f6d Ava Chow: Merge bitcoin/bitcoin#32448: contrib: remove bdb exception from FORTIFY ch...
<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
<achow101>
kanzure: and currently it is duplicated work for bitcoin core to have the bans be the same on both orgs, if we actually did that
<laanwj>
jonatack: right; "bitcoin core" is a particular implementation, "bitcoin" is the network and block chain
<jonatack>
moving bitcoin/bitcoin to bitcoin-core/bitcoin or bitcoin-core/bitcoin-core seems the most philosophically correct
<_aj_>
if bips is going to auto-ban everyone bitcoin-core does, what's the point?
<pinheadmz>
isnt the whole point to separate bans between bips and bitcoin core ?
<kanzure>
not urgent at the moment but is there a way i could subscribe to bitcoin-core/ gh bans to auto-ban on the bips org to not duplicate that work
<sipa>
abubakarsadiq: bitcoin-core was always intended to move everything bitcoin-core-specific to, but the bitcoin/bitcoin repo just never got around to it
<laanwj>
i mean maybe, on the other hand it's always bad timing, there is always some drama in bitcoin
<glozow>
first pwuille is given up, then bitcoin... chaos
<laanwj>
no, we're not giving up the bitcoin org
<Murch[m]>
I thought it was pretty unanimous that control over the bitcoin org would not be given up
<laanwj>
having all code repositories under one org would be great and has been the plan pretty much since bitcoin-core org was created
<achow101>
why would bitcoin/ be given up?
<furszy>
I'm concerned about moving the repo, giving up ownership of /bitcoin due to some public drama in the future, and then the new /bitcoin owners recreating the repo with different source code.
<Murch[m]>
Still seems like a good idea to me. Maybe we should check with Bitcoin Twitter, though. They seem to think that we should run everything by them. :p
<achow101>
#topic moving the repo to bitcoin-core (take 3) (achow101)
<johnny9dev>
bitcoin-core/gui-qml#448 is complete and just waiting for one last validation and merge
<johnny9dev>
I opened up the first draft of sending to multiple recipients at bitcoin-core/gui-qml#450
<johnny9dev>
Contributor Gee has un-drafted AssumeUTXO snapshot loading bitcoin-core/gui-qml#424 and is looking for review. Related to that, he is also looking to contribute this work to the Qt widgets gui at bitcoin-core/gui#870
<bitcoin-git>
[leveldb-subtree] laanwj opened pull request #52: Revert "Increase maximum read-only mmap()s used from 1000 to 4096 on 64-bit systems" (bitcoin-fork...2025-05-revert-mmap-increase) https://github.com/bitcoin-core/leveldb-subtree/pull/52
<bitcoin-git>
[bitcoin] laanwj closed pull request #32447: [RFC] dbwrapper: Set global leveldb mmap limit (master...2025-05-leveldb-mmap-file-limit) https://github.com/bitcoin/bitcoin/pull/32447
<bitcoin-git>
[bitcoin] laanwj opened pull request #32447: [RFC] dbwrapper: Set global leveldb mmap limit (master...2025-05-leveldb-mmap-file-limit) https://github.com/bitcoin/bitcoin/pull/32447
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32442: doc: Add troubleshooting note about Guix on SELinux systems (master...5-7-25-guix-doc) https://github.com/bitcoin/bitcoin/pull/32442
<bitcoin-git>
bitcoin/master 04a7a7a Ava Chow: build, wallet, doc: Remove BDB
<bitcoin-git>
bitcoin/master 810476f Ava Chow: test: Remove unused options and variables, correct comments
<bitcoin-git>
bitcoin/master 84f671b Ava Chow: test: Run multisig script limit test
<bitcoin-git>
[bitcoin] fanquake opened pull request #32437: crypto: disable ASan for sha256_sse4 with Clang (master...extend_asan_sse4) https://github.com/bitcoin/bitcoin/pull/32437
<gmaxwell>
Yeah. I mean in general building is so easy once you have the prereqs installed I kind think interested powerusers should just compile for themselves... at least anyone already running it on a linux device. And nothing that can _run_ bitcoin core would be unable to compile it.
<gmaxwell>
Sjors[m]: it was occuring to me that it would be nice if these "bitcoin node" devices were setup so you could just drop patches in a directory and it would apply them if it could, run the tests, tell you the status.. making it easier for less developer-savvy users to just run patches. Hopefully they don't *need* to but like hopefully they don't *need* to run a node either. :P
<gmaxwell>
people in the Bitcoin-o-sphere... you see the same thing in other open source projects like the ffmpeg/libav split, or in other cryptocurrencies.
<gmaxwell>
Yeah, so I think for example bitcoin core repo could be killed by inclusive policy (or by being too insular but thats the opposite direction of its current challenges in my view) or by some toxic central figure or etc. But the result is that there would be something else which would eventually gather up the biggest collection of people who *can* collaborate. .. and it would be the obvious
<Sjors[m]>
gmaxwell: I indeed think that people assume the bitcoin repo is a public square, because Bitcoin Core is open source and there's been very little historical moderation on the repo.
<gmaxwell>
But when you agonize over kicking out people who can't control themselves or just give tiny little short blocks, you send the message that the repository is public property and that access to it is somehow integral to the freedom of bitcoin or something... and then every removal is a high crime.
<gmaxwell>
Sjors[m]: I think that document has caused a bit of confusion, like for example in one lawsuit Coinbase cited from it extensively as an explination as to why bitcoin is not controlled by 'bitcoin core developers', but I think that's a terrible example because the policy there doesn't actually really achieve that... particularly since anyone with control over the repo (ultimately MSFT) could
<bitcoin-git>
[bitcoin] fanquake merged pull request #32287: build: Fix `macdeployqtplus` after switching to Qt 6 (master...250416-macdeploy) https://github.com/bitcoin/bitcoin/pull/32287
<bitcoin-git>
bitcoin/master 938208d Hennadii Stepanov: build: Resolve `@rpath` in `macdeployqtplus`
<bitcoin-git>
bitcoin/master fad57e9 Hennadii Stepanov: build: Fix `macdeployqtplus` after switching to Qt 6
<bitcoin-git>
bitcoin/master 84de8c9 Hennadii Stepanov: ci: Add `deploy` target for native macOS CI job
<bitcoin-git>
[bitcoin] fanquake merged pull request #32086: Shuffle depends instructions and recommend modern make for macOS (master...2025/03/mc-make) https://github.com/bitcoin/bitcoin/pull/32086
<bitcoin-git>
[bitcoin] TheCharlatan opened pull request #32427: (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store (master...blocktreestore) https://github.com/bitcoin/bitcoin/pull/32427
<bitcoin-git>
[bitcoin] laanwj opened pull request #32423: rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory (master...2025-05-remove-rpcpassword-deprecation) https://github.com/bitcoin/bitcoin/pull/32423
<bitcoin-git>
[bitcoin] darosior closed pull request #32422: spam: trick Drahtbot into rendering a scammy link (master...2505_trick_drahtbot) https://github.com/bitcoin/bitcoin/pull/32422
<bitcoin-git>
[bitcoin] darosior opened pull request #32422: spam: trick Drahtbot into rendering a scammy link (master...2505_trick_drahtbot) https://github.com/bitcoin/bitcoin/pull/32422
<bitcoin-git>
[bitcoin] theStack opened pull request #32421: test: refactor: overhaul (w)txid determination for `CTransaction` objects (master...202505-test-remove_txid_caching) https://github.com/bitcoin/bitcoin/pull/32421
<bitcoin-git>
[bitcoin] polespinasa closed pull request #31177: rpc, logging: return "verificationprogress" of 1 when up to date (master...verificationProgress) https://github.com/bitcoin/bitcoin/pull/31177
<bitcoin-git>
[bitcoin] hebasto merged pull request #32417: doc: Explain that .gitignore is not for IDE-specific excludes (master...2505-gitignoreignore) https://github.com/bitcoin/bitcoin/pull/32417