l0rinc
l0rinc
Code review reACK 8a4ab45c13dd7ca4474bc4621110da82e0a634f8 I have re-rebased [my previous ack](https://github.com/bitcoin/bitcoin/pull/32740#issuecomment-3208833064), solved the conflicts and did a soft reset compared to this, the only differences were whitespace changes, comment fixes, [static...
Code review reACK 9a387e9175d34d1eaf83b9008f5e857d1eb04b8e Finalized the pointer to reference migration since last ack.
Libsecp is a dependency, you have to fix those upstream. And before doing cheap typo fixes, we often appreciate if you familiarize yourself with the code by doing code reviews...
ACK 8ee014020071a60d1bdcdd6c16a7e515c6576fea
> The bar should be pretty high for touching such critical code. Absolutely, every change should have an extremely high bar here. For context, compared to the changes described in...
> it is called whenever a tx is validated (so also during mempool acceptance) Updated the description, thanks. > how much this improves transaction validation as a whole I can...
@1440000bytes, this behavior isn't helpful - you're just reiterating what I've already explained, without suggesting workable solutions. Anyway, I've created an [alternative PR](https://github.com/bitcoin/bitcoin/pull/31699) that focuses solely on the tests and...
~I pushed a new version that is based on https://github.com/bitcoin/bitcoin/pull/31699 - to separate the testing/benching from the consensus change. This will remain in draft to gather comments.~ ---- I've also...
> I feel like we shouldn't need to fully sort, though We likely wouldn't need that just for duplicate checking, but this seems "good enough", since it's a built-in function...
> by using a faster comparison operator and doing direct comparisons for relatively small input sizes. Quadratic comparison would likely be faster than sorting for very small input sizes (e.g.