From: bgroff@lavabit•com
To: "Gavin Andresen" <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
Date: Fri, 26 Aug 2011 21:15:26 -0400 (EDT) [thread overview]
Message-ID: <1929.81.218.219.122.1314407726.squirrel@lavabit.com> (raw)
In-Reply-To: <CABsx9T1RnwLZkBwOipXsscDUbMoiikFTbb2WMkGxhGDO9je3zA@mail.gmail.com>
>> 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
next prev parent reply other threads:[~2011-08-27 1:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 15:12 Gavin Andresen
2011-08-24 15:17 ` Rick Wesson
2011-08-24 15:45 ` Gregory Maxwell
2011-08-24 15:55 ` Rick Wesson
2011-08-24 16:05 ` Douglas Huff
2011-08-24 16:15 ` Luke-Jr
2011-08-24 16:46 ` Gregory Maxwell
2011-08-24 17:03 ` Luke-Jr
2011-08-24 17:07 ` Rick Wesson
2011-08-24 17:19 ` Gregory Maxwell
2011-08-24 17:40 ` Rick Wesson
2011-08-24 17:57 ` Gavin Andresen
2011-08-24 18:45 ` Jeff Garzik
2011-08-25 7:39 ` Michael Grønager
2011-08-25 17:18 ` Gavin Andresen
2011-08-26 10:50 ` Mike Hearn
2011-08-27 1:36 ` bgroff
2011-08-25 18:31 ` Gregory Maxwell
[not found] ` <20110825201026.GA21380@ulyssis.org>
2011-08-25 20:29 ` Gregory Maxwell
2011-08-25 21:06 ` Pieter Wuille
2011-08-24 17:03 ` theymos
2011-08-24 17:47 ` bgroff
2011-08-24 19:05 ` Christian Decker
2011-08-24 20:29 ` Gregory Maxwell
2011-08-24 22:27 ` Douglas Huff
2011-08-25 21:30 ` Christian Decker
2011-08-26 11:42 ` Mike Hearn
2011-08-26 19:44 ` Gavin Andresen
2011-08-27 1:15 ` bgroff [this message]
2011-08-24 16:18 Pieter Wuille
2011-08-24 16:26 ` Luke-Jr
2011-08-25 20:14 Pieter Wuille
2011-08-26 11:09 ` Mike Hearn
2011-08-26 21:30 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1929.81.218.219.122.1314407726.squirrel@lavabit.com \
--to=bgroff@lavabit$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox