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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WRRgP-0006jU-GK
for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 19:34:17 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WRRgO-00025q-9A for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 19:34:17 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2MJYAOt013724;
Sat, 22 Mar 2014 19:34:10 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 s2MJY6cq004931
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 22 Mar 2014 19:34:09 GMT
Date: Sat, 22 Mar 2014 15:34:35 -0400
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@monetize.io>
Message-ID: <20140322193435.GC6047@savin>
References: <20140322084702.GA13436@savin>
<CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7"
Content-Disposition: inline
In-Reply-To: <CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: f08f9f5f-b1f8-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAAUFVQGAgsB AmIbWl1eU1l7WWo7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrA2F7 bxhNExlycwxFeTBy ZURgWD4NXEwsfBB4
FFMGFDsOeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4rFzgw QxEEEn0qHEsIXW06
Ixs+Nl8bGg4eKEw5 PFU8XVYJexEVEG8W EkRHDSNVKlVJTC0t
Fg5cRlMFWCZMWjtR BwZgPB5BSjBVRyBc CQ5eUxwJByJDX25S
RS5ZWyYgSVI4Ykwn P0zM
X-Authentic-SMTP: 61633532353630.1024: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: 1WRRgO-00025q-9A
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for
embedded consensus systems via double-spending/replace-by-fee
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, 22 Mar 2014 19:34:17 -0000
--oJ71EGRlYNjSvfq7
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Tim=F3n wrote:
> On 3/22/14, Peter Todd <pete@petertodd.org> wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN <data> length getting reduced to a rather useless 40 bytes at
> > the last minute prior to the 0.9 release.
>=20
>=20
> I'm not against about miners accepting transactions that have longer
> data in non-utxo polluting OP_RETURN than whatever is specified as
> standard by the reference implementation, maybe it should be risen in
> standard but I think it was assumed that the most common case would be
> to include the root hash of some "merklized" structure.
> My only argument against non-validated proof of publication is that in
> the long run it will be very expensive since they will have to compete
> with transactions that actually use the utxo, a feature that is more
> valuable. But that's mostly speculation and doesn't imply the need for
Well remember that my thinking re: UTXO is that we need to move to a
system like TXO commitments where storing the entirety of the UTXO set
for all eternity is *not* required. Of course, that doesn't necessarily
mean you can't have the advantages of UTXO commitments, but they need to
be limited in some reasonable way so that long-term storage requirements
do not grow without bound unreasonably. For example, having TXO
commitments with a bounded size committed UTXO set seems reasonable; old
UTXO's can be dropped from the bounded sized set, but can still be spent
via the underlying TXO commitment mechanism.
> any action against it. I would strongly opposed to against a
> limitation on OP_RETURN at the protocol level (other than the block
> size limit itself, that is) and wouldn't mind if they're removed from
> isStandard. I didn't payed much attention to that and honestly I don't
> care enough.
>
> Maybe this encourages miners to adopt their own policies, which could
> be good for things like replace-by-fee, the rational policy for
> miners, which I strongly support (combined with game theory can
> provide "instant" transactions as you pointed out in another thread).
>=20
> Maybe the right approach to keep improving modularity and implement
> different and configurable mining policies.
Like I said the real issue is making it easy to get those !IsStandard()
transactions to the miners who are interested in them. The service bit
flag I proposed + preferential peering - reserve, say, 50% of your
peering slots for nodes advertising non-std tx relaying - is simple
enough, but it is vulnerable to sybil attacks if done naively.
> > All these methods have some overhead compared to just using OP_RETURN
> > and thus cost more.
>=20
> I thought the consensus was that op_return was the right way to put
> non-validated data in the chain, but limiting it in standard policies
> doesn't seem consistent with that.
Right, but there's also a lot of the community who thinks
proof-of-publication applications are bad and should be discouraged. I
argued before that the way OP_RETURN was being deployed didn't actually
give any reason to use it vs. other data encoding methods.
Unfortunately underlying all this is a real ignorance about how Bitcoin
actually works and what proof-of-publication actually is:
14-03-20.log:12:47 < gavinandresen> jgarzik: RE: mastercoin/OP_RETURN:
what's the current thinking on Best Way To Do It? Seems if I was to do
it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the
real data from a DHT or website (or any-of-several websites).
Blockchain as reference ledger, not as data storage.
> Peter Todd, I don't think you're being responsible or wise saying
> nonsense like "merged mined chains can be attacked for free" and I
> suggest that you prove your claims by attacking namecoin "for free",
> please, enlighten us, how that's done?
I think we're just going to have to agree to disagree on our
interpretations of the economics with regard to attacking merge-mined
chains. Myself, I'm very, very wary of systems that have poor security
against economically irrational attackers regardless of how good the
security is, in theory, against economically rational ones.
Again, what it comes down to in the end is that when I'm advising
Mastercoin, Counterparty, Colored Coins, etc. on how they should design
their systems I know that if they do proof-of-publication on the Bitcoin
blockchain, it may cost a bit more money than possible alternatives per
transaction, but the security is very well understood and robust. Fact
is, these applications can certainly afford to pay the higher
transaction fees - they're far from the least economically valuable use
of Blockchain space. Meanwhile the alternatives have, at best, much more
dubious security properties and at worse no security at all.
(announce/commit sacrifices is a great example of this, and very easy to
understand)
--=20
'peter'[:-1]@petertodd.org
0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91
--oJ71EGRlYNjSvfq7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTLeXHXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAyZmQ5NDk3NzA1MjRlZWE1NDQ0NmFkYjcwNjAzYTkwYTRj
NDkzZDM0NWY4OTBlMDQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfskagf/ZI8FdcBzDQHJIcN0GaJ0nW4F
4/Zcgjf2vVmW3VyeXcL3U1YTx/MuYx2aUS2a8RAiezPXwpXZe25ao3MEacPcAhds
zLNkFdpqNVCJw2qxlgW44Y6g/E2RmvWDxQBG2g19gtzomGSZ0SpR7D8+9SS4wu+e
9jMapOsbGxha0HCLjAyNV9jmXqINLhBsY2KLuDGsuphvF2T4wYWIwescNe+XMuzf
KfUmmSjIScwLUXvIxDZneHaoGKow9jhToYh3fxKkTjn1IuI51iaEsExiGFyGJ4HD
P9UR7LT93dvGcg2JjsI1jcVOF6AJubCTnAV/oOKyhJA6zy5WrWDpne+vFlvzHw==
=/PQK
-----END PGP SIGNATURE-----
--oJ71EGRlYNjSvfq7--
|
