CHIP-2022-05 Pay-to-Script-Hash-32 (P2SH32) for Bitcoin Cash

Continuing what @bitjson and @johoe have started (recent P2SH32 discussion and 2020 mention), and knowing that Jason is busy with other projects, I went ahead and created a CHIP:

that aims to solve a particular and well known problem with the current P2SH feature: feasible collision against 160-bit hashes in near future; and that in a mimimum-cost way by simply enabling a longer version of the BIP-0016 template:

Existing, P2SH20:

  • Locking script:
    OP_HASH160 OP_DATA_20 hash160(redeem_script) OP_EQUAL
    (raw: a9 14 1122334455667788990011223344556677889900 87).

Proposed, P2SH32:

  • Locking script:
    OP_HASH256 OP_DATA_32 hash256(redeem_script) OP_EQUAL
    (raw: aa 20 1122334455667788990011223344556677889900112233445566778899001122 87).

Both output types will be unlocked the same way:

  • Unlocking script:
    [push data_N] ... [push data_1] [push data_0] <push redeem_script>.

There are other interesting upgrades related to P2SH and our Script VM that we could consider such as making it independent of the stack item limit, as already laid out by Jason, and those may still be proposed in parallel as separate CHIP(s) building on top of this one which secures the critical building block in all future smart UTXO applications.

6 Likes

Thank you for putting this together!

The P2SH vulnerability is indeed something that needs to be fixed now that smart contracts are becoming more important on Bitcoin Cash! P2SH32 is especially important for sidechain covenants like SHA-gate which are likely to be the first contracts to manage a ton of funds.

I support this effort & hope to see the ideas of fixing boolean malleability and the redeem script size limit as extension CHIPs to this one!

4 Likes