MIME-Version: 1.0
In-Reply-To: <CACrqygD_5jpkTvvcFo7eHxZfiH4evzZQc=YB=opBo6M_0EsZTQ@mail.gmail.com>
References: <CACrqygD_5jpkTvvcFo7eHxZfiH4evzZQc=YB=opBo6M_0EsZTQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Wed, 15 Aug 2018 22:33:43 +0200
Message-ID: <CABm2gDpOvXg7_Yv9jkX=+a7ALXHgA5-4Oh4ZQnzp=pw5-0bZPA@mail.gmail.com>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
Precedence: list

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 transact=
ion
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we remov=
e
> the IPFS multihash prefix information to post a =E2=80=9Cbare=E2=80=9D SH=
A256 hash to look
> like many other hashes being posted in op_returns, to minimize any abilit=
y
> for a miner to identify our transaction. The more projects that do this t=
he
> better =E2=80=94 a form of herd immunity.
>
> Longer term I=E2=80=99m looking for more responsible ways to publish this=
 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 bloc=
k
> size bloat. However, to do so everyone has to do it the same way, ideally
> have it look like any other transaction. I=E2=80=99ve not quite seen a so=
lid
> 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
>