📝 furszy opened a pull request: "wallet: init, don't error out when loading legacy wallets"
(https://github.com/bitcoin/bitcoin/pull/32449)
Instead of failing during initialization and shutting down the app when encountering a legacy wallet, skip loading the wallet and notify the user accordingly.

This allows users to access migration functionalities without needing to manually remove the wallet from settings.json or resort to using the bitcoin-wallet utility.

This means that GUI users will be able to use the migration button, and bitcoin-cli users will be able to call the migratewallet RPC directly after init.

💬 hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2863644963)
> Not sure about compiler specific changes, that rely on the presence of an undocumented environment variable (which we don't explicitly set as far as I can tell?), to make tests work properly.

It is documented, and it is pre-defined by CI itself:
- in [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables):
> `CI` | Always set to `true`.

- in [Cirrus CI](https://cirrus-ci.org/gui
...

💬 Sjors commented on pull request "doc: warn that CheckBlock() underestimates sigops":
(https://github.com/bitcoin/bitcoin/pull/31624#discussion_r2080084146)
Good catch, and this was helpful in figuring out the history...

💬 Sjors commented on pull request "doc: warn that CheckBlock() underestimates sigops":
(https://github.com/bitcoin/bitcoin/pull/31624#issuecomment-2863671202)
I expanded the comment to mention that p2sh isn't counted either.

I also added some history to the commit message. This seems to be a case of: none of the reviewers of #748 brought it up, but there were no reviewers :-)

Also rebased.

💬 ryanofsky commented on pull request "(RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store":
(https://github.com/bitcoin/bitcoin/pull/32427#issuecomment-2863677632)
re: TheCharlatan https://github.com/bitcoin/bitcoin/pull/32427#issuecomment-2859921949

Thanks for clarifying the situation with leveldb. I just assumed based on its design that it would support atomic updates pretty robustly but if it has corruption problems of its own then it doesn't sound like we would lose much by switching to something simpler.

I still do think using sqlite could be a nice solution because data consistency issues can be a significant source of pain for users and develo
...

💬 fanquake commented on pull request "build: simplify *ifaddr handling":
(https://github.com/bitcoin/bitcoin/pull/32446#issuecomment-2863689887)
Guix Build:
```bash
2d1c74e19e10c55a45e137f151f77f0e0628c96f0664949ba730c249e8065597 guix-build-ab878a7e7410/output/aarch64-linux-gnu/SHA256SUMS.part
26cb4ed3dcaf1bfc2d2f9cdc34e8648df11e2aed33bdeb8618a6d8a3370ba0e3 guix-build-ab878a7e7410/output/aarch64-linux-gnu/bitcoin-ab878a7e7410-aarch64-linux-gnu-debug.tar.gz
756e79f7a151b67edc7b607f4b3b0baa72025dbf7cc158e27485f885fbd6adc1 guix-build-ab878a7e7410/output/aarch64-linux-gnu/bitcoin-ab878a7e7410-aarch64-linux-gnu.tar.gz
4485cf2be98328ed
...

💬 w0xlt commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r2080112837)
Is this wallet watch-only (per commit description) ?

📝 fanquake opened a pull request: "randomenv: remove some `/proc/` accesses"
(https://github.com/bitcoin/bitcoin/pull/32450)
Any env data we try and gather is on a best-effort basis, however in this instance, for multiple users, it's just producing spam. This could probably be solved with further snap/apparmor configuration, however given that no-one is actively working on snap packaging, we could instead drop this source of env data.

Closes https://github.com/bitcoin-core/packaging/issues/115.
Also in https://github.com/bitcoin-core/packaging/issues/217.

Happy to close this if someone opens an alternative PR (
...

✅ fanquake closed an issue: "build: cmake --install fails after --target deploy"
(https://github.com/bitcoin/bitcoin/issues/32007)

💬 polespinasa commented on pull request "rpc: print P2WSH and P2SH redem Script in getrawtransaction":
(https://github.com/bitcoin/bitcoin/pull/31252#issuecomment-2863778040)
Rebased on top of master.

💬 ryanofsky commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#discussion_r2080173789)
re: https://github.com/bitcoin/bitcoin/pull/30221#discussion_r2073849511

Just to be clear I was suggesting moving both WriteBestBlock call and the [Flush](https://github.com/bitcoin/bitcoin/blob/baa848b8d38187ce6b24a57cfadf1ea180209711/src/wallet/wallet.cpp#L239) call into the destructor, because if you only move the WriteBestBlock call, it will happen after flushing, which seems incorrectly logically, though maybe it is ok if sqlite Flush is a no-op. I didn't look into the CI failures though
...

💬 laanwj commented on pull request "randomenv: remove some `/proc/` accesses":
(https://github.com/bitcoin/bitcoin/pull/32450#issuecomment-2863810274)
As i have some experience setting up apparmor i looked into this for a bit, but sadly it's not simply a matter of adding some apparmor rules. Snap works with larger sets of permissions like `system-observe` `process-control`. We likely want to avoid granting these to bitcoind just to collect random data.

💬 achow101 commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#discussion_r2080195154)
`Flush()` is deleted post #28710 as sqlite's `Flush()` is a no-op.

💬 achow101 commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r2080202804)
I believe it's necessary so that repeated calls to `CachedTxIsTrusted` that would now occur once for each TXO can be skipped early.

📝 andrewtoth opened a pull request: "contrib: add xor-blocks tool to obfuscate blocks directory"
(https://github.com/bitcoin/bitcoin/pull/32451)
I wrote a tool in Rust to xor the blocks directory with a random key. It was pointed out to me that there already exists some Rust code in contrib, so this might be a welcome addition to the toolkit here.

This lets you obfuscate the blocks blk.dat and rev.dat files if you synced with a version prior to v28.

It checks if a `xor.dat` file exists, and if it is zero it overwrites it with a non-zero random key. It then goes through each `*.dat` file in the blocks directory, checking if the firs
...

💬 ryanofsky commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#discussion_r2080204034)
> `Flush()` is deleted post #28710 as sqlite's `Flush()` is a no-op.

Thanks, makes sense. I had been looking to see if the Flush call was moved in the diff, but of course it's not because it doesn't exist anymore.

💬 davidgumberg commented on pull request "doc: Add troubleshooting note about Guix on SELinux systems":
(https://github.com/bitcoin/bitcoin/pull/32442#discussion_r2080204499)
Fixed, thanks.

💬 achow101 commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r2080206413)
It is not. That part of the test no longer exists after #28710. I've updated the commit message.

🤔 ismaelsadeeq reviewed a pull request: "qa: Verify clean shutdown on startup failure"
(https://github.com/bitcoin/bitcoin/pull/30660#pullrequestreview-2825834195)
Nice cleanup, although I have one comment on the new log of `stop_node`.

💬 ismaelsadeeq commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2080170811)
In "qa: Only allow calling TestNode.stop() after connecting" 9b24a403fae4b896ff7705519bd48c877b4e621b

I am not sure whether this new error message is better, I think I will prefer the previous one as there is a case where the test node has start without a cookie file, hence `wait_for_rpc_connection` should not even be called.

And when you call stop_node it will tell you that there is no RPC connection.