Update BIP 340 with fresher info on multi-, threshold, and blind signatures #1583
Conversation
|
Paging @sipa, @real-or-random, and @jonasnick for review |
There was a problem hiding this comment.
Thanks for the PR. I think all of these changes make sense, but I wonder to what extent this should be a living document. My view is that we should certainly take care of the technical /normative sections and fix bugs and clarify things there whenever necessary. This is more of a motivational section, so I think it's not strictly required to keep it updated.
But pragmatically speaking, people keep getting confused about this, so why not point them to the recent research. It's just a bit strange that some of these papers cite BIP340 as a motivation, so it will be a bit cyclic now after the PR. (Perhaps add a line in the changelog section?)
There was a problem hiding this comment.
I think it makes sense to pragmatically try to reduce the confusion the document causes to today's readers. I think the main improvement of this PR, which I am happy to concept ACK is replacing
However, the practicality of the existing schemes is limited: most schemes in the literature have been proven secure only for the case ''k-1 < n/2'', are not secure when used concurrently in multiple sessions, or require a reliable broadcast mechanism to be secure. Further research is necessary to improve this situation.
with a reference to FROST.
bip-0340.mediawiki
Outdated
| To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below). | ||
| To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig2 multisignature scheme secure (see Applications below). |
There was a problem hiding this comment.
I think this makes the case for using key prefixing weaker because a possible interpretation of the sentence now is that it is possible to use MuSig(1) without key prefix instead. Maybe give MuSig, MuSig2 and FROST as examples?
I'm just mentioning this because the question why pubkey prefixing is required by BIP 340 (and therefore does not support recovering a public key from a signature) comes up regularly.
There was a problem hiding this comment.
Agreed, more generally one could say "for proving multiparty signature protocols (such as MuSig, MuSig2, and FROST) secure".
|
I agree that the informational/motivational sections are not intended to be constantly updated, but my concern was that this document might be the entry point to the topic for many people unfamiliar with it and so it might be beneficial to have more recent pointers. But of course feel free to cherry pick whatever you like ! |
|
I'm happy with 4dcdade if the other authors agree. |
Co-authored-by: Tim Ruffing <crypto@timruffing.de>
Co-authored-by: Tim Ruffing <crypto@timruffing.de>
|
Given that @sipa and @jonasnick were both active here recently with conditional ACKs and changes requested, I’m also waiting for their ACKs. |
|
The BIP editors have ranging preferences on Squashing and Git Commit hygiene, so we do not require any special effort to present a neat commit history. |
|
ACK 5d10163 |
Info and links about multi-, threshold, and blind signatures was a bit out of date.