Jude Nelson [ARCHIVE] on Nostr: 📅 Original date posted:2018-08-15 📝 Original message:> I recommend against ...
📅 Original date posted:2018-08-15
📝 Original message:> 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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180815/e8fe75f4/attachment-0001.html>;
📝 Original message:> 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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180815/e8fe75f4/attachment-0001.html>;