Signing `v`

[jannik-stacks]

Question for Fireblocks:
For TransactionOperation.Raw signing with EcdsaSecp256K1, what are the possible values of signature.v in the signedMessages response? Is it
guaranteed to be 0/1, or can it be 27/28? Is this behavior contractual across API versions?

I doubt this is a concern now.
Otherwise it might be good to normalize the signature v byte.

concatSignature doesn't normalize currently, but concatSignerSignature does. Just making sure I'm not missing anything

    const vv = v >= 27 ? v - 27 : v;   // ← this normalization

this.fireblocksService.signTransaction(hash, vaultId)                                                                                            
    → this.fireblocksSigner.rawSign(hash, vaultId)
      → fireblocks.transactions.createTransaction({ operation: Raw, algorithm: EcdsaSecp256K1 })                                                   
      → polls until complete
      → returns txInfo.signedMessages[0].signature   // { fullSig, v }

So if Fireblocks returns v=27 for call site 3 (signer sig), it returns v=27 for call sites 1 and 2 (tx sig) too. Which means either:

• Fireblocks always returns 0/1 — and the normalization in concatSignerSignature is defensive but never actually triggers
• Fireblocks always returns 27/28 — and concatSignature is broken right now, but somehow transactions still work (which wouldn't make sense)
• Fireblocks sometimes returns one or the other — unlikely for the same API/algorithm/vault

But maybe I'm missing something here 🙈

[saraidy]

Double checked, the v retuned in Fireblocks EcdsaSecp256K1 raw signing is indeed always either 1 or 0, so this normalization is redundant, also the concatSignerSignature is now unused as it was called in createSignerSig65HexFromParams which is now unused as the user provides the signature as a parameter to the solo stacking function, the redundant functions were removed