<bitcoin-git>
[bitcoin] willcl-ark opened pull request #32798: build: add root dir to CMAKE_SYSTEM_PREFIX_PATH in toolchain (master...nix-cmake-fix) https://github.com/bitcoin/bitcoin/pull/32798
<bitcoin-git>
[bitcoin] HowHsu opened pull request #32791: checkqueue: implement a new scriptcheck worker pool with atomic variables (master...checkqueue_atomic) https://github.com/bitcoin/bitcoin/pull/32791
<bitcoin-git>
[bitcoin] yuvicc opened pull request #32790: rpc, test: allow multiple data outputs in `createrawtransaction` & `createpsbt` (master...2025-06-fix-multi-data-outs) https://github.com/bitcoin/bitcoin/pull/32790
<bitcoin-git>
[bitcoin] maflcko closed pull request #31492: Execute Discover() when bind=0.0.0.0 or :: is set (master...discover-bind) https://github.com/bitcoin/bitcoin/pull/31492
<bitcoin-git>
[bitcoin] hamed-ta opened pull request #32789: Fix critical integer overflow vulnerability in compact block handling (master...blockencodings-overflow-fix) https://github.com/bitcoin/bitcoin/pull/32789
<bitcoin-git>
[bitcoin] Sjors opened pull request #32784: wallet: derivehdkey RPC to get xpub at arbitrary path (master...2025/06/gethdkey) https://github.com/bitcoin/bitcoin/pull/32784
<bitcoin-git>
[bitcoin] willcl-ark opened pull request #32783: doc: Add fetching single PRs from upstream to productivity.md (master...fetch-pr-single) https://github.com/bitcoin/bitcoin/pull/32783
<bitcoin-git>
[bitcoin] willcl-ark opened pull request #32782: test: disable secp256 tests by default (master...disable-secp-tests-split) https://github.com/bitcoin/bitcoin/pull/32782
2025-06-19
<sipa>
TheCharlatan: perhaps, but even then i don't think it deserves the "bitcoin" label
<TheCharlatan>
sipa, r.e. kernel deserving to be treated differently. if it becomes the common codebase for a bunch of implementations, it would be equally weird in my eyes if it were still in the bitcoin-core org and not a shared codebase to some extent.
<marcofleon>
darosior: I think janb84 was saying it could be somehow misinterpreted as the "final step" in core taking control of bitcoin
<darosior>
janb84: you seem confused. The point is to move away from bitcoin/bitcoin toward bitcoin-core/bitcoin.
<achow101>
darosior: I have had a couple of people say to me "well if you guys aren't bitcoin, why are you using bitcoin/bitcoin", so I don't think it's incorrect to say that we would face less pressure
<darosior>
achow101: it seems the push to move is at least in part fueled by thinking we would face less pressure. I think this view is incorrect and falling into the fallacy that the Github repo matters to define what the Bitcoin network is.
<sipa>
but i don't see how bitcoin core not being under bitcoin/ would somehow mean we don't think people should use bitcoin core
<abubakarsadiq>
the redirect from /bitcoin/bitcoin indicates that Bitcoin core is the dominant implementation :P
<Murch[m]>
At this point, anything we do seems to be represented in pretty much every possible way as there are a substantial number of Bitcoin geeks producing podcasts and blog posts that are overinvested in the OP_RETURN thing…
<darosior>
I understand many (including me) are concerned with the confusion of Bitcoin and Bitcoin Core. However i don't think this means we should ignore the fact that anybody serious who wants to use Bitcoin today with real money on the line will want to use Bitcoin Core. Moving the repository is not going to change this reality.
<sipa>
who knows how things can be misinterpreted, of course, but logically, this is exactly moving away from the (understandable) misdirection someone might take from bitcoin core being under the bitcoin/ org
<janb84>
There is currently a view of certain people that "bitcoin-core" is trying to capture bitcoin, wouldn't moving the repo now bolster that viewpoint and give extra negative backlash ?
<Murch[m]>
dergoegge, I mean, you would not be looking at the bitcoin org anymore when browsing the repository, even if you got there originally by calling up the bitcoin org
<achow101>
dergoegge: any new links people generate will be the new repo. when you go to the old link, it automatically redirects you to the new repo which says "bitcoin-core/bitcoin-core" or whatever
<sipa>
the bitcoin/ repo isn't there to to direct people (as repos won't even show up under it) to a specific implementation, it's to redirect old historical usage that hasn't updated
<sipa>
dergoegge: that seems like a strawman to me; over time, people will start using the bitcoin-core repo
<sipa>
darosior, achow101: yeah, this argument applies far more to bitcoin.org vs bitcoincore.org, but there the naming is already correct
<achow101>
the redirect will be permanent, and the bitcoin org owners aren't going to change in order to ensure that no new bitcoin/bitcoin that breaks the redirect
<achow101>
darosior: I don't see at all how that is a possibility. links to bitcoin/bitcoin will redirect. when you go to the bitcoin org profile, there won't be a "bitcoin" repository under there. I highly doubt any new person is going to github.com/bitcoin and looking for the "bitcoin" repo when they want to start using Bitcoin
<sipa>
darosior: i understand the concern of "people who aren't familiar will search for bitcoin and be confused when they don't find a reference implementation under bitcoin/" i guess, but really, i find it categorically wrong for bitcoin core (or kernel, or any of its related projects) to somehow present itself as being "bitcoin", even though today - and hopefully for long in the future - it remains de
<maflcko>
I'd say bips moving (or not) shouldn't affect or concern whether to move /bitcoin
<fanquake>
well /bitcoin does need to exist, to host the bips repo
<sipa>
people can choose to use bitcoin core or not
<sipa>
darosior: no it doesn't, bitcoin core de facto does
<fanquake>
my point is that if /bitcoin is now meant to be neutral, why wouldn’t people ask for that?
<achow101>
fanquake: ideally we wouldn't need to have redirects, but there's way too many links to bitcoin/bitcoin that breaking them would be a bad idea
<darosior>
I think it would be highly inadvisable for us to link people to alternate implementations that are not consensus-compatible with what 99% of the Bitcoin network runs.
<sipa>
fanquake: ideally there'd be a bitcoin-bips/bips and a bitcoin-core/bitcoin etc, and the bitcoin/ org remains vestigial just to avoid name squatting and for redirect
<fanquake>
Regardless of any technical reasons, personally, I don’t think anything is gained by us trying to create some perception that doesn’t currently reflect reality. I think this is also undermined by the fact that we are just going to redirect to ourselves anyways (so where is the separation?) If we did drop an org level readme in /bitcoin, would we also be listing/linking to every other implementation in there? If not, that’d seem to
<sipa>
people thinking that BIPs are bitcoin core thing
<bitcoin-git>
[bitcoin] fanquake merged pull request #32765: test: Fix list index out of range error in feature_bip68_sequence.py (master...test-feature-bip68-fix) https://github.com/bitcoin/bitcoin/pull/32765
<bitcoin-git>
bitcoin/master e285e69 zaidmstrr: test: Fix list index out of range error in feature_bip68_sequence.py
<bitcoin-git>
bitcoin/master fa18304 merge-script: Merge bitcoin/bitcoin#32765: test: Fix list index out of range error in fe...
<bitcoin-git>
[bitcoin] hebasto opened pull request #32773: cmake: Create subdirectories in build tree in advance (master...250618-mkdir) https://github.com/bitcoin/bitcoin/pull/32773
<bitcoin-git>
[bitcoin] brunoerg opened pull request #32772: fuzz: wallet: remove `FundTx` from `FuzzedWallet` (master...2025-06-fuzz-delete-fundtx) https://github.com/bitcoin/bitcoin/pull/32772
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32771: contrib: tracing: Fix read of `pmsg_type` in p2p_monitor.py (master...6-18-25-p2p-mon-fix) https://github.com/bitcoin/bitcoin/pull/32771
<bitcoin-git>
[bitcoin] zaidmstrr opened pull request #32765: test: Fix list index out of range error in feature_bip68_sequence.py (master...test-feature-bip68-fix) https://github.com/bitcoin/bitcoin/pull/32765
<achow101>
#proposedmeetingtopic move the repo to bitcoin-core
<bitcoin-git>
[bitcoin] achow101 opened pull request #32763: wallet: Replace CWalletTx::mapValue and vOrderForm with explicit class members (master...cwallet-tx-rm-mapvalue-vorderform) https://github.com/bitcoin/bitcoin/pull/32763
<bitcoin-git>
[bitcoin] b-l-u-e opened pull request #32757: net: Fix Discover() not running when using -bind=0.0.0.0:port (master...net-fix-discover-bind-any) https://github.com/bitcoin/bitcoin/pull/32757
<bitcoin-git>
[bitcoin] maflcko reopened pull request #32685: wallet: Allow read-only database access for info and dump commands (master...wallet-readonly-access) https://github.com/bitcoin/bitcoin/pull/32685
<bitcoin-git>
[bitcoin] maflcko closed pull request #32685: wallet: Allow read-only database access for info and dump commands (master...wallet-readonly-access) https://github.com/bitcoin/bitcoin/pull/32685
<bitcoin-git>
[bitcoin] romanz opened pull request #32743: chore: use `std::vectorstd::byte` for `BlockManager::ReadRawBlock()` (master...read-raw-bytes) https://github.com/bitcoin/bitcoin/pull/32743
<bitcoin-git>
[bitcoin] theStack opened pull request #32742: test: fix catchup loop in outbound eviction functional test (master...202506-test-complete-catchup-loop-in-p2p_outbound_eviction) https://github.com/bitcoin/bitcoin/pull/32742
2025-06-12
<bitcoin-git>
bitcoin/master 6f1392c Ryan Ofsky: indexes, refactor: Remove remaining CBlockIndex* uses in index Rewind meth...
<bitcoin-git>
[bitcoin] achow101 merged pull request #32694: index: move disk read lookups to base class (master...2025_indexes_remove_CBlockIndex_access) https://github.com/bitcoin/bitcoin/pull/32694
<johnny9dev>
For myself, I've been focused on the current Send and Recieve PRs that are in review. I've also been making updates to how address inputs are handled, bitcoin amount label formatting, and address label formatting to get closer to the design spec.
<johnny9dev>
Significant progress was made this week on rebasing the project and moving it to CMake+Qt6. Both hebasto and pinheadmz have PRs now to test and fix issues with the update. bitcoin-core/gui-qml#470 bitcoin-core/gui-qml#472. Both PRs are now able to load up the QML app and get to the main navigation and views.
<vasild>
cfields: that would be like outsouring the indexing to the OS/filesystem, e.g. blocks/1/15/153/153764 (for block 153764). The question is can we do better than the worst OS/FS that is going to use Bitcoin Core, or even, better than the best FS?