Comments (8)
I don't know if we care about this ~5us speedup at signing time (because when you do care, perhaps you want signing with precomputed public key data, which avoids this cost in both cases), but there seems to be basically no gain apart from consistency with R (which is arguably very different, as handling of R is generally limited in scope to the signing code, while public keys are obviously exposed to applications (and things like the taproot tweak break the perfect blackboxy ness of them).
I think the question is not so much whether we care. We care about the details, and here it seems to me that switching to oddness is faster and it's basically for free because there is no point in consistency.
- As you point out, handling R is fully internally anyway.
- I would care about consistency if it was to avoid implementing two algorithms. But in this case, the oddnest test is a one-line algorithm.
- I think then consistency with existing keys is actually the nicer consistency because -- as you point out -- public keys (and their tie-breaker to some extent) are user-facing and sticking to the thing that people and that is mathematically simpler is probably better for implementers.
from bips.
@roconnor-blockstream pointed on IRC that the even-tiebreaker also adds a normalization step to the verifier.
from bips.
careful with too much public key consistency. That's how you people blowing their security by using the same key/nonce with ecdsa and schnorr, or burning their coins by writing uncompressed pubkeys into the output. :P
I don't think this one matters too much one way or another. It's nice if the flagged public key can just be an ordinary 'compressed' public key.
Looks like 'oddness' (yuck) for the pubkey would just plain be faster because jacobi is slower than a multiply, unlike for r and we get the square and inverse for free as a product of the x projection to affine. Even if you assume that the pubkey is going to be precomputed in signing (as it should be), that precomputation would still be faster.
@sipa and half a negate.
from bips.
So, I think we should change BIP340 to use implicit-even as tiebreaker. To avoid inconsistently breaking potential code people may have written already, we should probably also change the challenge hash tag. How about "Schnorr/secp256k1" or so?
from bips.
This also means changing BIP341 to change the flag in the control block to be the odd/even bit of Q, rather than its squaredness.
Implementation-wise, I wonder if this means we can't just drop a bunch of the x-only code, and just use the existing pubkey tweaking functions in the consensus verifier.
from bips.
I share the slight preference for implicit-even as tiebreaker because it simplifies the scheme (by avoiding the jacobi symbol), despite the additional verification branch. Also, implementation-wise this makes the full/auxiliary pubkey type identical to the existing one and there's no need for a tiebreaker flag.
As for compatibility between auxiliary/flagged and compressed pubkeys, it seems like compressed pubkeys are already compatible with xonly pubkeys. An adversary can easily convert between the two. At least I'm not able to come up with a non-adverserial scenario or practical attack where this matters.
from bips.
I think the only reason squareness was chosen over evenness was because we'd already specced has_square_y(P)
and P = lift_x(x)
conversion functions for dealing with R
. Switching to evenness sounds like a good tradeoff if it makes implementation/use a bit easier.
from bips.
Fixed by #192.
from bips.
Related Issues (20)
- bip-schnorr/taproot agree on terminology of points HOT 6
- bip-taproot: Add security argument HOT 5
- bip-taproot: Internal pubkey construction seems to be inconsistent. HOT 3
- bip-taproot: Motivation section doesn't address motivation clearly HOT 2
- Diagram under "Constructing and spending Taproot outputs" doesn't show HOT 2
- bip-taproot/tapscript: Prevention length-extension attacks in public key tweaking HOT 6
- bip-schnorr: Euler's criterion
- bip-schnorr: Inaccurate proof of quadratic residuosity HOT 2
- Syntactical issue in taproot footnote 16 HOT 2
- bip-taproot: Publick key tweak resulting in point-at-infinity HOT 5
- bip-schnorr: Add k values to test-vectors HOT 8
- Avoiding the EC multiplication during signing by using precomputed pubkey data HOT 15
- Discussion on power analysis attacks HOT 47
- bip-schnorr: nonce uses hash instead of PRF HOT 2
- Synthetic randomness for batch verification HOT 2
- Clarify relationship between synthetic nonces and anti-covert-channel HOT 1
- BIP340: clarify impact of pre-hashed messages, or support variable-length messages HOT 71
- bip340: Cite malleability issues with other schemes
- bip-340: Reduce size of batch verification randomizers to 128 bits HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bips.