[bug] Message signed with ordinal address doesn't work for some users

[elRaulito]

Is there an existing issue for this?

• I have searched the existing issues

SATS-CONNECT Version

2.4.0

Current Behavior

At first we thought it was an issue with bip322-js so we opened an issue with them

ACken2/bip322-js#12

However seems that the signature we got:

AUBeB9HL+fbcTrVOSwzZvSn/oDluEckq0st4YMgr0nelFOT1qpA9HiohI6uGNDQnu47YUbFHWM0CrkiT7VdWf6Na

of the user bc1pvnkl5kgyjnr33yn5myvlqvw0nahnrqx2mj6a8j4ggpy09gvt3pdq4nf2sl is not valid

We have faced this issue a lot lately and apparently only few users are not able to make it work, the code is always the same on our platform

could it be something related to the 02/03 byte in front of ordinal public key that is not used?
Is there a way for us to test with a user that his signature is working fine on xverse?

Users were able to use the platform creating a new wallet on xVerse, so the issue is related to the address itself

Expected Behavior

Signature message verified with bip322-js

Steps To Reproduce

Try to create a limit order at fluidtokens
If your address is not signing the message in a correct way you'll get the error

This error seems to be for a 20% of our users

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)

No response

Anything else?

No response

[teebszet]

thanks for the issue raised @elRaulito , we'll look into this

[victorkirov]

@elRaulito could you please send through an example signature, address and message that was signed when you encounter this again. I can't reproduce on my side unfortunately.

[elRaulito]

Hey @victorkirov here you are, I can provide you even other users that are facing same issue

this following message:

{
    "runeId": "840000:3",
    "orderType": 0,
    "orderPosition": "buy",
    "orderAmount": 1332,
    "orderPrice": 7.51,
    "ownerBtckey": "020bb343eb11c05861b5d5607391a71b14fc941b6e50c52070fbb7c0665e7a48e2",
    "ownerOrdKey": "56f4b67b0ade2e9ba69244db27dd980e58c4445ffb29c60dac4a2c7bc08688ac",
    "ownerBtcAddress": "3KZKi6aWvoZp2BjSYm8X126AeExpqdqvyh",
    "ownerOrdAddress": "bc1pvnkl5kgyjnr33yn5myvlqvw0nahnrqx2mj6a8j4ggpy09gvt3pdq4nf2sl"
}

Generating the signature:
AUBeB9HL+fbcTrVOSwzZvSn/oDluEckq0st4YMgr0nelFOT1qpA9HiohI6uGNDQnu47YUbFHWM0CrkiT7VdWf6Na

[victorkirov]

Could you send me the exact string? Or do you JSON.strigify an object each time on verify? If that's the case, you might be running into an ordering issue:
https://www.reddit.com/r/node/comments/tcr7kn/why_does_jsonstringify_reorder_keys/

[elRaulito]

@victorkirov yes we are using JSON.stringify however if that is the case shouldn't it it be for every user? since keys are the same

Also we are doing JSON.stringify on both frontend signing and on backend on verification shouldn't it work in case of reordering?

[victorkirov]

No, JSON.stringify doesn't guarantee the order that keys will be stringified in. You could get different results each time you call it, but you could also get the same. Cross system/platform for frontend and backend would mean you're even more likely to get different orders. That would explain why it's only failing sometimes, since it's changing the message.

You can either stringify once and pass that string message around, or rather use a format that guarantees the order to remain consistent (e.g. add your items in a specific order into an array and stringify that).

[elRaulito]

But would that explain why it's failing always for same users?

[victorkirov]

It could. If the stringify function on the user's machine always produces X and the function on your server always produces Y, then the messages will always be different.

[elRaulito]

Yes, however when they created a new wallet the error disappeared
We'll try this tho and let you know, thanks a lot!

[victorkirov]

Ah, ok, sorry, I missed that. In that case the client platform remains the same 🤔 It's definitely something to consider as you should never rely on the order of JS object keys, but there may be something else going on here. I'll try to reproduce it on my end as well.

[victorkirov]

I've just run a script that generates a seed phrase, then uses our code to get details for the taproot address for that seed, sign the above message, then verify the message. It ran 28000 times without failure. I'm thinking maybe our signature may not be the problem.

[elRaulito]

Thanks a lot @victorkirov

I guess time to debu JSON.stringify more

Will let you know