Related eBooks

Call it a pay-to-public-key-script-hash (P2PKSH), like so:

  • Locking script:
    OP_HASH160 OP_DATA_20 redeem_script OP_EQUAL
  • Redeem script:
    OP_DATA_20 pubkey OP_CHECKSIG
  • Unlocking script:
    <push signature> <push redeem_script>.

Either way, wallets would have to process a list of keys and compute a 20-byte hash and address corresponding to each key, but address generation would be slightly different.
Total size of prevout + input would be the same in either case:

  • P2PKH address (25 bytes):
    0x76a914 || hash160(pubkey) || 0x88ac
  • P2PKSH address (23 bytes):
    0xa914 || hash160(0x21 || pubkey || 0xac) || 0x87

Spending input script would also be slightly different:

  • P2PKH spend (66 + 34 bytes):
    <push signature> <push pubkey>
  • P2PKSH spend (66 + 36 bytes):
    <push signature> <push (0x21 || pubkey || 0xac)>

Note: || indicates byte concatenation.

Both would require support by applications such as wallets, and both would have the same transaction (input+output) size.
The P2PKSH option has some advantage in that it would make the address relatively smaller and in that it would make all 20-byte outputs indistinguishable from each other.

It wouldn’t make sense to start using this kind of address now, but there was a window of opportunity in the period 2012-2016 so I wondered. If Bitcoin had shipped with P2SH right from the start, would we have only 1 address type?


By pplny

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

Translate »