< July 2026 >
Su Mo Tu We Th Fr Sa 123456789101112131415 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
2025-05-08
<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
<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
<fjahr>
pinheadmz: Not sure if the ML is the right place for that bitcoin core meta discussion, so writing it here instead: Agree that it would be good to split conceptual and technical review but also skeptical the discussion post would get traction. And even if it did, people could still copy+paste their messages into the PR later.
<bitcoin-git>
[bitcoin] darosior closed pull request #32381: policy: allow more than one OP_RETURN outputs per tx (master...2504_fixthefiltersyo) https://github.com/bitcoin/bitcoin/pull/32381
<bitcoin-git>
[bitcoin] stratospher opened pull request #32385: test: add test for malleated transaction with valid witness (master...2025_04_tx_malleate) https://github.com/bitcoin/bitcoin/pull/32385
<bitcoin-git>
[bitcoin] achow101 merged pull request #32355: Bugfix: Miner: Don't reuse block_reserved_weight for "block is full enough to give up" weight delta (master...fix_block_full_enough) https://github.com/bitcoin/bitcoin/pull/32355
<bitcoin-git>
bitcoin/master 524f981 Luke Dashjr: Bugfix: Miner: Don't reuse block_reserved_weight for "block is full enough...
<bitcoin-git>
[bitcoin] achow101 merged pull request #31014: net: Use GetAdaptersAddresses to get local addresses on Windows (master...2024-10-windows-address-discovery) https://github.com/bitcoin/bitcoin/pull/31014
<bitcoin-git>
bitcoin/master b9d4d5f laanwj: net: Use GetAdaptersAddresses to get local addresses on Windows
<bitcoin-git>
bitcoin/master 0ed5f37 Ava Chow: Merge bitcoin/bitcoin#31014: net: Use GetAdaptersAddresses to get local ad...
<bitcoin-git>
[bitcoin] achow101 merged pull request #27826: validation: log which peer sent us a header (master...2023/05/saw-header) https://github.com/bitcoin/bitcoin/pull/27826
<bitcoin-git>
bitcoin/master bad7c91 Sjors Provoost: Log which peer sent us a header
<bitcoin-git>
bitcoin/master f9fa287 Sjors Provoost: Use LogBlockHeader for compact blocks
<bitcoin-git>
[bitcoin] darosior opened pull request #32381: policy: allow more than one OP_RETURN outputs per tx (master...2504_fixthefiltersyo) https://github.com/bitcoin/bitcoin/pull/32381