BIP459: Full-Aggregation of BIP340 Signatures#2210
Conversation
|
I had asked BIP editors to reserve 459 for this so the CISA related BIPs can be in consecutive order, but I didn't want to cause confusion as it might have looked like self-assigment if had just pushed it with the number. So waiting for a confirmation for the number :) |
|
Yes, 459 was reserved for Full-Aggregation of BIP340 Signatures. |
fjahr
changed the title
Add a vendored copy of the secp256k1lab library (master branch, commit a265da139aea27386085a2a8760f8698e1bda64e) that the full-aggregation reference implementation and test vector scripts depend on.
|
One imprecision here that I am grappling with: While this says "Full-Aggregation of BIP340 Signatures" technically this doesn't aggregate BIP340 signatures like half-agg does because there is never an actual BIP340 signature created. Rather, there could have been a BIP 340 signature in its place instead, and this builds on Schnorr which is tied to BIP340 in the Bitcoin context. Expressing that more correctly felt like bending over backwards when I tried and might have caused more confusion that clarity. But I wanted to make clear that I am aware of this and happy to take suggestions for changes if people think this improves the BIP. |
|
About the Nonce Generation warning on deterministic signatures: related to my earlier comments on the list and elsewhere, about 'what if there is a folklore "acceptably secure" single-owner aggregation that doesn't follow the DahLIAS protocol', how about this one: suppose a user does use RFC6979-style deterministic nonce-generation, reasoning "well, the attack is only if I'm signing with someone else, but I'm not". You might reasonably retort: but it specifically says under "Nonce generation" that it 'MUST NOT BE USED' and references active attackers, but I'd counter that the explanatory footnote refers specifically to co-signers as the threat; so a person may read that and think "I have no co-signers, no risk". There is at least one case where it could leak keys: if you sign with ACP, and you are convinced by external actions to, say, do RBF or "redo" the transaction elsewise, you could end up using the same nonce for different challenges. Apologies if this is too much like pedantry; I am less looking at it from the angle of "is this protocol correct?" and more from the angle of "what stupid, but plausible, thing are people likely to do?". With MuSig2 I feel like it's less of an issue (though of course people certainly can shoot themselves in the foot!), I am thinking of smaller wallet developers looking for the "I can give my users cheaper transactions!" angle, but who don't understand the deeper/subtler parts of what's going on here. |
3 participants
This is a BIP draft for full-aggregation of BIP340 Schnorr signatures, a standard for the DahLIAS scheme by Jonas Nick, Tim Ruffing, and Yannick Seurin. It complements BIP458 half-aggregation. Full-aggregation results in a constant 64-byte signature but requires an interactive signing protocol.
Compared to the version shared on the mailing list recently, this version incorporates waxwing's feedback from the thread, most notably:
Signand new test vectors covering this and other checksThe reference implementation is written in Python based on secp256k1lab, and the latest master of secp256k1lab is vendored with the BIP, same as it was done for BIP458.