public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: "John Light" <bitcoin-dev@lightco•in>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs
Date: Sun, 06 Aug 2023 16:35:38 -0400	[thread overview]
Message-ID: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> (raw)

Hi Peter,

Re: https://github.com/bitcoin/bitcoin/pull/28130

I have a few questions about your proposal and its impact on full node operators:

1. With your proposed policy change removing the OP_RETURN output count and data size limits, is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space e.g. the envelope technique inscriptions use? Robin Linus suggested on your PR there may be a case that "effectively results in a discount for small inscriptions".[1] It would be good to have confirmation on this and specific details about the range of inscription sizes that would receive the discount if this is true. (Robin himself is of course also welcome to answer this question; I have cc'd him directly on this email as an invitation to respond.)

2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes? While researching this question I found PR #2791 from Pieter Wuille, which implemented pruning of provably-unspendable outputs, which I assume includes OP_RETURN outputs.[3] After looking around some more and not finding definitive answers, I have a few new questions about this:
  i) Is the unspendable output pruning implemented in PR #2791 on by default or is this a flag that needs to be enabled by full node operators? If it's a flag, what is the flag called and how can it be enabled? If it's on by default, how can it be disabled?
  ii) If a full node operator does prune OP_RETURN outputs, does that in any way impair their ability to help a new node do IBD to validate the blockchain? And would that answer be any different if we were talking about pruning Taproot witness space (i.e. "envelopes" or "inscriptions") instead of OP_RETURN outputs?


Regards,

John Light

[1] https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1664950834

[2] https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain

[3] https://github.com/bitcoin/bitcoin/pull/2791

next             reply	other threads:[~2023-08-06 20:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-06 20:35 John Light [this message]
2023-08-08  1:34 ` ZmnSCPxj
2023-08-09 13:06 ` Murch
  -- strict thread matches above, loose matches on Subject: below --
2023-08-03 11:42 Peter Todd

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=00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com \
    --to=bitcoin-dev@lightco$(echo .)in \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox