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
|
Return-Path: <judecn@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82F83D25
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Aug 2018 20:40:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f52.google.com (mail-it0-f52.google.com
[209.85.214.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EBBFC774
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Aug 2018 20:40:14 +0000 (UTC)
Received: by mail-it0-f52.google.com with SMTP id e14-v6so3466782itf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Aug 2018 13:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=iSSGHOK34G3YzZ7Gl67zVaUhdazEsfXVI05zZRLIk6M=;
b=CQEZusJviD6R5KLVLIuLMt7QxBT/SJP9t8DT6SuhLygCEkTBvAvMUzStY4pcE7pMLS
bTBWe4boa+EuzLerlzcZALZbVhTJZYnXwZsnHplvkewZ6CeF4NsgKKW16vn2Q/SQh4Qj
aZLskDqktdpFCIXjbpSKoScw+qTEOUMqxTH8rzocPfTYw4vg/gqUa6A9O1SawCkqIFth
K9WBPIU9YUGZT0VyA52kbKNGMN2tyZrEZJ+AVfA73OzmBM93BdSH7pYxcKGvRpd+Pcoc
08ToOPizm0h5+HDsOO/ylm0RBqX+RNJSBxQbfj2bCpAOjle7xE5B5By4j+Dc9pG5r4ZD
kzdA==
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:from:date
:message-id:subject:to;
bh=iSSGHOK34G3YzZ7Gl67zVaUhdazEsfXVI05zZRLIk6M=;
b=sS80BIs1nLNtCi3LocwP3d/U5md5JZjQWBWUJ3qISR0Ti6EvbXctWxBSVn/O1WjKDH
AbEewXBd2Dunf7/wrVBGHVj302XrilRwFiJRjWgMvOKRERqFtAjcKML4vd+arRj+3p90
e/G1wXPhGtoTrRmygDp9ikuRMUe2PFBJXr5HIjZwL2p+Rtrx/wnQ54MxuVI6DYk1OFLC
jlb7PdObwF3OYLAR1I3Q+CR4rxG7azyoQBhdQUoXIcHyfhZnjsawFAong8qFarYODEg7
rnNuMOoLNfRv7rFmHfwJM5I8t6J6KgzyanGB9XNhbWgIPB317Fdz9EHilsz3fOtFgBUv
Munw==
X-Gm-Message-State: AOUpUlEVYVz4qUHd7myHCfF9cKAe+eybk/2bjOOau21xlvupZzh516As
PuI2ljUov6U/ZHuMdBXeUawqbVwNadEkMTb4WzPSyGL+
X-Google-Smtp-Source: AA+uWPz/FMLokRlglj+GlbwPynXASKhp4MFHqX9zrXVCC+bWqdBss6oeABkFS/D1Gn398lt1ITFi1Hd7avjAjKkxjZk=
X-Received: by 2002:a24:3005:: with SMTP id
q5-v6mr19414257itq.23.1534365613953;
Wed, 15 Aug 2018 13:40:13 -0700 (PDT)
MIME-Version: 1.0
References: <CACrqygD_5jpkTvvcFo7eHxZfiH4evzZQc=YB=opBo6M_0EsZTQ@mail.gmail.com>
<CABm2gDpOvXg7_Yv9jkX=+a7ALXHgA5-4Oh4ZQnzp=pw5-0bZPA@mail.gmail.com>
In-Reply-To: <CABm2gDpOvXg7_Yv9jkX=+a7ALXHgA5-4Oh4ZQnzp=pw5-0bZPA@mail.gmail.com>
From: Jude Nelson <judecn@gmail.com>
Date: Wed, 15 Aug 2018 20:40:02 +0000
Message-ID: <CAFsQEP1ttFbAZZzz49Jg3E3jbZjztNRDVGJAKOWULYzrn+7obQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000060184f05737f558d"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 15 Aug 2018 21:23:57 +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: Wed, 15 Aug 2018 20:40:15 -0000
--00000000000060184f05737f558d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> I recommend against using an op_return prefix,
> as they allow for transaction censorship.
> In fact, in our case, where we use an IPFS hash in
> an op_return, we remove the IPFS multihash prefix
> information to post a =E2=80=9Cbare=E2=80=9D SHA256 hash to look like
> many other hashes being posted in op_returns, to
> minimize any ability for a miner to identify our transaction.
> The more projects that do this the better =E2=80=94 a form of herd
> immunity.
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.
On Wed, Aug 15, 2018 at 8:34 PM Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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".
> 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.
>
> On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>Should we actually be using the BIP process to claim a prefix?
> >
> > I recommend against using an op_return prefix, as they allow for
> transaction
> > censorship.
> >
> > In fact, in our case, where we use an IPFS hash in an op_return, we
> remove
> > the IPFS multihash prefix information to post a =E2=80=9Cbare=E2=80=9D =
SHA256 hash to
> look
> > like many other hashes being posted in op_returns, to minimize any
> ability
> > for a miner to identify our transaction. The more projects that do this
> the
> > better =E2=80=94 a form of herd immunity.
> >
> > Longer term I=E2=80=99m looking for more responsible ways to publish th=
is hash,
> for
> > instance have the hash be in the witness script data, so that it can be
> > easily purged from nodes that do not wish to preserve it and prevent
> block
> > size bloat. However, to do so everyone has to do it the same way, ideal=
ly
> > have it look like any other transaction. I=E2=80=99ve not quite seen a =
solid
> > proposal for best practices here.
> >
> > =E2=80=94 Christopher Allen
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000060184f05737f558d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> I recommend against using an op_return prefix,=
=C2=A0</div><div>> as they allow for transaction censorship.</div><div><=
br></div><div>> In fact, in our case, where we use an IPFS hash in=C2=A0=
</div><div>> an op_return, we remove the IPFS multihash prefix=C2=A0</di=
v><div>> information to post a =E2=80=9Cbare=E2=80=9D SHA256 hash to loo=
k like=C2=A0</div><div>> many other hashes being posted in op_returns, t=
o=C2=A0</div><div>> minimize any ability for a miner to identify our tra=
nsaction.=C2=A0</div><div>> The more projects that do this the better =
=E2=80=94 a form of herd=C2=A0</div><div>> immunity.<br><br>Can a miner =
identify which transactions came from your software simply by running a cop=
y themselves?=C2=A0 If so, then they can censor your transactions no matter=
how you encode them.</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr">On Wed, Aug 15, 2018 at 8:34 PM Jorge Tim=C3=B3n via bitcoin-dev <=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
op_return outputs can be pruned because they are not spendable.<br>
putting a hash on in the witness script data won't make things better<b=
r>
(it would actually make them worse) and it definitely doesn't help<br>
"block size bloat".<br>
I think I'm missing some context, but if you're using op_return pur=
ely<br>
for timestamping I would recommend using pay 2 contract=C2=A0 instead.<br>
<br>
On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev<br>
> <bitcoin-dev at <a href=3D"http://lists.linuxfoundation.org" rel=3D=
"noreferrer" target=3D"_blank">lists.linuxfoundation.org</a>> wrote:<br>
>>Should we actually be using the BIP process to claim a prefix?<br>
><br>
> I recommend against using an op_return prefix, as they allow for trans=
action<br>
> censorship.<br>
><br>
> In fact, in our case, where we use an IPFS hash in an op_return, we re=
move<br>
> the IPFS multihash prefix information to post a =E2=80=9Cbare=E2=80=9D=
SHA256 hash to look<br>
> like many other hashes being posted in op_returns, to minimize any abi=
lity<br>
> for a miner to identify our transaction. The more projects that do thi=
s the<br>
> better =E2=80=94 a form of herd immunity.<br>
><br>
> Longer term I=E2=80=99m looking for more responsible ways to publish t=
his hash, for<br>
> instance have the hash be in the witness script data, so that it can b=
e<br>
> easily purged from nodes that do not wish to preserve it and prevent b=
lock<br>
> size bloat. However, to do so everyone has to do it the same way, idea=
lly<br>
> have it look like any other transaction. I=E2=80=99ve not quite seen a=
solid<br>
> proposal for best practices here.<br>
><br>
> =E2=80=94 Christopher Allen<br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">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=
/mailman/listinfo/bitcoin-dev</a><br>
><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>
--00000000000060184f05737f558d--
|
