Add Support for BIP-340 Schnorr #113
Replies: 3 comments 7 replies
-
|
Generally speaking, I think the proposal makes sense to me as the new curve and sign algorithm will increase the scalability of Rosetta from transaction signing perspective so that more future assets will be integrated with Rosetta easily. Given only new curve and sign algorithm is added, there should be no or very few breaking changes. One small comment related to implementation is that we should also update the corresponding asserter (e.g. https://github.com/coinbase/rosetta-sdk-go/blob/a48f742c1d904ad2e022585affa2eee63e437908/asserter/construction.go#L250) @shrimalmadhur Please review this proposal as well |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @GeekArthur for creating this discussion and @sleepdefic1t for proposing this. I think this would be a good addition from the open source spec per se so I am supportive of this addition. @GeekArthur from Coinbase perspective if any chain wants to use it, we have to make sure our internal key management systems supports this curve type. So as an open source spec we can add it, but there will be more work required if any chain with this curve wants to integrate with Coinbase. |
Beta Was this translation helpful? Give feedback.
-
|
@sleepdefic1t Proposal is approved, you can work on the corresponding specs and sdk changes, thanks for proposing this! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Bitcoin's BIP-340 Schnorr signature scheme is a
secp256k1curve variant not directly supported by Rosetta.The primary outward distinction between the Ecdsa/Secp256k1 scheme and BIP-340 is the use of x-only 32-byte publicKeys and 64-byte (
[R,s]) signatures.BIP-340's underlying Sign/Verify scheme also internally encodes the signing keyPairs' signature and public point as its variants whose
'Y'coordinates are a quadratic residue ('even'). (see more here: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design)Benefits
BIP-340 provides greater (provable) security than ECDSA/secp256k1-based schemes and offers signature non-malleability and linearity. Signing also makes use of "tagged hashes" to mitigate things like related-key attacks, which accordingly "...increases robustness in multi-user settings."
While this proposal to introduce BIP-340 does not include multisignature support, this would be a likely precondition to doing so. (e.g., #50)
Solution
Add the following to
rosetta-specifications:./models/CurveType.yaml-Secp256k1Bip340./models/SignatureType.yaml-SchnorrBip340Once approved and released, implement the following in
rosetta-sdk-goincluding any relevant tests:./keys/keys.go- Key Import & Generation./keys/signer_bip340.go- Sign & VerifyIt should be mentioned that the new CurveType is necessary due to BIP-340's requirement of 32-byte/x-only keys while the existing
rosetta-sdk-gokey interface extends no such ability under the existingSecp256k1curve.CurveType
rosetta-specificationsrosetta-sdk-goKey Importimportof any standardsecp256k1privateKey and drop the first byte (compression odd/even flag) of its associated publicKey per BIP-340 spec to extend backward compatibility.secp256k1's 33-byte compressed publicKey.'Y'coordinates that are a quadratic residue.rosetta-sdk-goKey GenerationYvalue that is a quadratic residue by negating the newly-generated privateKey when its associated public key is found to be 'odd' in its compressed form.References
SignatureType
rosetta-specificationsrosetta-sdk-goSign & VerifyBackwards Compatible
Key Imports: Yes
Everything Else: n/a
Beta Was this translation helpful? Give feedback.
All reactions