Comments (4)
@sipa if you have no objections or concerns, I'd open a PR to the main BIP repo.
from bips.
That's a very neat way to spell out this argument and leaves no doubt. I polished it a little bit to help my understanding:
For i in [1, u] let
P_i = lift_x(int(pk_i)),
r_i = int(sig[0:32]),
R_i = lift_x(r_i),
s_i = int(sig[32:64]).
If there exists an i such that lift_x for P_i or R_i fails or r_i >= p or s_i >=
n, then both Verify(pk_i, m_i, sig_i) and BatchVerify(pk_1, ..., pk_u, m_1, ...,
m_u, sig_1, ..., sig_u) fail.
Otherwise Verify(pk_i, m_i, sig_i) fails if and only if C_i := s_i*G - R_i -
e_i*P_i != 0. We let c_i to be the discrete logarithm of C_i with respect to a
fixed group generator and define the polynomial f_u(a_2, ..., a_u) = c_1 +
a_2*c_2 + .... + a_u*c_u. BatchVerify succeeds if and only if f_u evaluated on
uniform randomizers a_2, ..., a_u is 0. Assume there exists i in [1, u] such
that Verify(pk_i, m_i, sig_i) fails. Then f_u is not the zero polynomial and we
make the following inductive argument to prove that
forall u >= 1, Pr(f_u(a_2, ..., a_u) = 0) <= 2^-128.
(similar to the Schwartz-Zippel lemma with d = 1, a_1 = 1):
u = 1: By assumption, Verify(pk_1, m_1, sig_1) fails, which implies c_1 != 0.
We have Pr(f_1() = c_1 = 0) = 0 <= 2^-128.
u > 1: We can write the polynomial as
f_u(a_2, ..., a_u) = a_u*c_u + f_{u-1}(a_2, ..., a_{u-1}).
Case a) If Verify(pk_u, m_u, sig_u) fails, then c_u != 0. Since f_u is not
the zero polynomial, we have that for fixed values a_2, ..., a_{u-1}, there
is at most a single value for a_u such that f_u(a_2, ..., a_u) = 0.
Since a_u is chosen independently from a_2, ..., a_{u-1} and uniformly from
a space of 2^128 values, we have
Pr(f_u(a_2, ..., a_u) = 0) <= 2^-128.
Case b) If Verify(pk_u, m_u, sig_u) succeeds, then c_u = 0 and
f_u = f_{u-1}. By assumption there exists an i in [1, u-1] such that
Verify(pk_i, m_i, sig_i) fails. By the induction hypothesis we have
Pr(f_u(a_2, ..., a_u) = 0) = Pr(f_{u-1}(a_2, ..., a_u) = 0) <= 2^-128.
qed
But is there a reason why we can't simply invoke the Schwartz–Zippel lemma? I think this would work directly:
Assume there exists i in [1, u] such that Verify(pk_i, m_i, sig_i) fails. Then f_u is
not the zero polynomial and by the Schwartz–Zippel lemma, f_u(a_2, ..., a_u) <= 2^-128.
from bips.
But is there a reason why we can't simply invoke the Schwartz–Zippel lemma?
I think we can. Initially I thought that the Schwartz-Zippel Lemma as stated on wikipedia required the indeterminates to be in the same field as the coefficients but after looking at it again, I can see that that's not actually the case.
from bips.
You could also open a PR against this repo and we could batch a few changes. Not sure which is better, I'm fine with both options.
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
- Squareness vs oddness tie-breaker for public keys HOT 8
- 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
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.