0

I am reading "Mastering Bitcoin" by Andreas Antonopoulos. In the transactions section, the locking script for normal account(single address) is

OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG

Which I'm sure that <Cafe Public Key Hash> is the address of the recipient. But the locking script for multsig account is,

2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG

My question is that why does the locking script for multsig address contain their public keys instead of PubKeyHashes(addresses)? And also isn't it dangerous for the receiving party(multsig owners) to reveal their public keys to senders..Long shot but if ECDSA breaks, they can't be secure with SHA256 and RIPEMD160 right?

2
  • Are you talking about bare multisig (where the locking script with pubkeys goes into the scriptPubKey directly), or about P2SH/P2WSH multisig, where the scriptPubKey only contains a hash of the locking script? Both are possible, but the former is very uncommon (as it doesn't have a corresponding address type, so most wallets can't be instructed to create such outputs). Commented Oct 10, 2021 at 16:34
  • Yes, I'm aware of P2SH addresses of the multsig scipt. But I'm interested in knowing why the underlying raw script has PubKeys instead of addresses. Commented Oct 11, 2021 at 4:50

1 Answer 1

2

My question is that why does the locking script for multsig address contain their public keys instead of PubKeyHashes(addresses)?

Why would it?

The reason for using a hash of the public key in P2PKH is because it resulted in shorter addresses (in Satoshi's time, before compressed public keys, public keys were 65 bytes, so using a 20-byte hash was significantly shorter). Such an argument does not exist for bare multisig, because there exists no address for bare multisig.

In P2SH (or P2WSH) multisig, the issue does not apply either, because what is given to the sender is an address that only contains a hash of the locking script. Whether or not that script uses pubkeys or pubkey hashes does not affect the size of that hash. Using an additional redirection inside the script there would also just be a waste of resources (because at spend time, both the pubkey hashes (inside the locking script) and the full public keys (as inputs to it) would need to be passed).

And also isn't it dangerous for the receiving party(multsig owners) to reveal their public keys to senders

There are certain cases where the senders will know the receiver's public keys, but in general, this is not the case. As said, no bare multisig address type exists, so most commonly, P2SH or P2WSH multisig is used. In that case, the sender only receives the script hash from the recipient.

Regarding the security reduction, my own (and apparently somewhat controversial) opinion is that the pubkey hashing does not meaningfully contribute to Bitcoin's security, and while it is frequently repeated, this is cargo cult. Reasons are:

  • If ECDSA is broken, any attacker cooperating with miners can already exploit it (because unconfirmed transactions reveal public keys).
  • Millions of BTC are stored in outputs with publicly known public keys. You can't realistically hope that BTC holds any value after it's assumed ECDSA is broken (as long as ECDSA is commonly used).
  • Tons of interesting use cases involve revealing public keys to other parties (such as Lightning, or even just multisig between the signers). If we were seriously concerned about ECDSA's security, we shouldn't just be discouraging these, but going as far as outlawing them. That doesn't happen, because ECDSA is part of Bitcoin's security assumptions. Dealing with it being broken is done by migrating to something else, not by patching it up.

There are other answers on this site which go into more detail about it.

1
  • Thanks for clarification! Commented Oct 12, 2021 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.