bgroff at lavabit.com [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-26 🗒️ Summary of this message: The proposal to ...

📅 Original date posted:2011-08-26
🗒️ Summary of this message: The proposal to whitelist the basic CHECKMULTISIG form seems uncontroversial, but there are some disadvantages to using it, such as the limit of 1000 in a block and the complexity of using HASH160 based addresses. The suggestion is to focus on a more general case to make it easier to validate and innovate with new scripts.
📝 Original message:>> Whitelisting the basic CHECKMULTISIG form (assuming it can be made to
>> work) seems uncontroversial, why not do it today?
>
> That seems like the right way forward.
>
> I just wrote a unit test and stepped through the CHECKMULTISIG code to
> see exactly what the bug is, and the offending line is:
> 797 int isig = ++i;
> 798 i += nSigsCount;
>
> It should be just int isig = i;
>
> The result is CHECKMULTISIG expects one extra item on the stack, so
> the workaround would be a standard transaction type of the form:
>
> scriptSig: OP_0 sig1...m
> scriptPubKey: m pubkey1...n n OP_CHECKMULTISIG

Right, that is the workaround in pull 319.

There is another disadvantage to CHECKMULTISIG - you currently can only
have 1000 of these in a block. This is because a CHECKMULTISIG is counted
as 20 sigop operations in GetSigOpCount, and you can have a maximum of
20000 sigops in a block (MAX_BLOCK_SIGOPS). This is in CheckBlock so
won't change anytime soon.

If you want to use HASH160 based addresses, CHECKMULTISIG looks even less
attractive. The shortest script with CHECKSIG is something like:

0
OVER 2SWAP CHECKSIG SWAP HASH160 {} EQUAL BOOLAND ADD // n times
m GREATERTHANOREQUAL

( thanks to coblee
https://gist.github.com/39158239e36f6af69d6f#gistcomment-47017 )

I think this is actually as short as the shortest you can do with
CHECKMULTISIG.

Another issue that came up during pull 319 discussion is whether to
support more general cases or more specific cases. For example, should we
optimize for the 1-of-2, 2-of-2 and 2-of-3 cases or should we just have
one script template for all m-of-n? I would propose focusing on a more
general case for the following reasons:

* It is easier to validate one general algorithm than an expanding set of
special-purpose functions. For example, I think the most people on this
list can validate the coblee script above for all n and m, but faced with
a bunch of special purpose scripts they might miss a bug.

* We don't have to expose the most general cases to the API, but it would
be nice if we didn't have to keep changing IsStandard as people find use
cases for 2-of-4, etc. With IsStandard remaining narrow, innovation with
new scripts is stifled because most client won't mine or relay
non-standard transactions.

* It would be less work for third-party software to track this
(blockexplorer, android wallet).

--
Bobby Groff