💬 BenWestgate commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#discussion_r1309545616)
I would prefer it quietly round down to the maximum. Especially since it rounds up to the minimum.

I know a few scripts people use that set dbcache to a percentage of available memory that this part of the PR would break for 64GB RAM.

What problem is failing to start meant to solve?

💬 epiccurious commented on pull request "doc: Update mentions of generating bitcoin.conf":
(https://github.com/bitcoin/bitcoin/pull/30154#discussion_r1611518035)
Good point. My intention here is to reduce ambiguity by being more explicit to the user.

One solution would be to add a check to ensure this section mentioned actually exists in the markdown, but it's probably not worth the added code complexity for little benefit.

Do you prefer to revert this change back?

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611522537)
OK, i went for `QueryDefaultGatewayImpl` for now, with an outer function. Naming it different things on different platforms means having to repeat the `#ifdef` forest, which isn't really worth the slight increase in clarity imo.

💬 epiccurious commented on pull request "doc: Update mentions of generating bitcoin.conf":
(https://github.com/bitcoin/bitcoin/pull/30154#issuecomment-2126901520)
> IIUIC, this change affects only people who is getting core from source

Correct as I understand it. Only impacts people using the source, not the binary distributions.

💬 ajtowns commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611532999)
`EXCLUSIVE_LOCKS_REQUIRED(!foo)` is a stronger assertion; it says that if the caller can see the lock, it also has to have the same assertion. `LOCKS_EXCLUDED(foo)` just says you can't `LOCK()` or have `EXCLUSIVE_LOCKS_REQUIRED(foo)` -- so there's nothing prevent the caller's caller from having taken the lock.

📝 ismaelsadeeq opened a pull request: "Fee Estimation via Fee rate Forecasters"
(https://github.com/bitcoin/bitcoin/pull/30157)
### This PR aims at improving Bitcoin Core fee estimation


### The objectives of this improvement are to:

- Reduce overestimation done by the current `CBlockPolicyEstimator`
- Make the fee estimator aware of the state of the mempool, allowing it to respond to changing conditions immediately.
- Empower node users to be self-sovereign and use their node's estimates, as is now, the majority rely on third parties for fee estimation.
- Simplify the process of adding new fee estimation strat
...

💬 epiccurious commented on pull request "doc: note that you can assume C++20.":
(https://github.com/bitcoin/bitcoin/pull/30136#issuecomment-2126906154)
Concept ACK f00801c5fc7ed18518de64dea03b96d7585523ab.

⚠️ kosuodhmwa opened an issue: "Log: "no wallet support compiled in" when i start bitcoind"
(https://github.com/bitcoin/bitcoin/issues/30158)
hi there

How to compile it with wallet support? I would like to use it as a wallet too - so not just as a full node.

Thank you very much for your feedback(s).


Kind regards, Jan

💬 maflcko commented on issue "Log: "no wallet support compiled in" when i start bitcoind":
(https://github.com/bitcoin/bitcoin/issues/30158#issuecomment-2126963695)
```
sudo apt install libsqlite3-dev
```

See https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#linux-distribution-specific-instructions

💬 sdaftuar commented on pull request "refactor prep for package rbf":
(https://github.com/bitcoin/bitcoin/pull/30072#discussion_r1611599378)
Looks like the commit message for commit 6b3373248656ef45d73262aa6dba3aec5866f7ca should be updated now, sorry!

🚀 fanquake merged a pull request: "contrib: Renew Windows code signing certificate"
(https://github.com/bitcoin/bitcoin/pull/30149)

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611604355)
Oh duh! Swapped out the last commit for just a deletion of `EraseTxNoLock`, now having all functions call `EraseTx` instead.

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611604731)
done

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611604912)
fixed

💬 TheCharlatan commented on pull request "Encapsulate warnings in generalized node::Warnings and remove globals":
(https://github.com/bitcoin/bitcoin/pull/30058#discussion_r1611606129)
Thanks for testing this out! I forgot that the we'd need to reconstruct the versionbit before, sorry about that. I think I like this better. The reason I am a bit hesitant about keying by strings is that it makes them harder to discover for outside users and forces them to use a variable-size data type as a key for mapping them.

💬 fanquake commented on pull request "contrib: Renew Windows code signing certificate":
(https://github.com/bitcoin/bitcoin/pull/30149#issuecomment-2126990044)
Backported to 27.x in #30092.

🤔 sdaftuar reviewed a pull request: "Drop -dbcache limit"
(https://github.com/bitcoin/bitcoin/pull/28358#pullrequestreview-2073822380)
Concept ACK.

I don't see much of a philosophical difference between having no limit and having a limit of 16GB on systems where a user has less than 16GB actually available... If we're already requiring users to do something smart, we can keep doing that -- and if we are worried about someone using an inappropriate value we can try to solve that separately (maybe by testing that we can allocate that much at startup or something?).

💬 sdaftuar commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#discussion_r1611605241)
Just noticed the filename here should be fixed (25358 vs 28358).

💬 hebasto commented on pull request "fuzz: More accurate coverage reports":
(https://github.com/bitcoin/bitcoin/pull/30156#issuecomment-2126993578)
Concept ACK on improving coverage.

💬 glozow commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1611615809)
Ah that makes sense. I will leave this as is.