From d2a386cf7f19a60dab65f6e1404b5dd9c2b0983b Mon Sep 17 00:00:00 2001 From: krupawan5618 Date: Fri, 5 Mar 2021 17:54:26 -0500 Subject: [PATCH] Update ch07.asciidoc Aim is to clarify the current restrictions of standard multisig vs. P2SH. The aim is to further clarify why a transaction would be invalid, in each perspective. On a technical note, saying that it 'invalidates the transaction' may not be correct, but my current understanding is that a 2 of 5 multisig transaction would enter the mempool but then become invalid by nodes. On the other hand, nodes wouldn't have a way to tell if a P2SH hash has within it 15 public keys as it is just a hash; therefore, the only way to tell is to analyze unlocking script of a transaction in input, unless the basis for 15 public keys is a size restriction? Thank you --- ch07.asciidoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index d179253f..23cc11ec 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -177,7 +177,10 @@ If the redeem script hash matches, the unlocking script is executed on its own, 2 PK1 PK2 PK3 PK4 PK5 5 CHECKMULTISIG ---- -Almost all the scripts described in this chapter can only be implemented as P2SH scripts. They cannot be used directly in the locking script of an UTXO.((("", startref="mohamseven"))) +[TIP] +==== +Remember, standard multisignature scripts are limited to at most 3 listed public keys (as determined by IsStandard() function), while P2SH allows for up to 15 public keys. For example, using a 2 of 5 standard multisignature locking script cannot be used directly in the locking script of an UTXO and would invalidate the transaction. Furthermore, a transaction input cannot include more than 15 public keys to redeem a P2SH. ((("", startref="mohamseven"))) +==== ==== P2SH Addresses