<dviola>
11GB, that's not a lot, I guess the chainstate gets rebuilt every time bitcoin core finishes syncing?
<dviola>
I was pretty impressed when I synced bitcoin core for the first time on a dual core PC (E5500 CPU + 2GB RAM)... I'm still not sure whether the slowdown I experienced was disk related or filesystem related but I did notice some slowdown when having the chainstate on SATA SSD
<Earnestly>
dviola: Fwiw, it'd all just live in a micro form factor pc of some description. bitcoin core doesn't really need much in the ways of specs. I have even sync'd the block chain on an rpi 2b not so long ago, it just takes awhile. (My internet isn't that fast anyway)
<bitcoin-git>
[bitcoin] theStack opened pull request #32645: fs: use `ftruncate` in `AllocateFileRange` on OpenBSD (master...202505-fs-use_ftruncate_on_openbsd) https://github.com/bitcoin/bitcoin/pull/32645
<bitcoin-git>
[bitcoin] fanquake merged pull request #32619: wallet, rpc, gui: List legacy wallets with a message about migration (master...dont-list-legacy-wallets) https://github.com/bitcoin/bitcoin/pull/32619
<bitcoin-git>
bitcoin/master 0995517 Ava Chow: wallet, rpc: Give warning in listwalletdir for legacy wallets
<bitcoin-git>
bitcoin/master f3a444c Ava Chow: gui: Disallow loading legacy wallets
<bitcoin-git>
bitcoin/master b933813 merge-script: Merge bitcoin/bitcoin#32619: wallet, rpc, gui: List legacy wallets with a ...
<bitcoin-git>
bitcoin/master b1ea542 Greg Sanders: test: test MAX_SCRIPT_SIZE for block validity
<bitcoin-git>
bitcoin/master 5471e29 Ava Chow: Merge bitcoin/bitcoin#32304: test: test MAX_SCRIPT_SIZE for block validity
<_aj_>
sipa: i thought we were going for X is the year of a bitcoin full node on your phone?
<sipa>
2025 will the year of Bitcoin on the desktop
<gmaxwell>
Earnestly: It should just be wiped with a "go over here" pointer on it, I think. Bitcoin isn't the kind of obscure project dying for the last possible user that it matters if someone gets lost on the way.
<gmaxwell>
I hope bitcoin core gets off of it some day.
<gmaxwell>
When people in those PRs who *might* have been otherwise seen as brigading actually argued their points, they got reasoned replies. E.g. https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2874791860 in my comment on instagibbs PR I took the time to specifically respond to points of k98kurz, who is someone I've never seen before, and might have guessed was there only due to being
<gmaxwell>
If someone reads the realy policy thing, understands it, and disagrees with it-- well then thats a fine reason for them to just not us bitcoin core as it's being designed/maintained with values in mind that they don't agree with.
<bitcoin-git>
[bitcoin] ryanofsky opened pull request #32641: Update libmultiprocess subtree to fix clang-tidy errors (master...pr/subtree-2) https://github.com/bitcoin/bitcoin/pull/32641
<gmaxwell>
dzxzg: it's also a big time and energy saver ultimately, like no need to have a quarterly useless debate PR by PR over questions that are answered by the policy doc. Which makes it easier to actually set a forward direction. E.g. project collectively has a vision for the kind of bitcoin its building for. I mean I think it always has, but it's not always well communicated.
<dzxzg>
Why does every last person need to be convinced? At the extreme end, the brigadiers are not hearing any one out in good faith, and the majority in the middle are probably just gawking at the spectacle. I think it would be more productive to spend resources/time communicating a positive vision(s) of the future of Bitcoin Core (Kernel, Erlay, Multiprocess, Cluster mempool, Stratum V2, Package Relay, etc. etc.) instead of trying to put out fires started
<dzxzg>
Why does every last person need to be convinced? At the extreme end, the brigadiers are not sincerely interested in changing their minds, and the majority in the middle are probably just gawking at the spectacle. I think it would be more productive to spend resources/time communicating a positive vision of the future of Bitcoin Core instead of trying to put out fires by people that are started by people that just want to throw sand into gears
<johnny9dev>
Since last meeting, The QR code component was merged in bitcoin-core/gui-qml#454, Initial loading animations were merged in (bitcoin-core/gui-qml#455 and bitcoin-core/gui-qml#459), and a minor compile error fixed bitcoin-core/gui-qml#458.
<johnny9dev>
I also undrafted the multiple recipients PR as the core functionality is working now (bitcoin-core/gui-qml#450)
<bitcoin-git>
[bitcoin] l0rinc opened pull request #32638: blocks: force hash validations of blocks read from disk explicit (master...l0rinc/read-block-hash-check) https://github.com/bitcoin/bitcoin/pull/32638
<bitcoin-git>
[bitcoin] fanquake merged pull request #32634: build: Add resource file and manifest to `bitcoin.exe` (master...250528-bitcoin-rc) https://github.com/bitcoin/bitcoin/pull/32634
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32636: Split `CWallet::Create()` into `CreateNew` and `LoadExisting` (master...5-27-2025-create-refactor) https://github.com/bitcoin/bitcoin/pull/32636
<bitcoin-git>
bitcoin/master 4df4df4 Martin Zumsande: test: fix sync function in rpc_psbt.py
<bitcoin-git>
[bitcoin] hebasto opened pull request #32634: build: Add resource file and manifest to `bitcoin.exe` (master...250528-bitcoin-rc) https://github.com/bitcoin/bitcoin/pull/32634
<bitcoin-git>
[bitcoin] hebasto opened pull request #32633: windows: Use predefined `RC_INVOKED` macro instead of custom one (master...250528-rc-invoked) https://github.com/bitcoin/bitcoin/pull/32633
<bitcoin-git>
[bitcoin] brunoerg opened pull request #32632: wallet: sqlite: there is no need to have exclusive locking when mocking (master...2025-05-wallet-sqlite) https://github.com/bitcoin/bitcoin/pull/32632
<bitcoin-git>
[bitcoin] marcofleon opened pull request #32631: refactor: Convert GenTxid to `std::variant` (master...2025/05/gentxid-variant) https://github.com/bitcoin/bitcoin/pull/32631
<bitcoin-git>
[bitcoin] theStack opened pull request #32621: contrib: utxo_to_sqlite.py: add option to store txid/spk as BLOBs (master...202505-utxo-to-sqlite_blobs) https://github.com/bitcoin/bitcoin/pull/32621
2025-05-26
<gmaxwell>
I'm pretty sure I lost a few bitcoin a decade ago by BDB just deciding to strip everything out of some corrupted file.
<phantomcircuit>
gmaxwell: bdb will write log files into the ~/.bitcoin directory, if you happen to copy the .dat file when it's doing that you'll get corruption that's fixable with db_dump -R, but which iirc basically deletes records until the database is consistent
<bitcoin-git>
[gui] achow101 opened pull request #877: gui: Add a menu action to restore then migrate a legacy wallet (master...gui-migrate-path) https://github.com/bitcoin-core/gui/pull/877
<gmaxwell>
I'm finding now that good brand sata/nvme SSDs that sat in a closet for 5 years are full of errors, so I assume this also means a lot of earlier bitcoin users might be finding their older wallets harder to recover.
<bitcoin-git>
[bitcoin] achow101 opened pull request #32620: wallet: Fix wallet interface detection of encrypted wallets (master...fix-gui-migrate-encrypted) https://github.com/bitcoin/bitcoin/pull/32620
<gmaxwell>
but it also only outputs a legacy wallet, which doesn't directly work with bitcoin core anymore.
<bitcoin-git>
[bitcoin] achow101 opened pull request #32619: wallet, rpc, gui: List legacy wallets with a message about migration (master...dont-list-legacy-wallets) https://github.com/bitcoin/bitcoin/pull/32619
<bitcoin-git>
[bitcoin] achow101 opened pull request #32618: wallet: Remove ISMINE_WATCHONLY and watchonly from RPCs (master...delete-ismine-watchonly) https://github.com/bitcoin/bitcoin/pull/32618
<bitcoin-git>
[bitcoin] w0xlt opened pull request #32617: [Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2 (master...secp256k1_hpke) https://github.com/bitcoin/bitcoin/pull/32617
2025-05-25
<bitcoin-git>
[bitcoin] tnndbtc opened pull request #32615: fee estimate test: fix #31944 by handling a legitimate scenario that … (master...fix-fee-estimation-test) https://github.com/bitcoin/bitcoin/pull/32615
<Krellan>
smart, that makes more sense then, settings.json dynamically written, bitcoin.conf static as written by user
<dzxzg>
*user configuration in bitcoin.conf
<dzxzg>
settings.json is a file that is read from and written into at runtime by bitcoin Core, and is modified by using the GUI and some RPC's, overwriting user configuration files in bitcoin.conf would not have been a good solution, you can read more about the tradeoffs behind the design of settings.json here: https://github.com/bitcoin/bitcoin/pull/15935#issuecomment-490641194
<Krellan>
i will try that, removing it from settings.json (why is there a settings.json anyway when there's a bitcoin.conf)
<Krellan>
I tried making a directory and copying the wallet.dat file in manually. That just gave me an error upon starting bitcoin again: the wallet was in legacy format which is no longer allowed, then it exited before giving me the chance to migrate it.
<Krellan>
Thanks. How does "Migrate wallet" populate the list? I thought it was just subdirectories in the bitcoin datadir. It doesn't appear in "Open wallet" either, it's a loose file I have.
<bitcoin-git>
[bitcoin] benthecarman opened pull request #32607: rpc: Note in fundrawtransaction doc, fee rate is for package (master...fundawtx-pkg-doc) https://github.com/bitcoin/bitcoin/pull/32607
<bitcoin-git>
[bitcoin] davidgumberg opened pull request #32606: p2p: Drop unsolicited CMPCTBLOCK from non-HB peer (master...5-23-25-ignore-unsolicited) https://github.com/bitcoin/bitcoin/pull/32606
<bitcoin-git>
[bitcoin] Crypt-iQ opened pull request #32604: log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError (master...log_ratelimiting_05192025) https://github.com/bitcoin/bitcoin/pull/32604
<bitcoin-git>
[bitcoin] achow101 merged pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
<bitcoin-git>
bitcoin/master db465a5 Sebastian Falbesoner: wallet, rpc: remove obsolete "keypoololdest" result field/code
<bitcoin-git>
bitcoin/master 7a05f94 Sebastian Falbesoner: rpc: doc: drop descriptor wallet mentions in fast wallet rescan related RP...
<bitcoin-git>
bitcoin/master e5cbea4 Sebastian Falbesoner: rpc: doc: remove redundant "descriptors" parameter in `createwallet` examp...
<bitcoin-git>
[bitcoin] mzumsande closed pull request #31714: validation: Do less work in NeedsRedownload (master...202501_simpler_segwit_check) https://github.com/bitcoin/bitcoin/pull/31714
<bitcoin-git>
[bitcoin] hebasto reopened pull request #32577: subprocess: Let shell parse command on non-Windows systems (master...250521-subprocess-split) https://github.com/bitcoin/bitcoin/pull/32577
<gmaxwell>
I think in general private wallet use is an important area, since just using a wallet privately is a big reason to use bitcoin core. Essentially all other wallet approaches (except perhaps obscure ones) end up identifying you to third parties even when you're not sending a txn. Best you can do is use them over tor which has pretty significant limitations for long lived usage.
<bitcoin-git>
[bitcoin] rkrux opened pull request #32603: wallet, rpc: clarify wallet version in getwalletinfo help (master...wallet-version) https://github.com/bitcoin/bitcoin/pull/32603
<gmaxwell>
I stumbled into this somewhat old PR https://github.com/bitcoin/bitcoin/issues/28272 I think it's a moderately severe privacy problem. Consider a wallet in blocksonly mode. An attacker can race to send it an unsolicited compact block to determine what transactions the node sent. There is a straightforward fix: drop or treat as header messages any compact block where you hadn't asked the peer
<bitcoin-git>
[bitcoin] marcofleon opened pull request #32602: fuzz: Add target for coins database (master...2025/05/coins-view-db-fuzztest) https://github.com/bitcoin/bitcoin/pull/32602
<bitcoin-git>
[bitcoin] hebasto closed pull request #32577: subprocess: Let shell parse command on non-Windows systems (master...250521-subprocess-split) https://github.com/bitcoin/bitcoin/pull/32577
<bitcoin-git>
[bitcoin] hebasto opened pull request #32601: test: Fix `system_tests/run_command` test (master...250523-run-comand-test) https://github.com/bitcoin/bitcoin/pull/32601
<bitcoin-git>
[bitcoin] achow101 opened pull request #32598: walletdb: Log additional exception error messages for corrupted wallets (master...loadwallet-log-runtime_error) https://github.com/bitcoin/bitcoin/pull/32598
<bitcoin-git>
[bitcoin] achow101 opened pull request #32597: wallet: Always set descriptor cache upgraded flag for new wallets (master...desc-cache-is-upgraded) https://github.com/bitcoin/bitcoin/pull/32597
2025-05-22
<w473rm3l0n>
I don't think any such post will make a difference, because some people are unhappy with the way bitcoin core development works and their concerns or perception go beyond just OP_RETURN.
<bitcoin-git>
[bitcoin] theStack opened pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
<bitcoin-git>
[bitcoin] achow101 opened pull request #32593: wallet, rpc: Move (Un)LockCoin WalletBatch creation out of RPC (master...improve-lockcoin-interface) https://github.com/bitcoin/bitcoin/pull/32593
<gmaxwell>
my comment about coinbase attributing bitcoin's decenteralization to anyone being able to open a pull request.
<gmaxwell>
implementations in Bitcoin today, the thing that replaced the BCH 'reference implementation' was created in response to the adverse change)
<gmaxwell>
I dunno how to manage it though because all this openness and inclusiveness are fantastic tools for making good software, and also important to people's good feelings towards the project. But they just simply can't be where Bitcoin's security comes from.
<gmaxwell>
'cause at the day it's not the developers being great people that protects bitcoin (thoug they are!) -- great people can still have guns held to their heads (figuritively or litterally!) or can go crazy.
<gmaxwell>
one of the few positive oppturnities in this recent turmoil I think is an chance for people to learn to apply a diff and run a patched copy. That's a skill that any serious bitcoin power user ought to have. and while (IMO) completely unjustified for the current issue, it's exactly what people might need to do in the face of an adverse change.
<gmaxwell>
The fact that the current alternatives aren't so impressive is just a product that they are driven by their own motivations that don't have much/anything to do with specific bad choices in bitcoin core.
<gmaxwell>
lightlike: re serious alternatives: the code the user is running *right now* is a serious alternative to a future release. A future release with whatever adverse change backed out is a serious alternative -- even a moderately technical user can now reverse apply a diff and build bitcoin core with the help of an LLM. :) And of course people will make alternatives. And especially if the issue
<gmaxwell>
So at least for that specific purpose, it would have been better if contributing.md just said "Stuff goes in here if Achow likes it, you can use this repo if you like it, otherwise take a hike" :P ... cause if coinbases lawyers saw that they'd go okay obviously *this* isn't where bitcoin's properties arise. And instead would have made the case that no one controls the software users run and in
<gmaxwell>
So I agree to you to at least that extent. But I've absolutely seen it go wrong, including e.g. one coinbase filing in litigation explaining that bitcoin was decenteralized because anyone can make a pull request. ... and I don't really blame coinbase, it's easy to see how the very elaborate pesudogovernmental procedures in the project got mistaken for the origin of Bitcoin's properties.
<bitcoin-git>
[bitcoin] theuni opened pull request #32592: threading: remove ancient CRITICAL_SECTION macros (master...remove-critsect) https://github.com/bitcoin/bitcoin/pull/32592
<gmaxwell>
I think I feel somewhat the opposite, the whole point of bitcoin is defeated if other people control your usage. So trying to act like a pseudogovernment isn't in Bitcoin's interest, as some people will mistake the pomp and circumstance of power with actual power that should not and must not exist.
<lightlike>
gmaxwell: that is certainly what open source projects in general should default to - but even if in theory everyone can run their own software, in practice bitcoin core is still the de-facto reference implementation, which makes it a bit unique. As long as most other node impls are not serious alternatives I'd argue that implies at least some additional responsibilities other projects don't have - only up to some point though (e.g. we
<gmaxwell>
and this is my view because simply if it doesn't work that way it will be replaced with something that does. Exactly like this IRC channel, which functionally replaced #bitcoin-dev, because the other wasn't maintained in a way that preserved the participation of the major participants.
<gmaxwell>
The underlying principle I, personally, would keep in mind is that the repository exists so that its significant contributors can collaborate and produce the best bitcoin software they can. It does not exist to be fair, inclusive, friendly, to anyone -- except to the (very significant!) extent that those things help to produce good bitcoin software.
<gmaxwell>
lightlike: to clarify the 'asked to leave' comment from earlier. In watching PRs and bitcoin related traffic on social media, I've seen repeated participation from people who are overtly hostile to the project, it's activities, and contributors... including stuff that would get them immediately ejected from any professional enviroment. And while constructive criticism about proposals is
<bitcoin-git>
[bitcoin] fanquake merged pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
<bitcoin-git>
bitcoin/master fa07953 MarcoFalke: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task
<bitcoin-git>
[bitcoin] fanquake merged 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
<glozow>
perhaps unpopular opinion, but maybe the website repo should have stricter contribution requirements than the bitcoin/bitcoin repo
<TheCharlatan>
"> Note that this is not condoning non-financial data block space usage." this is what the issue seems to boil down to for users of Bitcoin Core, but I feel like this is not clear enough.
<sipa>
I've written a short statement about the relation between Bitcoin Core developments and transaction relay policy, with the help of darosior and glozow
<hebasto>
To improve our chances, I encourage anyone with a microsoft account to consider upvoting issue reports related to Bitcoin Core.
<hebasto>
To compile Bitcoin Core on Windows, there is currently only one supported option: MSVC.
<johnny9dev>
This week we onboarded a new contributor, goqusan. He will be helping implement the QML components in the wallet views. He's starting with the receive page and added QR encoding. bitcoin-core/gui-qml#454
<johnny9dev>
Christoph has been doing work on the Animations for the wallet and fixed the main transition easing with bitcoin-core/gui-qml#453
<johnny9dev>
For me, I implemented the initialization states for the WalletQmlController and added the first instance of the Skeleton loading animation that Christoph proposed last week. bitcoin-core/gui-qml#454
<johnny9dev>
This following week we'll be focused on getting bitcoin-core/gui-qml#450 mergable, implementing more of the Receive page, and adding input validation and error strings on to the Send page.
<corebot>
https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
<corebot>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] maflcko opened pull request #32588: util: Abort on failing CHECK_NONFATAL in debug builds (master...2505-abort-debug-check-nonfatal) https://github.com/bitcoin/bitcoin/pull/32588
<bitcoin-git>
[bitcoin] i-am-yuvi opened pull request #32587: [WIP] test: Fix reorg patterns in mempool tests to use proper fork-based approach (master...2025-05-update_test_reorg_behaviour) https://github.com/bitcoin/bitcoin/pull/32587
<bitcoin-git>
[bitcoin] maflcko opened pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
<bitcoin-git>
[bitcoin] fanquake merged pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400