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
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
Return-Path: <lautarodragan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B67FF25A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Aug 2018 02:22:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F02441A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Aug 2018 02:22:34 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id l2-v6so14353967wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Aug 2018 19:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:reply-to:from:date:message-id
:subject:to:cc;
bh=REvIgGrXTXMzVh/nd0otRAPoe5FdW4u2harYESsM300=;
b=h2d6FCRfh3YgQ8f2vHy7KYbMvXKSq5/8Z84oeX5m1DzQou8NGMi3udIRrmz+l1ZyWJ
MmMmCzLsI1yGPQz2lEVQQDNgJElKw2tLog9QQY6ZlX0uA+ZwQ6q50QS/IFrpVjjABpJA
MgqoRrEsUXT2qdYY3xKM+sPVrYbpumX3UnR9y9GEmZtwTJ+fH4iJZamNaw8FMdUSHn2t
VFc6YTzCjpUySRBY3gWjl9DTEgrPe5QWWjZJ1suMzzyyQduEq/PvvyWh1Sm4Lu/4XsOr
Nqo1Co50Kk9Ll8AjVb8yVx3eFaRB1d2pMC3aOvBJtiDPgBW5c+vGQ8h1glCP0oAvsXaI
MwsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
:from:date:message-id:subject:to:cc;
bh=REvIgGrXTXMzVh/nd0otRAPoe5FdW4u2harYESsM300=;
b=hRxrrBCg+ko5lb9BLvBtqCZFTgFdc3kFkziQRL0LQ3hRglAt4hzyVWW3C9Q2fwcCGD
9/C3MXKKlrAei9VLNKDEBqv7PPvZls8KO+Gj2ezDy4As+/N0gKhXCMPCNB7/dyO9I5mf
T/P4OPbKJ/1a7ysZSLmvvvVzUILATIQ3UTP5pmE2He5oqyNdexOLM47szsCK8y3HDzDo
6hS2zpIggEgsc1OgtUQlflLJtsd2Sso1cgAl9+XFpxzo1fRhCEzJNWRINxc5901yELFs
idO62W1bBmCa1uVlkM1FSWyWNGpHILz61XOZPvsE+0TV1AQcBKcEN4+ZlrHhC/0td/dh
9nYw==
X-Gm-Message-State: AOUpUlFHPBtt91sg5icjp5MLEg8gH6cwoG8q2HXwpw85mLNQajedeb2a
dM2Lus7zk4EnA9/xNOXV9y+sqgXb8s7urSlidEoV1g==
X-Google-Smtp-Source: AA+uWPzEyzWHgwt6IlYNS+peSiR3A02qiSoEIzzGIlBo4q3/MDbkrV4NvgPfGjWiGDNeX4TVBoLtNcZxd44az2fToPI=
X-Received: by 2002:a1c:1805:: with SMTP id 5-v6mr14075001wmy.25.1534386153376;
Wed, 15 Aug 2018 19:22:33 -0700 (PDT)
MIME-Version: 1.0
References: <CACrqygD_5jpkTvvcFo7eHxZfiH4evzZQc=YB=opBo6M_0EsZTQ@mail.gmail.com>
<CAFsQEP1ttFbAZZzz49Jg3E3jbZjztNRDVGJAKOWULYzrn+7obQ@mail.gmail.com>
<CACrqygBJ=RdPpHqHzPNqqj0V2w5XL6GVtKobOWnj1EsVykUS8w@mail.gmail.com>
<201808160106.54960.luke@dashjr.org>
In-Reply-To: <201808160106.54960.luke@dashjr.org>
Reply-To: lautaro.dragan@gmail.com
From: Lautaro Dragan <lautarodragan@gmail.com>
Date: Wed, 15 Aug 2018 23:22:21 -0300
Message-ID: <CAK6DEso4-R78qLtQLfGxNUML5B1Y8gxXXVzrzmSwkPabMfkW+w@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009ed1560573841d75"
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLYTO,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 16 Aug 2018 11:50:08 +0000
Subject: Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 02:22:35 -0000
--0000000000009ed1560573841d75
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks Christopher.
> op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
Agreed
> I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract instead.
And
> If you're *actually* just doing timestamping you're better off using
OpenTimestamps. But many times people think they're just doing timestamping
in reality mere timestamps are insufficient for the task.
No, it's not only timestamping. Think of it as storing the URL of something
in the OP_RETURN, only that instead of a URL it's a hash. But it's not just
the hash of the work =E2=80=94 IPFS adds a few other elements that affect t=
his
hash, so calculating it out of the file being added won't do. Also, the
batching OTS uses and the batching we use (using IPFS directories) are
incompatible.
> Can a miner identify which transactions came from your software simply by
running a copy themselves? If so, then they can censor your transactions
no matter how you encode them.
Miners would have to try and `ipfs cat` every OP_RETURN of every
transaction (maybe filtering by byte length), which is a relatively high
cost operation. But such a script is straight forward to write and can be
hosted in a cheap AWS machine. We're talking about less than a week of
coding and less than a hundred bucks of hosting, so if they're out to get
you it won't make a difference.
> Choosing not to mine transactions is not censorship.
Is it not, if for political rather than economical reasons? These
transactions pay fees like any other.
El mi=C3=A9., 15 de ago. de 2018 a la(s) 22:08, Luke Dashjr via bitcoin-dev=
<
bitcoin-dev@lists.linuxfoundation.org> escribi=C3=B3:
> On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev
> wrote:
> > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > Can a miner identify which transactions came from your software simpl=
y
> by
> > > running a copy themselves? If so, then they can censor your
> transactions
> > > no matter how you encode them.
> >
> > Possibly, but in the IPFS case I suspect the latency required to inspec=
t
> > all hashes would likely impact the ability of the miner to succeed in
> the
> > block. (True? I don=E2=80=99t touch mining software.)
>
> Not true at all.
>
> > Thus as long as all hashes look the same, and there are multiple conten=
t
> > addressable schemes that use hashes that have to be searched in order t=
o
> > know to censor, you have to censor all or none.
>
> Choosing not to mine transactions is not censorship.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000009ed1560573841d75
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks Christopher.=C2=A0<div><br></div><div>>=C2=A0<sp=
an style=3D"color:rgb(33,33,33)">op_return outputs can be pruned because th=
ey are not spendable.</span></div><span style=3D"color:rgb(33,33,33)">putti=
ng a hash on in the witness script data won't make things better</span>=
<br style=3D"color:rgb(33,33,33)"><span style=3D"color:rgb(33,33,33)">(it w=
ould actually make them worse) and it definitely doesn't help</span><br=
style=3D"color:rgb(33,33,33)"><span style=3D"color:rgb(33,33,33)">"bl=
ock size bloat".</span><br style=3D"color:rgb(33,33,33)"><div><span st=
yle=3D"color:rgb(33,33,33)"><br></span></div><div><span style=3D"color:rgb(=
33,33,33)">Agreed</span></div><div><span style=3D"color:rgb(33,33,33)"><br>=
</span></div><div><span style=3D"color:rgb(33,33,33)">>=C2=A0</span><spa=
n style=3D"color:rgb(33,33,33)">I think I'm missing some context, but i=
f you're using op_return purely</span></div><div class=3D"inbox-inbox-u=
yb8Gf" style=3D"color:rgb(33,33,33)"><div><div class=3D"inbox-inbox-F3hlO">=
for timestamping I would recommend using pay 2 contract=C2=A0 instead.</div=
></div></div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)=
"><br class=3D"inbox-inbox-Apple-interchange-newline"></div><div class=3D"i=
nbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">And</div><div class=3D"inb=
ox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div class=3D"inbo=
x-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">> If you're *actually*=
just doing timestamping you're better off using OpenTimestamps. But ma=
ny times people think they're just doing timestamping in reality mere t=
imestamps are insufficient for the task.</div><div class=3D"inbox-inbox-uyb=
8Gf" style=3D"color:rgb(33,33,33)"><br></div><div class=3D"inbox-inbox-uyb8=
Gf" style=3D"color:rgb(33,33,33)">No, it's not only timestamping. Think=
of it as storing the URL of something in the OP_RETURN, only that instead =
of a URL it's a hash. But it's not just the hash of the work =E2=80=
=94 IPFS adds a few other elements that affect this hash, so calculating it=
out of the file being added won't do. Also, the batching OTS uses and =
the batching we use (using IPFS directories) are incompatible.</div><div cl=
ass=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div cla=
ss=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">> Can a miner id=
entify which transactions came from your software simply by running a copy =
themselves?=C2=A0 If so, then they can censor your transactions no matter h=
ow you encode them.</div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:r=
gb(33,33,33)"><br class=3D"inbox-inbox-Apple-interchange-newline"></div><di=
v class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">Miners would h=
ave to try and `ipfs cat` every OP_RETURN of every transaction (maybe filte=
ring by byte length), which is a relatively high cost operation. But such a=
script is straight forward to write and can be hosted in a cheap AWS machi=
ne. We're talking about less than a week of coding and less than a hund=
red bucks of hosting, so if they're out to get you it won't make a =
difference.</div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33=
,33)"><br></div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,=
33)">> Choosing not to mine transactions is not censorship.</div><div cl=
ass=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br class=3D"inbox=
-inbox-Apple-interchange-newline"></div><div class=3D"inbox-inbox-uyb8Gf" s=
tyle=3D"color:rgb(33,33,33)">Is it not, if for political rather than econom=
ical reasons? These transactions pay fees like any other.</div><div class=
=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div><span =
style=3D"color:rgb(33,33,33)"><br></span></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">El mi=C3=A9., 15 de ago. de 2018 a la(s) 22:08, L=
uke Dashjr via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>> escribi=C3=B3:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Wednesday 15 August 2018 21:54:50=
Christopher Allen via bitcoin-dev wrote:<br>
> On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> > Can a miner identify which transactions came from your software s=
imply by<br>
> > running a copy themselves?=C2=A0 If so, then they can censor your=
transactions<br>
> > no matter how you encode them.<br>
><br>
> Possibly, but in the IPFS case I suspect the latency required to inspe=
ct<br>
> all hashes would likely=C2=A0 impact the ability of the miner to succe=
ed in the<br>
> block. (True? I don=E2=80=99t touch mining software.)<br>
<br>
Not true at all.<br>
<br>
> Thus as long as all hashes look the same, and there are multiple conte=
nt<br>
> addressable schemes that use hashes that have to be searched in order =
to<br>
> know to censor, you have to censor all or none.<br>
<br>
Choosing not to mine transactions is not censorship.<br>
<br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000009ed1560573841d75--
|
