1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bgroff@lavabit.com>) id 1Qx7Uj-0000hI-CW
for bitcoin-development@lists.sourceforge.net;
Sat, 27 Aug 2011 01:15:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=bgroff@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qx7Ui-0000gr-AZ for bitcoin-development@lists.sourceforge.net;
Sat, 27 Aug 2011 01:15:33 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id 7A64C11BC82;
Fri, 26 Aug 2011 20:15:26 -0500 (CDT)
Received: from lavabit.com (122.bint4.interhost.co.il [81.218.219.122])
by lavabit.com with ESMTP id 8P3UXEGXDF2Y;
Fri, 26 Aug 2011 20:15:26 -0500
Received: from 81.218.219.122 (SquirrelMail authenticated user bgroff)
by lavabit.com with HTTP; Fri, 26 Aug 2011 21:15:26 -0400 (EDT)
Message-ID: <1929.81.218.219.122.1314407726.squirrel@lavabit.com>
In-Reply-To: <CABsx9T1RnwLZkBwOipXsscDUbMoiikFTbb2WMkGxhGDO9je3zA@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
<CANEZrP2FYjJXvB=kzu+wBcoGOyL=45QeDqLfyZONxYu-9M50Uw@mail.gmail.com>
<CABsx9T1RnwLZkBwOipXsscDUbMoiikFTbb2WMkGxhGDO9je3zA@mail.gmail.com>
Date: Fri, 26 Aug 2011 21:15:26 -0400 (EDT)
From: bgroff@lavabit.com
To: "Gavin Andresen" <gavinandresen@gmail.com>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
X-Headers-End: 1Qx7Ui-0000gr-AZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 27 Aug 2011 01:15:33 -0000
>> 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 =3D ++i;
> 798 i +=3D nSigsCount;
>
> It should be just int isig =3D 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 counte=
d
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 w=
e
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
|
