Pieter Wuille

@vostrnad Does the performance on Windows recover if you run with the `-blocksxor=0` option?

@davidgumberg Well from the (apparently mistaken) assumption that the XOR logic comes with no material performance cost, it made sense to always want to use it (even with a pattern...

> I wonder if this issue could be caused by number of calls we make to `fwrite` because of the write buffering in xor path of `AutoFile::write()`, maybe platforms other...

@vasild Yes, but that gratuitously reveals to its peers that it is the transaction originator too (not really an issue in your private broadcast setting, but in nearly all others,...

@ariard Asking for conceptual feedback is reasonable, but here I don't even see any concept being proposed, neither in the PR nor in the associated BIP draft. It is *just*...

It would be good to know what impact it has on IBD, as it's necessarily going to make things slower (more syncs means more disk writes, and more memory/cpu to...

@ismaelsadeeq It's a possibility, if we'd want to replace CFeeRate entirely. Another possibility is keeping CFeeRate and its interface, but make it be an encapsulated FeeFrac object (that e.g. on...

@tdb3 0x200000004 is the more accurate number (it equals floor((2^64-1)/(2^31-1))) but 0x200000000 obviously also works, and: * It compiles to slightly simpler asm code (it computes fee >> 33, rather...

I've made a number of changes, mostly in response to @paplorinc's [suggestion](https://github.com/bitcoin/bitcoin/pull/30535#discussion_r1694594826), which involves: * Rewriting all of `feefrac`'s fuzz tests to test against `arith_uint256` (rather than using its own...

I have added a commit that splits `FeeFrac::Evaluate` into an `EvaluateDown` and an `EvaluateUp`, corresponding to the rounding modes they implement (plus tests for both behaviors).