John Light [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-06 🗒️ Summary of this message: John Light has ...
📅 Original date posted:2023-08-06
🗒️ Summary of this message: John Light has sent an email to Peter regarding his proposal on removing OP_RETURN output count and data size limits, asking questions about the impact on full node operators.
📝 Original message:
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
🗒️ Summary of this message: John Light has sent an email to Peter regarding his proposal on removing OP_RETURN output count and data size limits, asking questions about the impact on full node operators.
📝 Original message:
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