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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1U5Z8u-0001hk-MD
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Feb 2013 10:00:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.172 as permitted sender)
client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f172.google.com;
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1U5Z8r-0004Au-9a
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Feb 2013 10:00:44 +0000
Received: by mail-ob0-f172.google.com with SMTP id tb18so1058787obb.31
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Feb 2013 02:00:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.159.98 with SMTP id xb2mr16283224obb.35.1360749635913;
Wed, 13 Feb 2013 02:00:35 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.169 with HTTP; Wed, 13 Feb 2013 02:00:35 -0800 (PST)
In-Reply-To: <20130213041209.GA28202@savin>
References: <20130212151108.GA639@savin>
<CABsx9T1P=OC7amNeZivTVcQSb0+=FSKhvAB-XjDzkqq6bc07-g@mail.gmail.com>
<20130213041209.GA28202@savin>
Date: Wed, 13 Feb 2013 11:00:35 +0100
X-Google-Sender-Auth: Xf8-wE4IDWWSUQkVDuNh2Dr8his
Message-ID: <CANEZrP3qgo-VC5YHTSLOH5rGdv5PP4e2V6qECQVfvMgJXFbx-g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=14dae9399a4dad494204d59836a2
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
(mh.in.england[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: 1U5Z8r-0004Au-9a
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN
for marking unspendable txouts
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: Wed, 13 Feb 2013 10:00:45 -0000
--14dae9399a4dad494204d59836a2
Content-Type: text/plain; charset=UTF-8
> So what exactly was the OP_RETURN bug anyway? I know it has something to
> do with not executing the scriptSig and scriptPubKey separately
> (https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
> commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
>
It was fixed by Satoshi long ago, back when we used CVS I think.
The problem was how scripts were executed. They were concatenated together
and then run as a single unit. The now obsolete OP_CODESEPARATOR was put
between them to control what was hashed and what wasn't.
The obvious problem with that arrangement being that scriptSig ran first
(it has to, to push the signatures onto the stack), so nothing stopped you
setting a scriptSig to OP_RETURN and making the script evaluate to true,
always. A pretty amazing oversight given the thought and care that went
into Bitcoin generally, and its robustness since then.
The fix was to move to the current system whereby the two scripts are
executed independently but sharing a stack, and it's only the return value
of the scriptPubKey that matters.
The scripting system always struck me as a rather late addition to the
design. Satoshi admitted as much when he said that he added it after
encountering an explosion of special cases as he designed various types of
contracts. The fact that there's an obvious bug in CHECKMULTISIG is more
evidence of this part being a general rush job, along with Satoshis
willingness to disable much of its functionality later with the IsStandard
checks. Also the design of CHECKSIG is an obvious retrofit, it would have
made far more sense to decompose it, and we never found a use case for 99%
of the opcodes despite having successfully designed (redesigned?) all the
contract types he ever mentioned.
--14dae9399a4dad494204d59836a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
So what exactly was the OP_RETURN bug anyway? I know it has something to<br=
>
do with not executing the scriptSig and scriptPubKey separately<br>
(<a href=3D"https://bitcointalk.org/index.php?topic=3D58579.msg691432#msg69=
1432" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D58579.msg=
691432#msg691432</a>) but<br>
commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged=
.<br></blockquote><div><br></div><div></div></div></div><div class=3D"gmail=
_extra" style>It was fixed by Satoshi long ago, back when we used CVS I thi=
nk.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The problem was how scripts were executed. They were concatenated together=
and then run as a single unit. The now obsolete OP_CODESEPARATOR was put b=
etween them to control what was hashed and what wasn't.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The obvious problem with that arrangement being that scriptSig ran first (=
it has to, to push the signatures onto the stack), so nothing stopped you s=
etting a scriptSig to OP_RETURN and making the script evaluate to true, alw=
ays. A pretty amazing oversight given the thought and care that went into B=
itcoin generally, and its robustness since then.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The fix was to move to the current system whereby the two scripts are exec=
uted independently but sharing a stack, and it's only the return value =
of the scriptPubKey that matters.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The scripting system always struck me as a rather late addition to the des=
ign. Satoshi admitted as much when he said that he added it after encounter=
ing an explosion of special cases as he designed various types of contracts=
. The fact that there's an obvious bug in CHECKMULTISIG is more evidenc=
e of this part being a general rush job, along with Satoshis willingness to=
disable much of its functionality later with the IsStandard checks. Also t=
he design of CHECKSIG is an obvious retrofit, it would have made far more s=
ense to decompose it, and we never found a use case for 99% of the opcodes =
despite having successfully designed (redesigned?) all the contract types h=
e ever mentioned.</div>
<div class=3D"gmail_extra" style><br></div></div>
--14dae9399a4dad494204d59836a2--
|
