Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82F83D25 for ; 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 ; Wed, 15 Aug 2018 20:40:14 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id e14-v6so3466782itf.1 for ; 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: In-Reply-To: From: Jude Nelson Date: Wed, 15 Aug 2018 20:40:02 +0000 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > wrote: > > On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev > > 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
> I recommend against using an op_return prefix,= =C2=A0
> as they allow for transaction censorship.
<= br>
> In fact, in our case, where we use an IPFS hash in=C2=A0=
> an op_return, we remove the IPFS multihash prefix=C2=A0
> information to post a =E2=80=9Cbare=E2=80=9D SHA256 hash to loo= k like=C2=A0
> many other hashes being posted in op_returns, t= o=C2=A0
> minimize any ability for a miner to identify our tra= nsaction.=C2=A0
> The more projects that do this the better = =E2=80=94 a form of herd=C2=A0
> immunity.

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.

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 pur= ely
for timestamping I would recommend using pay 2 contract=C2=A0 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 trans= action
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we re= move
> 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 abi= lity
> for a miner to identify our transaction. The more projects that do thi= s the
> better =E2=80=94 a form of herd immunity.
>
> Longer term I=E2=80=99m looking for more responsible ways to publish t= his hash, for
> instance have the hash be in the witness script data, so that it can b= e
> easily purged from nodes that do not wish to preserve it and prevent b= lock
> size bloat. However, to do so everyone has to do it the same way, idea= lly
> 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/mail= man/listinfo/bitcoin-dev
--00000000000060184f05737f558d--