Quote from: bitmover on April 10, 2020, 11:33:32 AM

Quote from: pooya87 on April 10, 2020, 04:01:32 AM

those that can't verify messages signed from a P2WPKH or P2SH/P2WPKH addresses can't do it because that part of their application is not capable of recognizing the "address type".

The problem is that "those that cant" = "all but electrum"

I just found a discussion where you did participate where a user claimed trezor and electrum made different signing methods...
https://bitcointalk.org/index.php?topic=5137069.msg50817536#msg50817536

it is not the method, it is the optional first byte. we don't even need that first byte to verify a message!
let me explain the process of message signing and verification, maybe that helps in understanding why it is so trivial to implement.
the part that is the exact same thing:
1. normalize the input string (message) and add a fixed predefined string (Bitcoin Signed Message:\n) to the beginning then decode (convert to byte array) using UTF8 encoding.
2. compute SHA256 of SHA256 of the result from step 1
3. pass the 32 byte result to the ECDSA function to sign and return signature (r and s).
(* there is an extra step here i'll explain below)
4. encode the signature using base64
To verify:
5. decode signature using base64
6. perform steps 1 and 2 above to get the same hash
7. recover from 0 up to 4 possible public key(s) using result of step 5 and 6 (* extra explanation below)
8. convert the result(s) of step 7 to address of same type as user entered to see if they match
9. publish result of the match to user

these 9 steps are the exact same way that you sign and verify any message using ECDSA. these are sections 4.1.3 Signing Operation and 4.1.4 Verifying Operation and 4.1.6 Public Key Recovery Operation of SEC 1: Elliptic Curve Cryptography standard.
address type doesn't make any difference in these steps at all.

* now the extra step explanation the part that makes things be different:
the thing about public key recovery (step 7) is that it can recover up to 4 possible public keys from a given ECDSA signature on secp256k1 curve (usually it is just one though). it still doesn't make a difference in verification since we can still recover all 4 and check all 4 to see if any match the given address. but we can help the verifier to know which public key is the correct one and by doing that reduce its work.
in bitcoin we use hash of the public key and since hash of compressed key is different from hash of uncompressed key, that also makes a difference. so the verifier has to check up to 8 hashes (addresses) instead. we can help the verifier know this too.
so far both of these are happening by adding an additional byte to the beginning of the signature. it is a number between 27 and 34.
to indicate address type (P2PKH or P2SH/P2WPKH or P2WPKH) they decided to add another value to this first byte.

so in short it is that non-standard self-defined optional first byte that is making some tools not be able to verify the signature created by another tool even if they understand the address.