the signature changing is ... potentially not expected behavior. I am not sure why it changes. The prefixes are identical. There are some conventions in bitcoinjs-message that could lead to distinct values, i.e. adjusting the recovery byte

https://github.com/bitcoinjs/bitcoinjs-message/blob/master/index.js#L34

does electrum / the node do this?

the signature changing is ... potentially not expected behavior. I am not sure why it changes. The prefixes are identical. There are some conventions in bitcoinjs-message that could lead to distinct values, i.e. adjusting the recovery byte

https://github.com/bitcoinjs/bitcoinjs-message/blob/master/index.js#L34

does electrum / the node do this?

interesting rabbit hole from here

short answer is: should be fine, since sig as utf8 can't have anything outside the 0-255 range, the string (even tho techically utf16) is expected to have the same char restriction

longer answer:

In nodejs, we could skip the whole string.fromCharChode step and just convert uint8array to base64 using Buffer. I've used btoa instead because, historically, using Buffer in libs tends to raise weird issues with browser-based users of libraries. Cashtab required webpack shims for this.

btoa has only recently been added to nodejs

if i console.log and run the test, we can see its implementation

console.log(typeof btoa, 'Where does btoa come from?', btoa.toString());

function Where does btoa come from? function btoa(input) {
  // The implementation here has not been performance optimized in any way and
  // should not be.
  // Refs: https://github.com/nodejs/node/pull/38433#issuecomment-828426932
  if (arguments.length === 0) {
    throw new ERR_MISSING_ARGS('input');
  }
  input = `${input}`;
  for (let n = 0; n < input.length; n++) {
    if (input[n].charCodeAt(0) > 0xff)
      throw lazyDOMException('Invalid character', 'InvalidCharacterError');
  }
  const buf = Buffer.from(input, 'latin1');
  return buf.toString('base64');
}

...so in nodejs environments, it's ultimately using Buffer anyway. We know that it is working in nodejs because the mocha tests pass, and we know it is working in the browser because it is working in Cashtab.

We could take these alt approaches to avoid btoa:

• use Buffer and trust js devs to get webpack right, or perhaps our own typescript build could be modified to ensure Buffer is polyfilled at the build step
• Use an npm lib for base64 conversions, like https://www.npmjs.com/package/base64-js

imo it's best to just use btoa since we know it works in nodejs and the browser without any further adjustments, and it prevents us from needing a lib which, while popular and free of its own deps, has not been updated in 4 years and still would be another supply chain concern.

I think it's best to just keep this function boolean with no error throwing.

This does mean a hypothetical user with a valid but non-base64-encoded signature could get the "technically wrong" answer that a signature is invalid. I haven't come across this issue. If it's important for a lib user, they can validate for this in their input field.

If we added this type of error throwing, it would mean that all implementers would need to try...catch for verifyMsg, to handle instances like "user has copy pasted a base64 signature into the check field, but then backspaced a character" -- the most common case would be bad input (signature is indeed wrong) -- the case of a correct but non-base64 sig would I think be niche .... and if we specifically only throw for this case, we might as well accept non-base64-but-still-valid sigs.