💬 instagibbs commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#issuecomment-3397331200)
reACK 023cd5a5469ad61205bf7bb1135895f2b4a20ea9

`git range-diff master 7421e58dee402ee8b5b58a18684953a89ad350d7 023cd5a5469ad61205bf7bb1135895f2b4a20ea9`

👍 willcl-ark approved a pull request: "doc: archive release notes for v30.0"
(https://github.com/bitcoin/bitcoin/pull/33601#pullrequestreview-3331448273)
ACK 8d6e49158e3a1b3215484b5d139c5d8a3fffc4c9

This archive is OK.

I do notice that we seem to have zero `Build System` notes though, which is slightly sad. New binaries (which could have been in this section) have their own section, but perhaps we miss detailing capnproto dependency.

💬 instagibbs commented on issue "test: intermittent issue in p2p_1p1c_network.py":
(https://github.com/bitcoin/bitcoin/issues/33318#issuecomment-3397358091)
I don't think the pre-received child peer(s) make sense anymore, as we intentionally zero these out of the orphanage when all the announcing peers disconnect.

If we want to keep this part just to exercise that state space, we could make sure that we wait until all the node's orphan slots are empty via rpc before continuing with the ultimate submitpackage?

🚀 fanquake merged a pull request: "doc: archive release notes for v30.0"
(https://github.com/bitcoin/bitcoin/pull/33601)

💬 fanquake commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3397400978)
Rel notes archived in #33601 & GH release: https://github.com/bitcoin/bitcoin/releases/tag/v30.0.

✅ fanquake closed an issue: "Release Schedule for 30.0"
(https://github.com/bitcoin/bitcoin/issues/32275)

🚀 fanquake merged a pull request: "ci: Use native platform for win-cross task"
(https://github.com/bitcoin/bitcoin/pull/33558)

💬 fanquake commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#issuecomment-3397429669)
Kicked all the unrelated failures.

⚠️ fanquake unpinned an issue: "Release Schedule for 30.0"
(https://github.com/bitcoin/bitcoin/issues/32275)
Here is a proposed release schedule for `v30.0`, the next major release of Bitcoin Core. The dates are set to target a release in early October.

## 2025-08-06 :heavy_check_mark:
- Open Transifex translations for `v30.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v28.0`

## 2025-08-20 :heavy_check_mark:
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language change
...

⚠️ fanquake opened an issue: "Release Schedule for 31.0"
(https://github.com/bitcoin/bitcoin/issues/33607)
Here is a proposed release schedule for `v31.0`, the next major release of Bitcoin Core.
The dates are set to target a release in early April.

## 2026-02-06 :construction:
- Open Transifex translations for `v31.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v29.0`

## 2026-02-20 :construction:
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until relea
...

⚠️ fanquake pinned an issue: "Release Schedule for 31.0"
(https://github.com/bitcoin/bitcoin/issues/33607)
Here is a proposed release schedule for `v31.0`, the next major release of Bitcoin Core.
The dates are set to target a release in early April.

## 2026-02-06 :construction:
- Open Transifex translations for `v31.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v29.0`

## 2026-02-20 :construction:
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until relea
...

💬 stickies-v commented on pull request "validation: Improve warnings in case of chain corruption":
(https://github.com/bitcoin/bitcoin/pull/33553#issuecomment-3397546214)
> In case of corruption that leads to a block being marked as invalid

Is the working assumption that the errors users are reporting in #26391 are due to disk corruption causing exactly the serialized `nStatus::BLOCK_FAILED_{VALID,CHILD}` bit to be flipped, causing the block to be loaded as invalid instead of valid, without causing any other corruption that would likely crash the application? Because while that wouldn't be impossible, it seems like an incredibly unlikely event to me?

⚠️ Waytoogo opened an issue: "Version 30 -datadir= not working"
(https://github.com/bitcoin/bitcoin/issues/33608)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

After installing version 30 the command line argument -datadir= for Bitcoin-qt.exe does not work on Windows. It keeps saying I don't have a wallet. I had to go back to version 29.1

### Expected behaviour

I expected it to load the data directory that I put in the command line.

### Steps to reproduce

Try to start Bitcoin-qt.exe with a the command line -datadir="C:\MyDataDirectory" or whe
...

💬 andrewtoth commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#issuecomment-3397616691)
I also measured the txindex with `-indexworkers=15` on a 32 vcpu machine and it was slightly slower than master.
I guess this makes sense since each thread needs to write the index data to leveldb, and the actual work done by the CPU is minimal (serializing then computing offsets). So each thread is waiting for the other threads to finish writing.
For blockfilter the filter computation is more intensive, and then each filter is written to a separate file. Only after the filter is written the l
...

💬 Waytoogo commented on issue "Version 30 `-datadir=` not working":
(https://github.com/bitcoin/bitcoin/issues/33608#issuecomment-3397625701)
Thank you for fixing the formatting. I'm not very good at this, but I wanted you guys to know about this problem.

💬 maflcko commented on issue "Version 30 `-datadir=` not working":
(https://github.com/bitcoin/bitcoin/issues/33608#issuecomment-3397643805)
Is there a warning about the wallet being BDB, and a suggestion to migrate it? If yes, my recommendation would be to backup the wallet (following your normal backup flow) and then migrate it, using v30.0.

💬 Waytoogo commented on issue "Version 30 `-datadir=` not working":
(https://github.com/bitcoin/bitcoin/issues/33608#issuecomment-3397660956)
No it's just not taking the -datadir= command. In older versions if I put a wrong directory in the command it will tell me the directory does not exist and won't start bitcoin. The new version just starts and completely ignores the -datadir= command and is trying to use the default directory.

💬 maflcko commented on issue "Version 30 `-datadir=` not working":
(https://github.com/bitcoin/bitcoin/issues/33608#issuecomment-3397711941)
Do you have more precise steps to reproduce? Include the full command and the full output for 29.x and 30.x, please.

It works locally:

```
bitcoin-qt -datadir=/tmp/does_not_exist
Error: Specified data directory "/tmp/does_not_exist" does not exist.

💬 Waytoogo commented on issue "Version 30 `-datadir=` not working":
(https://github.com/bitcoin/bitcoin/issues/33608#issuecomment-3397779269)
Yes now that I play with it more, it is opening my data directory, it just doesn't see my wallet. It says
"No wallet has been loaded. Go to File > Open Wallet to load a wallet. If I do that it says [default wallet] [needs migration]. should I click on that and let it migrate my wallet? I didn't know it needed migration. I'm backing everything up before I do anything else.

🤔 pablomartin4btc reviewed a pull request: "qt: add createwallet, createwalletdescriptor, and migratewallet to history filter"
(https://github.com/bitcoin-core/gui/pull/901#pullrequestreview-3331886096)
utACK 4e352efa2ce756c668664486c99d003eef530e0c

_(_`historyFilter` _was originally added in https://github.com/bitcoin/bitcoin/pull/8877)_