jamesob

> this breaks that by wiping the cache completely On a sort of related note, I think it's kind of crazy that we couple writing back to disk with emptying...

Concept ACK! I'll try to repro the bench results in the next week or so.

Bench running now, should have some results in the next day or so. ```shell $ ( bitcoinperf --no-teardown bench-pr --num-blocks 30_000 --run-id no-flush-on-prune \ --bitcoind-args='-dbcache=4000 -prune=550' --run-count 3 28280 &&...

Local IBD of 30_000 blocks with `-prune=550` from a Taproot-enabled height didn't show any difference. I didn't have `-log=prune` enabled, so my bench debug.log was basically useless. Rerunning...

Oddly enough, this change benched out as being slightly slower (~4.8%) than the commit before it in master. Not a huge regression, but not what I expected. Compiled with `gcc...

Quick update: I did confirm (on another machine) that more contemporary versions of gcc (`12.2.0` in this case) do show a speed _up_ of about 4%, with slightly more time...

Oddly enough, even with `gcc 12.2.0`, the regression on the first machine holds. Artifacts here: https://gist.github.com/jamesob/1f4456f1f9bafcabb392210bbfe9f240 Will run the secp benches in isolation.

> If that doesn't help, please benchmark libsecp256k1 with ([bitcoin-core/secp256k1@10e6d29](https://github.com/bitcoin-core/secp256k1/commit/10e6d29b60c3931e327bc18e6c50cea78296b1ba)) and without [bitcoin-core/secp256k1#1446](https://github.com/bitcoin-core/secp256k1/pull/1446) ([bitcoin-core/secp256k1@07687e8](https://github.com/bitcoin-core/secp256k1/commit/07687e811d1c9700e6fe9d658aef080e3568c0f1)), see the PR for instructions and also consider setting `SECP256K1_BENCH_ITERS=200000` or another large value. These benchmarks...

Concept ACK > If libbitcoinkernel exposes stateless block/tx validation, that is, I give the transaction[s], the inputs and some context like block hash and MTP, and it spits out a...

Big concept ACK on the interface. This is a nice simplification.