The latest updates on your projects. Learn more about Vercel for Git ↗︎

The stacks.js implementation should be following the standards.

Which standards? I don't think any of the SIPs talk about signature order explicitly.

I assume this change breaks transaction signing as-is. Did you try that @pradel?

nextSignature() in stacks.js:

https://github.com/hirosystems/stacks.js/blob/20b721cdccc2fb73f98aad80eb6d5e8e9cb987d0/packages/transactions/src/authorization.ts#L326-L346

from_secp256k1_recoverable in stacks-blockchain uses vrs order:

https://github.com/stacks-network/stacks-blockchain/blob/26bfd5fcdc1f25106288f18ced05290b569f6abb/stacks-common/src/util/secp256k1.rs#L90-L99

CVM special function special_secp256k1_recover in stacks-blockchain uses rsv order:

https://github.com/stacks-network/stacks-blockchain/blob/26bfd5fcdc1f25106288f18ced05290b569f6abb/clarity/src/vm/functions/crypto.rs#L108-L149

(Is that correct @jcnelson?)

Which standards? I don't think any of the SIPs talk about signature order explicitly.

I understood SIP018 was specifying this from the previous conversations.

I assume this change breaks transaction signing as-is. Did you try that @pradel?

I didn't, so far the transactions tests are still failing on this pr, I am not sure what would be the best way to fix them to make sure other components do not break.

just as a suggestion -- I modified the signature to accept a mode param in micro-stacks

https://github.com/fungible-systems/micro-stacks/blob/1d679a08e874a9d94ef6f3ce9c8d4d44b8b60148/src/transactions/keys.ts#L172

so that nothing would break for legacy implementations, but for new applications they can opt into the different order.

I understood SIP018 was specifying this from the previous conversations.

Ah I see! Yes I think SIP018 is the only SIP that discusses signature order. However, the Stacks blockchain appears to be using both vrs (for transactions) and rsv (for the Clarity functions).

I didn't, so far the transactions tests are still failing on this pr, I am not sure what would be the best way to fix them to make sure other components do not break.

Perhaps the least confusing option for developers integrating with stacks.js would be to have a separate signMessage or signStructuredData function that returns the signature in the expected rsv format. Then we can also add counterparts verifyMessage and verifyStructuredData.

@aulneau solution is good too but definitely more advanced. (Developers would have to understand signatures and ordering to make an informed decision.)