Skip to main content
Bitcoin

Return to Question

added 8 characters in body
Source Link
bca-0353f40e
bca-0353f40e
  • 1.2k
  • 3
  • 18

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?

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 with P2SH right from the start, would we have only 1 address type?

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?

Source Link
bca-0353f40e
bca-0353f40e
  • 1.2k
  • 3
  • 18

Why wrapping P2PK inside P2SH didn't catch on?

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 with P2SH right from the start, would we have only 1 address type?