📅 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>;
Jude Nelson [ARCHIVE] /
npub16q…lzuez
2023-06-07 18:14:00
in reply to nevent1q…ym8m
Author Public Key
npub16qvv8accnt96cq8lfx9lucxkcahkzak8zxh8wzqrhmczzn80hh6q6lzuezSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:14:00Event JSON
{
"id": "77ba3c069e83d5c549071b4e213933506d84c89a710e2befe62508310d56b439",
"pubkey": "d018c3f7189acbac00ff498bfe60d6c76f6176c711ae770803bef0214cefbdf4",
"created_at": 1686161640,
"kind": 1,
"tags": [
[
"e",
"eccbd39bd966baef56b5939c955d566f9fe6d2296c2c463ce1c7b09a9df0388b",
"",
"root"
],
[
"e",
"49a09a79b593925c5e12cbaadc6a1b5fad45d3a0f73c8e1349c576b18cb42d35",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2018-08-15\n📝 Original message:\u003e I recommend against using an op_return prefix,\n\u003e as they allow for transaction censorship.\n\n\u003e In fact, in our case, where we use an IPFS hash in\n\u003e an op_return, we remove the IPFS multihash prefix\n\u003e information to post a “bare” SHA256 hash to look like\n\u003e many other hashes being posted in op_returns, to\n\u003e minimize any ability for a miner to identify our transaction.\n\u003e The more projects that do this the better — a form of herd\n\u003e immunity.\n\nCan a miner identify which transactions came from your software simply by\nrunning a copy themselves? If so, then they can censor your transactions\nno matter how you encode them.\n\nOn Wed, Aug 15, 2018 at 8:34 PM Jorge Timón via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e op_return outputs can be pruned because they are not spendable.\n\u003e putting a hash on in the witness script data won't make things better\n\u003e (it would actually make them worse) and it definitely doesn't help\n\u003e \"block size bloat\".\n\u003e I think I'm missing some context, but if you're using op_return purely\n\u003e for timestamping I would recommend using pay 2 contract instead.\n\u003e\n\u003e On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003eShould we actually be using the BIP process to claim a prefix?\n\u003e \u003e\n\u003e \u003e I recommend against using an op_return prefix, as they allow for\n\u003e transaction\n\u003e \u003e censorship.\n\u003e \u003e\n\u003e \u003e In fact, in our case, where we use an IPFS hash in an op_return, we\n\u003e remove\n\u003e \u003e the IPFS multihash prefix information to post a “bare” SHA256 hash to\n\u003e look\n\u003e \u003e like many other hashes being posted in op_returns, to minimize any\n\u003e ability\n\u003e \u003e for a miner to identify our transaction. The more projects that do this\n\u003e the\n\u003e \u003e better — a form of herd immunity.\n\u003e \u003e\n\u003e \u003e Longer term I’m looking for more responsible ways to publish this hash,\n\u003e for\n\u003e \u003e instance have the hash be in the witness script data, so that it can be\n\u003e \u003e easily purged from nodes that do not wish to preserve it and prevent\n\u003e block\n\u003e \u003e size bloat. However, to do so everyone has to do it the same way, ideally\n\u003e \u003e have it look like any other transaction. I’ve not quite seen a solid\n\u003e \u003e proposal for best practices here.\n\u003e \u003e\n\u003e \u003e — Christopher Allen\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180815/e8fe75f4/attachment-0001.html\u003e",
"sig": "ccdbd775b0bad938b9151dbec94fe06dde7093af5f18116af4f92f1eee3b70a65512dcd93db8e56a7ebd899febdd7b55e252adec6f17d55ecf4f33037898e6cd"
}