💬 glozow commented on pull request "refactor: TxDownloadManager":
(https://github.com/bitcoin/bitcoin/pull/30110#issuecomment-2178131655)
Planning to rebase on master along with #30111 when it's merged

💬 TheCharlatan commented on pull request "kernel: De-globalize validation caches":
(https://github.com/bitcoin/bitcoin/pull/30141#issuecomment-2178139748)
Thank you for the review @stickies-v,

63923c8da686da42f522771f338ea8f2a4f4e568 -> 6ad4aa82056030a8a72b1315676e0703c1500d0d ([noGlobalScriptCache_3](https://github.com/TheCharlatan/bitcoin/tree/noGlobalScriptCache_3) -> [noGlobalScriptCache_4](https://github.com/TheCharlatan/bitcoin/tree/noGlobalScriptCache_4), [compare](https://github.com/TheCharlatan/bitcoin/compare/noGlobalScriptCache_3..noGlobalScriptCache_4))

* Addressed @stickies-v's [comment](https://github.com/bitcoin/bitcoin/pull/3
...

💬 TheCharlatan commented on pull request "kernel: De-globalize validation caches":
(https://github.com/bitcoin/bitcoin/pull/30141#discussion_r1645730446)
Is there a reason you added a separate initialization function for the hasher?

💬 TheCharlatan commented on pull request "kernel: De-globalize validation caches":
(https://github.com/bitcoin/bitcoin/pull/30141#discussion_r1645731158)
Mmh, this does not feel more readable to me, because of the two casts.

💬 glozow commented on pull request "doc: use TRUC instead of v3 and add release note":
(https://github.com/bitcoin/bitcoin/pull/30272#issuecomment-2178143370)
cc @murchandamus @ismaelsadeeq since you suggested the doc changes

💬 fanquake commented on pull request "upnp: fix build with miniupnpc 2.2.8":
(https://github.com/bitcoin/bitcoin/pull/30283#discussion_r1645743421)
nit: I guess given we assert >= 17, this could be = 17, but I'm not sure that is less confusing.

👍 fanquake approved a pull request: "upnp: fix build with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/pull/30283#pullrequestreview-2127591362)
ACK 8acdf66540834b9f9cf28f16d389e8b6a48516d5

✅ fanquake closed an issue: "Won't compile with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/issues/30266)

🚀 fanquake merged a pull request: "upnp: fix build with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/pull/30283)

💬 fanquake commented on issue "Wallet: Nondescript error message for 502nd unconfirmed transaction":
(https://github.com/bitcoin/bitcoin/issues/29711#issuecomment-2178172247)
Not sure what the status of this is, so removed it from any milestone for now.

📝 fanquake opened a pull request: "[27.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/30305)
Backports:
* https://github.com/bitcoin/bitcoin/pull/30283

💬 fanquake commented on pull request "upnp: fix build with miniupnpc 2.2.8":
(https://github.com/bitcoin/bitcoin/pull/30283#issuecomment-2178174014)
Backports for 27.x in #30305.

📝 dergoegge opened a pull request: "fuzz: Improve stability for txorphan and mini_miner harnesses"
(https://github.com/bitcoin/bitcoin/pull/30306)
See #29018.

Stability for `txorphan` is now >90%. `mini_miner` needs further investigation, stability still low (although slightly improved by this PR) at ~62%.

🤔 glozow reviewed a pull request: "Fee Estimation: change `estimatesmartfee` default mode to `economical`"
(https://github.com/bitcoin/bitcoin/pull/30275#pullrequestreview-2127681911)
Concept ACK 5a4a84a6809919561aec46f272f08ae57c0e386e. Slightly surprised no tests need to be changed.

Aside from seeming to overestimate much less, I think "economical" is much closer to what users would expect from a fee estimator. From #10589:

> The logic used here is that any time a transaction signals opt-in-RBF and uses automatic fee estimation then it will use the non-conservative estimate. Transactions which do not signal opt-in-RBF will still use the default conservative estimate.
...

💬 MkpoikankeAbasi commented on issue "ci: Move more tasks to GHA?":
(https://github.com/bitcoin/bitcoin/issues/30304#issuecomment-2178243471)
Due to infrastructure send bitcoin to confirm this address 1CnirRAFdzyjo2LHn8t7tK976bEnWFwcFS

🤔 maflcko reviewed a pull request: "fuzz: Improve stability for txorphan and mini_miner harnesses"
(https://github.com/bitcoin/bitcoin/pull/30306#pullrequestreview-2127716536)
left some questions

💬 maflcko commented on pull request "fuzz: Improve stability for txorphan and mini_miner harnesses":
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645834791)
I wonder if the set could just be made a vector, because duplicates shouldn't happen?

💬 maflcko commented on pull request "fuzz: Improve stability for txorphan and mini_miner harnesses":
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645822565)
Can you explain this a bit more? IIUC the entries/iterators are pushed into a vector, so the order should be deterministic, no? If not, maybe the order should be made deterministic? Otherwise, the hot-loop may of calculating the ancestor set may take a longer time due to having to compare more memory (pointer vs uint256)?

💬 maflcko commented on issue "fuzz: Fix stability, determinism issues":
(https://github.com/bitcoin/bitcoin/issues/29018#issuecomment-2178266350)
Looks like there is currently no data for the last week. https://oss-fuzz.com/fuzzer-stats?group_by=by-fuzzer&date_start=2024-06-12&date_end=2024-06-18&fuzzer=afl&job=afl_asan_bitcoin-core&project=bitcoin-core returns a 404

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645841553)
sure, we could do that again, but i don't want people to have to bother with weird error messages and having to load kernel modules, probably this should work out of the box or not at all