Tim Ruffing
Tim Ruffing
> Is the generated asm different? Yeah, we could check but I imagine it will be a lot of work. It would probably make sense to first run the internal...
@roconnor-blockstream Did you update your VST proofs to the changes suggested by Pieter? (If no, are planning to do so?)
> Apparently libsecp256k1 on occasion will cast signed int128 numbers to signed int64 numbers, expecting to truncate the bits. That seems kinda dicey to me, but okay. Do you have...
I think we should revisit this issue once #831 has been merged, see also the discussion in https://github.com/bitcoin-core/secp256k1/pull/767#issuecomment-679110697
Making the rules part of the generic interface seems a reasonable simplification given that we currently use only magnitudes below ~16 (https://github.com/bitcoin-core/secp256k1/pull/1028#discussion_r762599882) but you could argue that then we optimize...
> With #967 things may become even more complicated as it adds a "precomputed" dimension (=reduced to 4 64-bit limbs instead of 5), but lacks the need for magnitudes as...
As I understand, this should always be faster and we don't need lots of benchmarks to confirm. > The other updates the writeup to reflect the improvements here. Nice, I...
@whb07 Is the purpose of this PR simply to make the code cleaner or is this solving any particular issue that you have when using the library?
So now that #925 has been merged, the point of this PR would be to tidy up the remaining includes. That's not strictly necessary but it's a good idea from...