📅 Original date posted:2018-08-15
📝 Original message: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
>
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 18:14:00
in reply to nevent1q…aujt
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 18:14:00Event JSON
{
"id": "49a09a79b593925c5e12cbaadc6a1b5fad45d3a0f73c8e1349c576b18cb42d35",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686161640,
"kind": 1,
"tags": [
[
"e",
"eccbd39bd966baef56b5939c955d566f9fe6d2296c2c463ce1c7b09a9df0388b",
"",
"root"
],
[
"e",
"e7ad039cf347fedaed989d1c2f96f5804fd3e721ea19f38e6cb2cc28c096b84f",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "📅 Original date posted:2018-08-15\n📝 Original message:op_return outputs can be pruned because they are not spendable.\nputting a hash on in the witness script data won't make things better\n(it would actually make them worse) and it definitely doesn't help\n\"block size bloat\".\nI think I'm missing some context, but if you're using op_return purely\nfor timestamping I would recommend using pay 2 contract instead.\n\nOn Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003eShould we actually be using the BIP process to claim a prefix?\n\u003e\n\u003e I recommend against using an op_return prefix, as they allow for transaction\n\u003e censorship.\n\u003e\n\u003e In fact, in our case, where we use an IPFS hash in an op_return, we remove\n\u003e the IPFS multihash prefix information to post a “bare” SHA256 hash to look\n\u003e like many other hashes being posted in op_returns, to minimize any ability\n\u003e for a miner to identify our transaction. The more projects that do this the\n\u003e better — a form of herd immunity.\n\u003e\n\u003e Longer term I’m looking for more responsible ways to publish this hash, for\n\u003e instance have the hash be in the witness script data, so that it can be\n\u003e easily purged from nodes that do not wish to preserve it and prevent block\n\u003e size bloat. However, to do so everyone has to do it the same way, ideally\n\u003e have it look like any other transaction. I’ve not quite seen a solid\n\u003e proposal for best practices here.\n\u003e\n\u003e — Christopher Allen\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "e0bfddfd0c8dde278e08c9a3bcbfd1d23a3ad2e489599c9e7a395e8790dad31031546f4205973d850c80ef4e303792971b15afbad3903a07fb70ce766aefbcd0"
}