Innokentii Sennovskii
Innokentii Sennovskii
For some reason the link I added to the post to the function got lost. https://github.com/ethereum/py_ecc/blob/a1d18addb439d7659a9cbac861bf1518371f0afd/py_ecc/bls/point_compression.py#L173
the values, which are described in @(symbolic) are the ones that produce this result
I checked, it can deal with lists. But it seems to get into a real problem in here. It extends both values to 64 bits, but it still only uses...
The construction of concatenated polynomials now uses more cores.
There are two problems right now: 1. Recursive verifiers take a vector of field elements as inputs, construct the transcript from them and only after that recursively verify the proof....
What do we do about checking that we handled the correct proof? Is it published completely as public inputs? Do we hash it a bit more and use that?
We've fixed the edgecases with repeating points and points at infinity, but we are getting a weird issue when trying to create a NAF of 1 and the scalar field...
This would be really nice to protect us from shooting ourselves in the foot. If we implement fuzzing for noir programs, it would also have a benefit as an extended...
Had to switch to manual tracking in recursive verifiers because DFSan randomly applies or loses tags (probably has to do with C++ and all the templating/complex objects we use)
> It would be interesting to see if this could be implemented as a check on the ACIR directly by tracking sets of connected witnesses. This would then be generic...