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 --]
next prev parent 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