-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC 10: ROAST Schnorr signatures #601
Conversation
and our implementation must conform to it. | ||
|
||
Schnorr signatures are incompatible with existing Bitcoin scripts, | ||
requiring the use of taproot scripts instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a link to an explainer of taproot scripts would help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow-up issue
Left a few comments around hyperlinking extra info and some state stuff Additionally, I think adding more resources like https://www.youtube.com/watch?v=FVW6Hgt_meg and https://github.com/robot-dreams/roast would be sweet |
I'm good here! I think it would be helpful to have someone from @keep-network/go check this out as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent RFC, and overdue for a merge.
and our implementation must conform to it. | ||
|
||
Schnorr signatures are incompatible with existing Bitcoin scripts, | ||
requiring the use of taproot scripts instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow-up issue
=== DKG | ||
|
||
The (51, 100) secret key for a tBTC-ROAST signing group (aka wallet) | ||
is produced using GJKR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A link here would be 👌
Because of this, the only solution is to retry the signing | ||
until a set of signers with no misbehaving participants is stumbled upon. | ||
This means that even a small group of misbehaving participants | ||
can cause a dramatic slowdown in signing, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth noting what the dramatic slowdown means: For 51-of-100 signing and 2 malicious members, we need 5 retries on average.
already widely used in Bitcoin. | ||
A signature for message m and public key point P | ||
is defined as the (point, scalar) pair `(R, s)` | ||
where `s * G = R + hash(R || P || m) * P`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is II
a byte concatenation or a logical alternative of bytes? I take the former but would be nice to define it in the RFC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow up issue
|
||
The algorithm `Verify(pk, m, sig)` is defined as: | ||
|
||
* Let `P = lift_x(int(pk))`; fail if that fails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the lift_x
function doing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created a follow up issue
Using ROAST and Schnorr signatures, we can significantly simplify threshold signing while achieving attributability of misbehaviour.