Closed t-bast closed 8 months ago
This should be "rebased" on top of https://github.com/ACINQ/bitcoin-kmp/pull/107, which implements a musig2 API that is different than the current prototype on master and is based on https://github.com/ACINQ/secp256k1-kmp/pull/93 which implements a low-level musig2 API that tracks what will be added to https://github.com/bitcoin-core/secp256k1/ and should not change much now.
Nice, I'll do that!
This should be "rebased" on top of https://github.com/ACINQ/bitcoin-kmp/pull/107, which implements a musig2 API that is different than the current prototype on master and is based on https://github.com/ACINQ/secp256k1-kmp/pull/93 which implements a low-level musig2 API that tracks what will be added to https://github.com/bitcoin-core/secp256k1/ and should not change much now.
I started the rebase, but the exposed functions are quite inconvenient to work with, I suspect that #107 can be greatly improved. I'll review it thoroughly once the libsecp256k1 version is stable enough.
I started the rebase, but the exposed functions are quite inconvenient to work with, I suspect that #107 can be greatly improved. I'll review it thoroughly once the libsecp256k1 version is stable enough.
secp256k1-kmp
is "dumb" and exposes secp256k1
's API as directly as possible, if it's difficult to work with we may want to open issues upstream. In any case I'd rather keep secp256k1-kmp
as simple as possible (from an integration p.o.v) and if needed provide better abstractions in this library instead.
I agree that secp256k1-kmp
should directly wrap secp256k1
without adding helper functions. But bitcoin-kmp
should definitely add those helper functions to hide the secp256k1
API whenever possible!
Sorry I thought you meant https://github.com/ACINQ/secp256k1-kmp/pull/93. I agree that https://github.com/ACINQ/bitcoin-kmp/pull/107 is pretty basic but it made building our new swap-in protocol simpler (because it's easier to see how musig2 is used).
When using Musig2 for a taproot key path, we can provide simpler helper functions to collaboratively build a shared signature for the spending transaction.
This hides all of the low-level details of how the musig2 algorithm works, by exposing a subset of what can be done that is sufficient for spending taproot inputs.