is P2SH the most prominent Bitcoin soft fork

[Zilon]

I learnt it was introduced in April 2012 been standardised in BIP16. With the pure intent of simplifying the security model of Bitcoin using Bitcoin scripting language. Where the  redeem hash provided by the sender must get a corresponding redeem-script from the recipient and a signature script in the UTXO.

Can we call it a perfect transition from P2MS since P2MS is limited to just 3 public keys and will require 2 of 3 to spend an UXTO. whereas P2SH gives room for custom redeem script encircled by HASH160 and EQUAL opcodes of the script hash

 if P2SH is replacing P2MS will it be seen as the most prominent or is there a new BIP that has better qualities?

[1714951021]

1714951021

[1714951021]

1714951021

[1714951021]

1714951021

[pooya87]

Can we call it a perfect transition from P2MS since P2MS is limited to just 3 public keys and will require 2 of 3 to spend an UXTO.

AFAIK there are only standard rules that are limiting P2MS compared to P2SH (multisig) otherwise the only limiting factor in any MultiSig scripts is MAX_PUBKEYS_PER_MULTISIG (=20) and the OP/SigOp count as far the consensus rules are concerned.

whereas P2SH gives room for custom redeem script

Technically you can pay to any custom script (in your scriptpub). The benefit of P2SH is that it uses the hash of the script so you don't need to reveal that script and also it helps you create an address (something you can't do in P2MS or any custom output script) and give that address to others to pay you.

this brings me to my question if P2SH is the most prominent or is there a new BIP that has better qualities?

P2SH is one of the early changes to the consensus rules that involved the bitcoin scripts, I don't know if it is the most prominent though.

due to bug on P2SH multi-signature

That is not a bug in P2SH, it is a bug in OP_CHECKMULTISIG(VERIFY)
I also don't think it was a bug but an intentional "feature" to have an open room for future soft forks where the dummy item is used for something while still being backward compatible.

[pooya87]

Thanks for the correction. Although i notice few website has vague explanation about it. For example bitcoin.org describe as implementation bug which preserved for compatibility.

It most probably is a bug, I'm just floating the idea about possible plans for the dummy item in early days. Something like the plans Satoshi had for OP codes that are disabled today.

[garlonicon]

Multisig has n^2 complexity. So I guess it was just the number of the public key to start with, because then you can make it linear.

CHECKMULTISIG has a stupid design where it has to use trial and error.

Say your stack looks like 0 [sig3] [sig2] 2 [pub3] [pub2] [pub1] 3  with sig3 and sig2 being signatures with pubkeys 3 and 2 respectively.

The validation will first attempt to verify with pub1 and sig2, which will fail. Then it will try pub2 and sig2 which will be successful.

This is pointlessly inefficient and in a batch validation *no* signature can fail or otherwise the whole batch fails. In something like a 1 of 20 signature every node could be forced to process 20 failing signatures just to find the one passing one.

Perhaps Satoshi had intended to use the dummy value to indicate which signatures were in use, but that was never implemented.

The checksigadd construction avoids the inefficiency and makes batch validation possible-- because no checksig(add) input is allowed to fail except for an empty signature regardless of what the surrounding script does.  It also works equally well for weighed thresholds without losing any efficiency.

[Zilon]

Technically you can pay to any custom script (in your scriptpub). The benefit of P2SH is that it uses the hash of the script so you don't need to reveal that script and also it helps you create an address (something you can't do in P2MS or any custom output script) and give that address to others to pay you.

I was thinking since i can create my own custom redeem script that can be shared with people who will need to pay me using the script  hashed inside another hash that is to say " The script is first hashed using HASH160 then hashed  again with Equal Opcodes to conceal the initial script as you pointed. just confirming if i am not far from the point

That is not a bug in P2SH, it is a bug in OP_CHECKMULTISIG(VERIFY)
I also don't think it was a bug but an intentional "feature" to have an open room for future soft forks where the dummy item is used for something while still being backward compatible.

That means the bug was doesn't need to the removed just for compatibility sake of nodes that aren't upgraded yet.

[pooya87]

I was thinking since i can create my own custom redeem script that can be shared with people who will need to pay me using the script  hashed inside another hash that is to say " The script is first hashed using HASH160 then hashed  again with Equal Opcodes to conceal the initial script as you pointed. just confirming if i am not far from the point

Yeah, the benefit is that you give an address instead of a hard-to-transfer script. But there is only one HASH160 applied to the script (RIPEMD160 of SHA256 of the script).

That means the bug was doesn't need to the removed just for compatibility sake of nodes that aren't upgraded yet.

Yes, otherwise the old nodes would reject any transaction that doesn't have that dummy item. But we could add an additional limitation to require the dummy item to always be OP_0 (one byte) instead of arbitrary. This change was still backward compatible.