public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jude Nelson <judecn@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
Date: Wed, 15 Aug 2018 20:40:02 +0000	[thread overview]
Message-ID: <CAFsQEP1ttFbAZZzz49Jg3E3jbZjztNRDVGJAKOWULYzrn+7obQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpOvXg7_Yv9jkX=+a7ALXHgA5-4Oh4ZQnzp=pw5-0bZPA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

> 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 “bare” 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 — 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ón 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 “bare” 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 — a form of herd immunity.
> >
> > Longer term I’m 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
> block
> > size bloat. However, to do so everyone has to do it the same way, ideally
> > have it look like any other transaction. I’ve not quite seen a solid
> > proposal for best practices here.
> >
> > — 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
>

[-- Attachment #2: Type: text/html, Size: 3908 bytes --]

  reply	other threads:[~2018-08-15 20:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 18:34 [bitcoin-dev] Claiming an OP_RETURN Prefix Christopher Allen
2018-08-15 20:33 ` Jorge Timón
2018-08-15 20:40   ` Jude Nelson [this message]
2018-08-15 21:54     ` Christopher Allen
2018-08-16  1:06       ` Luke Dashjr
2018-08-16  2:22         ` Lautaro Dragan
2018-08-16  2:37           ` Luke Dashjr
2018-08-16 17:32     ` Ryan Grant
2018-08-15 21:46   ` Peter Todd
  -- strict thread matches above, loose matches on Subject: below --
2018-08-05 21:11 Lautaro Dragan
2018-08-05 23:57 ` Peter Todd
2018-08-06  0:55   ` Lautaro Dragan
2018-08-06  1:54     ` CryptAxe
2018-08-06  2:04 ` Luke Dashjr
2018-08-06  2:19   ` Lautaro Dragan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFsQEP1ttFbAZZzz49Jg3E3jbZjztNRDVGJAKOWULYzrn+7obQ@mail.gmail.com \
    --to=judecn@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox