⚠️ zefir-k opened an issue: "prune shall not delete blocks it did not download"
(https://github.com/bitcoin/bitcoin/issues/30163)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I operate a full node on an embedded system with datadir being on a local SSD but the blocks are stored on an external USB-HDD, which is often referred to be a well balanced compromise of speedy chainstate tracking and heavy blockchain data.

When setting up new nodes I usually build bitcoind from source and for a quick upstart I use to attach the USB-HDD containing the blocks to it, whi
...

💬 maflcko commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127790284)
> Since the data corruption only happens about once per week

Once per week is a lot and if this was a broader problem, I'd assume that more people were complaining. Given that you can consistently reproduce on different machines, this seems like a real bug is somewhere. However, Bitcoin Core is running fine in a lot of other places, so there has to be some hardware or configuration setting (or combination thereof) that triggers this bug on your side. It would be good to know which one it is.

💬 sipa commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2127791221)
There are several BIPs that contain specifications relating to testnet, so perhaps a BIP is the right place to define testnet4? The BIP process predates testnet3, but only by a few months, so I don't think we should see the lack of a testnet3 BIP as an argument against this.

💬 mzumsande commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127797705)
> There is a lot of memory pressure and paging when a block comes in

Could you explain the paging in a bit more detail? Is the node constantly being bombarded with lots of simultaneous RPC calls (which ones?) or is some other interface used?

Also, from your log it appears that this happened while the node was catching up with the tip (almost but not completely synced yet), receiving blocks quickly. Is that typical, or does it usually happen when the node is synced and receives blocks as th
...

🤔 sr-gi reviewed a pull request: "refactor prep for package rbf"
(https://github.com/bitcoin/bitcoin/pull/30072#pullrequestreview-2061682943)
utACK [2fd34ba](https://github.com/bitcoin/bitcoin/pull/30072/commits/2fd34ba504957331f5a08614b6e1f8317260f04d)

Sorry it took me a while to get familiar with the validation logic. I left some non-blocking comments.

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1603916879)
In 90b60a16731ac756dce44c29f57d111f4dffba75

nit (not-blocking):

```suggestion
/** Whether CPFP and RBF carveouts are granted. */
```

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612127074)
Is there any case in which `m_allow_sibling_eviction` is not shadowing `m_allow_replacement`? All the uses I see, they have the same value, or if one is set, the other is assumed.

Is that just the case now, and may it be different in a follow-up? Otherwise, what is the point of having two flags?

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1603924191)
In 90b60a16731ac756dce44c29f57d111f4dffba75

I think this comment is not accurate (it was not all that accurate before that PR either). At this point, `CalculateMemPoolAncestors` has only been called once. The only case in which this caching applies is in the last else case of this context. I think this should be reworded

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1603949576)
In 90b60a16731ac756dce44c29f57d111f4dffba75

If we are removing `txns.size() > 1` because it is a truism, we should at least assume it to make sure we are not overlooking it

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1603952684)
In 90b60a16731ac756dce44c29f57d111f4dffba75

I see `:%s/even/or` was applied a few lines above, but this suggestion seems not to have been covered. Was it applied to the above line by mistake?

💬 maflcko commented on issue "prune shall not delete blocks it did not download":
(https://github.com/bitcoin/bitcoin/issues/30163#issuecomment-2127810175)
Using the same blocksdir for two different nodes is not supported. Nodes may download blocks in a different order and save them to different locations in the blocksfiles. This will lead to an error at some point, latest when one of the nodes can't find a block where it believes to be one.

Currently, I don't think what you are trying to achieve is possible without copying blocks.

> If bitcoin-core assumes pruning to be enabled by default, at least it should have asked for confirmation to de
...

💬 instagibbs commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612164710)
In package RBF this changes: https://github.com/bitcoin/bitcoin/pull/28984/commits/f93b602e74e101f4fed51f6d43b4930fcd7b0530#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R528

We don't want sibling eviction attempts to happen during package rbf logic

💬 instagibbs commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612164921)
I reverted that change based on your feedback already :)

💬 instagibbs commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612164986)
My reading of it is if it fails *below* for a second time, we will want to have cached the first error string.

either way, this PR hopefully doesn't make this confusion worse than status quo?

💬 instagibbs commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612165294)
will touch if I have to retouch the PR

👍 theuni approved a pull request: "build: LLD based macOS toolchain"
(https://github.com/bitcoin/bitcoin/pull/21778#pullrequestreview-2074783866)
Tentative ACK e8c25e8a35e333e90514945c592557615641553f.

There's a lot going on here and I'm not 100% confident, but I'm out of things to complain about :)

💬 brunoerg commented on pull request "i2p: fix and improve logs":
(https://github.com/bitcoin/bitcoin/pull/29833#discussion_r1612179061)
done

💬 brunoerg commented on pull request "i2p: fix and improve logs":
(https://github.com/bitcoin/bitcoin/pull/29833#discussion_r1612179235)
done

💬 brunoerg commented on pull request "i2p: fix and improve logs":
(https://github.com/bitcoin/bitcoin/pull/29833#issuecomment-2127843639)
Force-pushed addressing https://github.com/bitcoin/bitcoin/pull/29833#discussion_r1599061492.

💬 sr-gi commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1612181309)
Yeah, I don't think it makes it worse