Bitcoin Forum
April 26, 2024, 03:02:49 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Multisig based on public key hashes instead of public keys  (Read 123 times)
coinlatte (OP)
Newbie
*
Offline Offline

Activity: 21
Merit: 16


View Profile
April 28, 2022, 07:39:57 PM
Merited by hugeblack (3), NeuroticFish (1), ABCbits (1)
 #1

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:
Code:
alicePrivKey=0000000000000000000000000000000000000000000000000000000000000001
bobPrivKey=0000000000000000000000000000000000000000000000000000000000000002
Then, each party can compute its public key:
Code:
alicePubKey=0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
bobPubKey=02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
And then, each party can compute its address:
Code:
aliceAddress=bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
bobAddress=bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp
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:
Code:
aliceHash=751e76e8199196d454941c45d1b3a323f1433bd6
bobHash=06afd46bcdfd22ef94ac122aa11f241244a37ecc
And then, we can create 1-of-2 multisig, when revealing only one public key is needed to move the coins:
Code:
OP_DUP OP_HASH160 OP_DUP 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUAL OP_SWAP 06afd46bcdfd22ef94ac122aa11f241244a37ecc OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG
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:
Code:
<sigAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice> 751e76e8199196d454941c45d1b3a323f1433bd6
<sigAlice> <pubkeyAlice> <hashAlice> 1
<sigAlice> <pubkeyAlice> 1 <hashAlice>
<sigAlice> <pubkeyAlice> 1 <hashAlice> 06afd46bcdfd22ef94ac122aa11f241244a37ecc
<sigAlice> <pubkeyAlice> 1 0
<sigAlice> <pubkeyAlice> 1
<sigAlice> <pubkeyAlice>
1
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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714143769
Hero Member
*
Offline Offline

Posts: 1714143769

View Profile Personal Message (Offline)

Ignore
1714143769
Reply with quote  #2

1714143769
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3374
Merit: 6535


Just writing some code


View Profile WWW
April 28, 2022, 08:49:39 PM
Merited by EFS (8), NeuroticFish (4), ABCbits (4), hugeblack (4), pooya87 (2), BlackHatCoiner (2), DdmrDdmr (1)
 #2

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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!