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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1U5Thf-0004mU-Vt
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Feb 2013 04:12:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.110 as permitted sender)
client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
helo=outmail148110.authsmtp.com;
Received: from outmail148110.authsmtp.com ([62.13.148.110])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1U5Thd-0000jI-VT for bitcoin-development@lists.sourceforge.net;
Wed, 13 Feb 2013 04:12:15 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r1D4C565036582; Wed, 13 Feb 2013 04:12:05 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r1D4C0HX013943
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 13 Feb 2013 04:12:03 GMT
Date: Tue, 12 Feb 2013 23:12:09 -0500
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20130213041209.GA28202@savin>
References: <20130212151108.GA639@savin>
<CABsx9T1P=OC7amNeZivTVcQSb0+=FSKhvAB-XjDzkqq6bc07-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
In-Reply-To: <CABsx9T1P=OC7amNeZivTVcQSb0+=FSKhvAB-XjDzkqq6bc07-g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 85bb41ce-7593-11e2-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwEUHlAWAgsB AmUbW1BeUV97WWA7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqAGgF dR5mOhlzdAxCezBy ZUVlXT5TWRYocUcu
F1NTEGQFeGZhPWIC AkULch5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4xMBVu Dx0HBSk+VVYOXSQr
MyQ7IH0RDV1ZO0M+ eXwZbmg1DyIoLEVQ GFsvSCpQPVoAQSVj
EAVBRUMYHDRXRSoU Hg0vPwNTagAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1U5Thd-0000jI-VT
Cc: 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 04:12:16 -0000
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 12, 2013 at 12:42:37PM -0500, Gavin Andresen wrote:
> On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > .... Again, thoughts?
> >
>=20
> First: I really like the fidelity bond concept, and want to see it happen.
>=20
> RE: OP_RETURN : I've got a knee-jerk opposition to the OP_RETURN opcode,
> because it was the cause of the nastiest bug ever Bitcoin history. So I'd
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=3D58579.msg691432#msg691432) but
commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
> be more comfortable using either OP_FALSE or OP_INVALIDOPCODE for the
> "provably unspendable" transaction.
You know, come to think of it, OP_FALSE doesn't get used by standard
transactions either, and it's behavior is a little odd in how it does
push to the stack. So lets make the standard OP_INVALIDOPCODE,
specifically 0xFF, and put it at the start of the scriptPubKey.
> RE: anyone-can-spend transactions: Thinking aloud... I wonder if we might
> inadvertently cause "spend storms" on the network; if suddenly there are =
11
> BTC sitting in an anybody-can-spend txout, I could imagine EVERYBODY on t=
he
> network trying to race each other to spend it (maybe assuming that there
> are a few miners on old versions of the software who are too dumb to claim
> it for themselves).
That's a good point. It would encourage efforts to identify as many
Bitcoin nodes as possible, particularly miners, and I don't think we
really want to incentivise that. It's not a problem unique to this
proposal - compromised private keys and SIGHASH_NONE (1) - but
fidelity bonds will give people incentive to develop the infrastructure
to exploit it.
1) Speaking of, maybe I'm missing something, but if I have a
transaction with one or more txin's and sign every signature with
SIGHASH_SINGLE, what stops an attacker from adding their own txout
at the end and diverting the mining fee to themselves?
Having said that, if we both make empty scriptPubKeys standard, and add
code so that miners will always try to spend the outputs for themselves
at the same time, we can get rid of this problem by removing the
incentive. It would also still make non-fidelity-bond uses viable as
well.
Of course, if you want to go down that path, we might as well add code
to detect and spend fidelity bonds too, and make the publish
transactions IsStandard(). Basically for every script in a confirmed
block check if any pushdata op happens to be a script that we would be
willing to add to the mempool at nBlockHeight + N. (assuming current
utxo set) If so, add it to the mempool now. N should be at least 100
blocks I think for the same reason that coinbase tx's take 100 blocks to
spend. The limit also means the size of the mempool can't get larger
than MAX_BLOCK_SIZE * N. Meanwhile IsStandard() would allow the
scriptPubKey OP_INVALIDOPCODE <valid serialized tx>
P2SH already treats data as scripts, so treating data as entire tx's
isn't that big of a leap. Also since the txout is unspendable, the
Satoshi criteria that block-reorgs should not make child tx's vanish is
still met. (though tx mutability sort of breaks this anyway)
We would however open quite a few cans of worms:
1) We just made non-final !IsStandard() for a reason.
2) What if there are transactions already in the mempool that spend the
txin's of the sacrifice? If we ignore them, we've just created another
way to double-spend unconfirmed transactions. On the other hand, if we
don't ignore them, we've just created a way to give us a chance to mine
the sacrifice for ourselves.
Personally I'm with you Gavin and think assuming miners are greedy is
best, but lets just say I probably shouldn't write an implementation
with a function named IsTxOutStealable()?
2a) What if multiple sacrifice publications exist spending the same
txin's? We should have deterministic behavior and mine the most valuable
one. If you don't do that, the attackers effective hashpower is
increased. (and thus the true sacrifice value of the bond decreases)
2b) ...but this is actually an annoying optmization problem. You could
create a whole bunch of sacrifices, each spending two or more inputs,
one small, one large. Then create one large sacrifice, that spends all
the *small* inputs. If the value of the large sacrifice is less than the
combined totals of the smaller sacrifices, you should be mining the
small ones rather than the large for maximum return.
3) With the 10KB limit on scripts, a naive IsStandard() could wind up
recursing about 200 times; we probably should say recursive publish
transactions are non-standard.
3b) ...on the other hand, if they are non-standard, implementations that
use fidelity bonds better make sure they don't accept such monsters.
We probably should just define one standard sacrifice tx form with one
txin, one txout, and a standard P2SH scriptPubKey, but miners can still
do their own thing and cause problems in determining the true value
sacrificed if they don't get the optimization problem right.
Fidelity bonds needs a lot more thought, and a testnet implementation...
--=20
'peter'[:-1]@petertodd.org
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRGxKZAAoJEH+rEUJn5PoE6MYH/0StlBdDOZCRTliX9dUJ547a
LgM0xNIx509rciRodc4muVO3Sjw5dylpo0meyA0WMfVHSeQV9fikCJEybnCBw6YE
sVn8RiELW88EWJgXK0ljtdUdHFG4UqjOqgPLo+z+7pNdxe+eIxQgp9G7mPDBTpgq
15QtaeuSehro34Zfk69DDHoM2ZpRbD3eX+CEYacD/Ay+9LsIxaAVjoU65sGZRNpC
SnaOW9PXGKLUD1eMiTYXsN1LFWMfvpD/BWVyzesJuu6anYhmBqkeRmuvNBErMOOS
Pz4l8L81SZKpa+uNlFlx0pcpbjwlso5FQ68NeYq0NcLGuSAq2rNp5earlsqLI/I=
=cdcH
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
|
