> 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
