<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>
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
<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
<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 810476f Ava Chow: test: Remove unused options and variables, correct comments
<bitcoin-git>
bitcoin/master 04a7a7a Ava Chow: build, wallet, doc: Remove BDB
<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 84de8c9 Hennadii Stepanov: ci: Add `deploy` target for native macOS CI job
<bitcoin-git>
bitcoin/master fad57e9 Hennadii Stepanov: build: Fix `macdeployqtplus` after switching to Qt 6
<bitcoin-git>
bitcoin/master 938208d Hennadii Stepanov: build: Resolve `@rpath` in `macdeployqtplus`
<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/master 22cff32 Sjors Provoost: doc: recommend gmake for FreeBSD
<bitcoin-git>
bitcoin/master b645c52 Sjors Provoost: doc: recommend modern make for macOS depends
<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
<bitcoin-git>
[bitcoin] maflcko opened pull request #32417: doc: Explain that .gitignore is not for IDE-specific excludes (master...2505-gitignoreignore) https://github.com/bitcoin/bitcoin/pull/32417
<bitcoin-git>
[bitcoin] theStack opened pull request #32415: scripted-diff: adapt script error constant names in feature_taproot.py (master...202505-test-adapt_consensus_error_constants) https://github.com/bitcoin/bitcoin/pull/32415
<bitcoin-git>
[bitcoin] andrewtoth opened pull request #32414: validation: periodically flush dbcache during reindex-chainstate (master...reindex-flush) https://github.com/bitcoin/bitcoin/pull/32414
<bitcoin-git>
[bitcoin] rkrux opened pull request #32413: test: test that descriptorprocesspsbt removes non witness utxos in PSBT (master...descriptorprocesspsbt) https://github.com/bitcoin/bitcoin/pull/32413
<vasild>
yeah, I was just thinking about that - if Bitcoin Core is a typical software project, then its developers are dictators and do as they see fit. Disagreeing people are free to fork it and change it according to their taste.
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400
2025-05-01
<badkat>
can anybody guide me to get into bitcoin network again? my last interaction to this blockchain was in 2013
<bitcoin-git>
[bitcoin] Brotcrunsher opened pull request #32397: doc: Add hint about avoiding spaces in paths when building on Windows (master...HintNoSpace) https://github.com/bitcoin/bitcoin/pull/32397
<BlueMatt[m]>
Murch[m]: sure, if you want someone who doenst work on bitcoin core i can :)
<BlueMatt[m]>
yea, letting this slip into the next release is really not okay, there's very nontrivial cost to the bitcoin system
<Sjors[m]>
And more practically, it means several rounds of bitcoin podcasts can go through the issue and hopefully convince more people.
<jonatack>
lightlike: i think the process hasn't helped in this case, as willcl-ark wrote in bitcoin/meta a couple hours ago
<Murch[m]>
pinheadmz: okay sure, but there do seem to be some people here that don’t seem to support dropping the limit, so I’m not sure Bitcoin Core can put out a blog post. Where would this be posted and by whom?
<jonatack>
perhaps consider spending time exlaining the issues involved to the outer community, if perception of bitcoin core is a criteria
<darosior>
Storm in a tea pot. I don't think we should give in to bullies and do what we believe is good for actual Bitcoin Core and Bitcoin network users, ie the silent majority. I think we should merge Todd's PR and call it a day.
<vasild>
I guess the most liberal is to have this configurable in Bitcoin Core so users can set whatever mempool policy they wish. This way Bitcoin Core developers will not be perceived as imposing their views on the node operators.
<jonatack>
I think the BIPs case is separate from the bitcoin core one.
<Murch[m]>
glozow: Yeah, I think the ownership being retained by Bitcoin Core maintainers is understood
<TheCharlatan>
yeah, but you end up with either bitcoin or bitcoin-core on your machine.
<jonatack>
I agree the project owners in bitcoin/ would not need to be changed.
<TheCharlatan>
I'd like to keep /bitcoin. It would also make easier to maintain any existing cloning documentation, i.e. no need to handle the renamed dir.
<laanwj>
bitcoin-core/bitcoin-core sgtm
<achow101>
cfields: I think the general sentiment is that the current owners of bitcoin/ will remain so, and no new ones will be added, regardless of any moves
<stickies-v>
Murch[m]: but the bip editor's can't get ban permissions in the bitcoin org?
<Murch[m]>
Some BIP Editors appear to think that the bitcoin org is the correct place for BIPs while Bitcoin Core should move out. Others seem fine with the move.
<achow101>
TheCharlatan: we can bikeshed that.. I like bitcoin-core/bitcoin-core
<TheCharlatan>
what will be the name of the repo in the bitcoin-core org?
<vasild>
did anything happen with the bip repo in the meantime, e.g. did bip people decide to move it away from bitcoin/bips?
<_aj_>
fanquake: find .bitcoin/blocks/index -printf "%s\n" | (x=0; while read a; do x=$(($x+$a)); done; echo $((x/1024/1024)) )
<bitcoin-git>
[bitcoin] hebasto opened pull request #32396: cmake: Add application manifests when cross-compiling for Windows (master...250501-app-manifest) https://github.com/bitcoin/bitcoin/pull/32396
<bitcoin-git>
[bitcoin] ismaelsadeeq opened pull request #32395: fees: rpc: `estimatesmartfee` now returns a fee rate estimate during low network activity (master...04-2025-fee-estimate-with-low-network-activity) https://github.com/bitcoin/bitcoin/pull/32395