💬 laanwj commented on pull request "ci: Place datadirs for tests under tmpfs ":
(https://github.com/bitcoin/bitcoin/pull/31182#issuecomment-2446990530)
> I'd say the memory increase shouldn't matter, because on modern distros the default temp dir is already a tmpfs. So if memory was an issue, then running the tests normally (outside the CI) would already lead to issue reports. (I haven't seen any, but I may be missing some).

i don't think anyone runs the tests in low-memory/dis conditions 😄 i've had some issues on custom RISC-V hardware in the past, but nothing significant enough to create an issue about. At least the CI with start with a c
...

💬 naumenkogs commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1822539819)
in a8d0976de7edf43d3cfea8dff3afc923580d8f84

⚠️ southunitedraza opened an issue: "Tokensg"
(https://github.com/bitcoin/bitcoin/issues/31185)

✅ fanquake closed an issue: "Tokensg"
(https://github.com/bitcoin/bitcoin/issues/31185)

:lock: fanquake locked an issue: "Tokensg"
(https://github.com/bitcoin/bitcoin/issues/31185)

💬 andrewtoth commented on pull request "RPC: Add reserve member function to `UniValue` and use it in `getblock` RPC":
(https://github.com/bitcoin/bitcoin/pull/31179#issuecomment-2447160934)
> this approach is possible but is it maintainable?

Hmm, yeah this would end up with `reserve(<magic number>)` littered throughout the json serialization. Not ideal.

I took a quick look through most of the block parsing, and many of the reservations we would do would be <5, so unlikely to be a big benefit.

The `entry` in `TxToUniv` could have up to 12 kv-pairs stored, and in `blockheaderToJSON` it could have 14. These would also be reserving two vectors so might have some visible benefi
...

💬 hodlinator commented on pull request "tinyformat: Add compile-time checking for literal format strings":
(https://github.com/bitcoin/bitcoin/pull/31174#issuecomment-2447182783)
Rebased #30933 on top of this PR and the mismatches between our custom `consteval` checking and tinyformat are gone as far as our current tests go - rebased commit: 32d4cf37d5056dc42bbf317b059e10910b984b0e

💬 maflcko commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#issuecomment-2447191411)
Are you still working on this? If not, maybe turn into a draft for now?

💬 ryanofsky commented on pull request "tinyformat: Add compile-time checking for literal format strings":
(https://github.com/bitcoin/bitcoin/pull/31174#issuecomment-2447224880)
re: https://github.com/bitcoin/bitcoin/pull/31174#issuecomment-2447182783

> mismatches between our custom `consteval` checking and tinyformat are gone as far as our current tests go

In case you do want a test with different behavior, I think you can use %n specifier which is not supported by tinyformat

- rebased commit: [32d4cf3](https://github.com/bitcoin/bitcoin/commit/32d4cf37d5056dc42bbf317b059e10910b984b0e)

💬 maflcko commented on pull request "ci: Place datadirs for tests under tmpfs ":
(https://github.com/bitcoin/bitcoin/pull/31182#issuecomment-2447229422)
(force pushed to fix a type bug in the modified Python code, discovered by the Windows CI. I wish this code was written in Rust or another type-safe language, so that issues like this are caught at compile-time, but this can be done in a follow-up)

✅ maflcko closed a pull request: "doc: note that you can assume C++20."
(https://github.com/bitcoin/bitcoin/pull/30136)

💬 maflcko commented on pull request "doc: note that you can assume C++20.":
(https://github.com/bitcoin/bitcoin/pull/30136#issuecomment-2447301242)
Closing for now, due to inactivity since May. (The feedback was waiting to be addressed since then)

Please leave a comment if you want this reopened, or you can open a new pull request with the new changes.

💬 davidgumberg commented on pull request "key: clear out secret data in `DecodeExtKey`":
(https://github.com/bitcoin/bitcoin/pull/31166#issuecomment-2447431280)
utACK https://github.com/bitcoin/bitcoin/pull/31166/commits/559a8dd9c0aafcecf00f9ccd9aabe5720bcebe8c

I agree that given how short lived this data is it doesn't seem likely to get paged, but it would still be nice to encapsulate our allocation strategy for secrets.

💬 theStack commented on pull request "net: Use actual memory size in receive buffer accounting":
(https://github.com/bitcoin/bitcoin/pull/31164#issuecomment-2447431668)
Concept ACK

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#issuecomment-2447434066)
Rebasing to deal with merge conflicts

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1822834821)
I think the current approach mimics what you were doing with your old one. I haven't picked up the trickle reduction commit not the delayed response, but I was planning to in the next PR.

Your approach used to add transactions to the reconciliation set during INV building, which happens on trickle intervals. So data was added to `to_be_announced` (delayed) on `RelayTransaction` and then made available on trickle. The current approach adds data to the delayed set on `RelayTransaction` and make
...

💬 dergoegge commented on pull request "bench: Remove various extraneous benchmarks":
(https://github.com/bitcoin/bitcoin/pull/31153#issuecomment-2447569710)
Added the doc commit, ready for further review

💬 jb55 commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2447587199)
> In my main machine, is ryzen with 32gb ddr4 with 2 sticks of memory. The other machine is Xeon, with 32gb memory, in quad channel ddr3. So i dont think its memory, because the 2 computers are stable. I can run prime95 in both for 2 hours with no problem.

it's true, I just ran disk diagnostics, no issues. going to run a memory diagnostic... but my system has been stable so I would be very surprised if it was that. I'm also running on ZFS. I keep hitting this, even after a full redownload...
...

💬 maflcko commented on pull request "bench: Remove various extraneous benchmarks":
(https://github.com/bitcoin/bitcoin/pull/31153#discussion_r1822897369)
Hex parsing is used in mining via DecodeHexBlk, no?

💬 dergoegge commented on issue "Support validating a PoW-free block over over RPC":
(https://github.com/bitcoin/bitcoin/issues/31136#issuecomment-2447653274)
At a glance, [this](https://github.com/bitcoin/bitcoin/blob/97b790e844abd2f92c928239a7dc786d37fad18b/src/rpc/mining.cpp#L683-L710) looks like what you're looking for? i.e. `getblocktemplate`'s proposal mode: https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki#block-proposal