bips
bips copied to clipboard
sipa
Bitcoin Improvement Proposals
This (currently) speeds up batch verification in libsecp256k1 by up to 9%. Reopen of https://github.com/sipa/bips/pull/220 which was automatically closed. Closes https://github.com/sipa/bips/pull/219. - [ ] Consider replacing Schwartz-Zippel with proof by...
Context: https://github.com/bitcoin-core/secp256k1/pull/558#discussion_r457281893 Right now, BIP340 specifies that imputs are strictly 32-byte messages. This implies that for typical use cases, the message needs to be pre-hashed, and the GGM/rpp/rpsp proof doesn't...
For public keys `pk_1, ..., pk_u`, messages `m_1, ..., m_u`, signatures `sig_1, ..., sig_u`, the probability that `BatchVerify(pk_1, ..., pk_u, m_1, ..., m_u, sig_1, ..., sig_u)` with 128-bit uniform randomizers...
@sipa points out that we should cite these: https://eprint.iacr.org/2020/1244 https://hdevalence.ca/blog/2020-10-04-its-25519am (cc @hdevalence)
After we have switched to recommending synthetic randomness for nonces, I propose to do the same for the randomness used in batch verification. Currently we derive the randomness deterministically from...
@roconnor brought this up, but I'm not sure what exactly his issue was (perhaps he wants to comment here). Our current paragraph on this is quite general and therefore not...
See https://eprint.iacr.org/2017/985.pdf, which describes an attack against Ed25519, by doing power analysis on the nonce generation function. It relies on having a single SHA512 message block that contains both attacker-controlled...
Regarding TapTree construction based on tapscript probability weights (e.g. Huffman): There seems to be a privacy trade-off when optimizing for expected script path spending cost, as standard outputs will likely...
