-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add high-level types for musig2 primitives provided by secp256k1-kmp #107
Conversation
6f072e4
to
7cf6966
Compare
d5becfe
to
1110a6c
Compare
1110a6c
to
fa9718d
Compare
Why did you keep the prototype musig2 implementation (in the test folders)? Shouldn't we get rid of it entirely, we want to test the "real" implementation and have no use for the prototype one anymore? It's dangerous to keep it around, as some of the tests in Or am I too early reviewing this, and it's not ready yet? |
I kept it for reference but it's not supposed to be used in |
3fea18e
to
baeca86
Compare
baeca86
to
641a0db
Compare
09ff67a
to
eb10a83
Compare
df9ecff
to
bc6e398
Compare
* Add high-level helpers for using Musig2 with Taproot When using Musig2 for a taproot key path, we can provide simpler helper functions to collaboratively build a shared signature for the spending transaction. Those helper functions hide the low-level details of using an opaque key aggregation cache or signing session. This comes with a small performance penalty, as we recompute the key aggregation cache. We also document the exposed APIs, import more tests from the official test vectors, and make APIs safe: they should never throw exceptions, except when invalid public keys are provided as inputs (which should be verified by the caller beforehand). * Move taproot signing helpers to `Transaction.kt` This is more consistent with the existing `signInput` helpers.
@@ -12,7 +12,7 @@ plugins { | |||
val currentOs = org.gradle.internal.os.OperatingSystem.current() | |||
|
|||
group = "fr.acinq.bitcoin" | |||
version = "0.17.0-SNAPSHOT" | |||
version = "0.17.0-MUSIG2-SNAPSHOT" |
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.
Should we merge with that temporary version since we don't expect to do any other work on bitcoin-kmp
that would require a quick release? And then once we can merge ACINQ/secp256k1-kmp#93 we'll be able to make clean releases and fix the versions?
This PR is based on #108 because of ACINQ/secp256k1-kmp#93