On Friday, August 21, 2020 1:50 AM, John Newbery via bitcoin-dev
wrote:
> Summary: We should change the proposal and implementation to use even
> tie-breakers everywhere.
>
> John #notoquadraticresiduetiebreakers Newbery
Thanks Nadav, Lloyd, John, and those who commented privately,
As the
Pieter,
Thanks for the illuminating write-up. There seem to be two questions here,
one technical and one process:
1. Is changing to even tie-breaker for R the correct choice technically? I
can't comment on the performance characteristics of using a square/even
tie-breaker and I'll assume the
On Wednesday, August 12, 2020 11:49 AM, Pieter Wuille
wrote:
> It is late in the process, but I feel I owe this explanation so that at least
> the possibility of changing can be discussed with all information.
As the responses have been pretty positive so far, we've gone ahead and made a
Thanks for bringing this discovery up and a big thanks to Peter Dettman for
working on this.
I second what Nadav said. Removing pointless complexity is worth it even at
this stage. I also maintain a non-libsecp implementation of BIP340 etc.
Having two ways to convert an xonly to a point is a pain
Hello Pieter and all,
I am one of the maintainers of Bitcoin-S[1] and I maintain our secp256k1
bindings (via JNI) as well as our (inefficient) bouncy castle fallback
implementations of all secp256k1 functionality we depend on including
Schnorr signatures. In light of this new information that
Hello all,
The current BIP340 draft[1] uses two different tiebreakers for conveying the Y
coordinate of points: for the R point inside signatures squaredness is used,
while for public keys evenness is used. Originally both used squaredness, but
it was changed[2] for public keys after observing
