For everyone else: There's no need for a signed message or transaction ID since it's a made up scenario of scammer who doesn't know how Bitcoin address works.
He wanted to pass that he "
accidentally" typed the wrong last character thinking that it wont invalidate the address.
The alleged address that received the 4.37BTC doesn't have the correct checksum,
thus any well-written wallet wont be able to send to it.
You can try it in any wallet that you use.
Some technical explanations:
- Address 1L1UduuGPZ8ttGe59F2w9tTEumQFhtxiuT, base58 decoded, separated the last 4Bytes checksum: 00d08175a8f7d52324279706dae9d132e17a1bfce8 8c7b316e
- The first 4-Bytes of the SHA256x2 hash of the above's left part should be equal to the right part (checksum): 8c7b316e.
- So let's get: SHA256[SHA256(00d08175a8f7d52324279706dae9d132e17a1bfce8)]: 8c7b316c28e25f67a1b027243d1b9558c15a7efb10e8e283c2ce9e12f89f794a
- The first 4-Bytes of the above are: 8c7b316c which isn't equal to 8c7b316e.
- With that, the address is invalid.
On a slim chance that the exchange/wallet is miswritten to accept such address:
Since it's only the checksum part that's wrong, the output should still be sent to the address with the correct checksum, thus, to his own address ending with "
R".
That's because Bitcoin P2PKH outputs aren't actually addresses but "
scriptPubkey" or "
locking script" which is in the first part of the decoded data above.
It's a different scenario if he edited one character that's not part of the checksum instead since it would be sent to another address. (
only if a buggy wallet allows it)
There's a 1 out of 32bit chance (
4-Bytes) that it will be valid to any wallets, that's 1 out of 4,294,967,296 (
2^32).