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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1WwzFL-0000Dg-M7
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 19:40:43 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.179 as permitted sender)
client-ip=209.85.160.179; envelope-from=gavinandresen@gmail.com;
helo=mail-yk0-f179.google.com;
Received: from mail-yk0-f179.google.com ([209.85.160.179])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwzFJ-0001UB-Tp
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 19:40:43 +0000
Received: by mail-yk0-f179.google.com with SMTP id 20so5567861yks.24
for <bitcoin-development@lists.sourceforge.net>;
Tue, 17 Jun 2014 12:40:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.31.135 with SMTP id m7mr47899845yha.104.1403034036373;
Tue, 17 Jun 2014 12:40:36 -0700 (PDT)
Sender: gavinandresen@gmail.com
Received: by 10.170.223.70 with HTTP; Tue, 17 Jun 2014 12:40:36 -0700 (PDT)
Date: Tue, 17 Jun 2014 15:40:36 -0400
X-Google-Sender-Auth: nPGq-eq9UqvjUesf9F7FL4VYm9g
Message-ID: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com>
From: Gavin Andresen <gavin@bitcoinfoundation.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0160d100589dfb04fc0d5127
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WwzFJ-0001UB-Tp
Subject: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH
transactions
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: Tue, 17 Jun 2014 19:40:43 -0000
--089e0160d100589dfb04fc0d5127
Content-Type: text/plain; charset=UTF-8
Assuming there is rough consensus, I'll make this a pull request (see
https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
changes).
----
Now that we are finally starting to see the use of multi-signature and
other more complicated transaction forms in applications I think it is time
to open up the "IsStandard" transaction rules on the main Bitcoin network.
There are two main risks to doing this:
1. The risk that one of the seldom-used opcodes has a not-yet-discovered
chain-forking bug. I believe that risk to be very low; we have never seen
such a bug on the test network (where all transaction forms are allowed)
and have never found a bug after writing extensive unit tests.
2. The risk of opening up a denial-of-service attack (either bloat the
blockchain or use an excessive amount of CPU time) via a very
expensive-to-store-or-verify transaction. This proposal does not entirely
eliminate IsStandard checks to mitigate the potential for DoS attacks.
Proposal
--------
Allow any Script containing 15 or fewer signature operations as a
pay-to-script-hash (P2SH) Script to be relayed and mined by the reference
implementation.
This should be a simple change to the AreInputsStandard() method in the
reference implementation.
Discussion
----------
P2SH Scripts are limited to 520 bytes, and are currently limited to one of
the "standard" transaction forms on the main network. In practice that
means you can currently encode a n-of-15 OP_CHECKMULTISIG which can be
redeemed as a 'standard' transaction.
Allowing any P2SH Script would allow an attacker to craft a single standard
transaction output that requires on the order of 200 ECDSA signature
checking operations to validate-- an order of magnitude more than is
currently allowed. Therefore I am proposing that we keep the current
15-signature-checking-operations-per-transaction-output limit in place, but
allow any combination of enabled Script opcodes. So, for example, you might
have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using:
```
OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4
pubkey5 3 OP_CHECKMULTISIG OP_ENDIF
```
(this would count as 5 signature operations)
Restricting arbitrary Scripts to P2SH transaction types limits unspent
transaction output set bloat in two ways:
1. The Scripts are not stored in UTXO set.
2. They are limited to 520 bytes by the Script rule on the amount of data
that can be pushed onto the stack.
The reference implementation's wallet will still only recognize P2SH
transactions that use one of the standard transaction forms. To actually
USE a new transaction form will require specialized wallets or specialized
applications.
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--089e0160d100589dfb04fc0d5127
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Assuming there is rough consensus, I'll make this a pu=
ll request (see <a href=3D"https://github.com/gavinandresen/bitcoin-git/tre=
e/relax_isstandard">https://github.com/gavinandresen/bitcoin-git/tree/relax=
_isstandard</a> for code changes).<br>
<br>----<br><br>Now that we are finally starting to see the use of multi-si=
gnature and other more complicated transaction forms in applications I thin=
k it is time to open up the "IsStandard" transaction rules on the=
main Bitcoin network.<br>
<br>There are two main risks to doing this:<br><br>1. The risk that one of =
the seldom-used opcodes has a not-yet-discovered chain-forking bug. I belie=
ve that risk to be very low; we have never seen such a bug on the test netw=
ork (where all transaction forms are allowed) and have never found a bug af=
ter writing extensive unit tests.<br>
2. The risk of opening up a denial-of-service attack (either bloat the bloc=
kchain or use an excessive amount of CPU time) via a very expensive-to-stor=
e-or-verify transaction. This proposal does not entirely eliminate IsStanda=
rd checks to mitigate the potential for DoS attacks.<br>
<br>Proposal<br>--------<br>Allow any Script containing 15 or fewer signatu=
re operations as a pay-to-script-hash (P2SH) Script to be relayed and mined=
by the reference implementation.<br><br>This should be a simple change to =
the AreInputsStandard() method in the reference implementation.<br>
<br>Discussion<br>----------<br>P2SH Scripts are limited to 520 bytes, and =
are currently limited to one of the "standard" transaction forms =
on the main network. In practice that means you can currently encode a n-of=
-15 OP_CHECKMULTISIG which can be redeemed as a 'standard' transact=
ion. <br>
<br>Allowing any P2SH Script would allow an attacker to craft a single stan=
dard transaction output that requires on the order of 200 ECDSA signature c=
hecking operations to validate-- an order of magnitude more than is current=
ly allowed. Therefore I am proposing that we keep the current 15-signature-=
checking-operations-per-transaction-output limit in place, but allow any co=
mbination of enabled Script opcodes. So, for example, you might have a P2SH=
Script that is redeemed with 2-of-2 OR 2-of-3 using:<br>
```<br>OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4=
pubkey5 3 OP_CHECKMULTISIG OP_ENDIF<br>```<br>(this would count as 5 signa=
ture operations)<br><br>Restricting arbitrary Scripts to P2SH transaction t=
ypes limits unspent transaction output set bloat in two ways:<br>
1. The Scripts are not stored in UTXO set.<br>2. They are limited to 520 by=
tes by the Script rule on the amount of data that can be pushed onto the st=
ack.<br><br>The reference implementation's wallet will still only recog=
nize P2SH transactions that use one of the standard transaction forms. To a=
ctually USE a new transaction form will require specialized wallets or spec=
ialized applications.<br clear=3D"all">
<div><br></div>-- <br>--<div>Gavin Andresen</div><div>Chief Scientist, Bitc=
oin Foundation</div><div><a href=3D"https://www.bitcoinfoundation.org/" tar=
get=3D"_blank">https://www.bitcoinfoundation.org/</a></div><div><br></div>
</div>
--089e0160d100589dfb04fc0d5127--
|
