It is possible, but there's no reason to, especially if the multisig script is inside of a P2SH, a P2WSH, or a P2TR. All the hashing would do is make the spending tx larger.
The primary reason to use pubkey hashes is to make output scripts (and addresses) shorter. Except for bare multisigs, this would not be necessary as the script is hidden inside of a hash already and only revealed at spending time. And with no address for bare multisigs, creating such outputs is much more difficult. So there would be no size benefit from hashing the pubkeys.
People often tout quantum resistance as a reason to hash pubkeys, but even that is completely useless for multisigs done in the normal way. The pubkeys are revealed in the spend, which is also when the pubkey hashes are revealed. So there is no gain from doing that.
Topic: Multisig based on public key hashes instead of public keys (Read 151 times)
Is it possible? And if so, why don't we use public key hashes instead of public keys? For example, let's assume we have first two private keys:
Then, each party can compute its public key:
And then, each party can compute its address:
Sending to address is enough to get it recorded on-chain. If coins were never moved, then it is impossible to know the public key. But it may be possible to create a multisig that is based on such address. For example, we can start from getting hashes for each of them:
And then, we can create 1-of-2 multisig, when revealing only one public key is needed to move the coins:
As far as I know, it should work in theory, but I still cannot confirm it would work in practice. Both paths should be spendable. For Alice, it would be:
And for Bob, it should left "0 1" instead of "1 0" on the stack, so after addition, OP_VERIFY will succeed by consuming OP_TRUE. I am still trying to confirm that on regtest, but I think it should be technically possible to use public key hashes to make a multisig, instead of using public keys.
Code:
alicePrivKey=0000000000000000000000000000000000000000000000000000000000000001
bobPrivKey=0000000000000000000000000000000000000000000000000000000000000002
Code:
alicePubKey=0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
bobPubKey=02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
Code:
aliceAddress=bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
bobAddress=bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp
Code:
aliceHash=751e76e8199196d454941c45d1b3a323f1433bd6
bobHash=06afd46bcdfd22ef94ac122aa11f241244a37ecc
Code:
OP_DUP OP_HASH160 OP_DUP 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUAL OP_SWAP 06afd46bcdfd22ef94ac122aa11f241244a37ecc OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG
Code:
751e76e8199196d454941c45d1b3a323f1433bd6 1 1 1 06afd46bcdfd22ef94ac122aa11f241244a37ecc 1 0 1
1
Jump to: