* Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs
@ 2023-08-06 20:35 John Light
2023-08-08 1:34 ` ZmnSCPxj
2023-08-09 13:06 ` Murch
0 siblings, 2 replies; 4+ messages in thread
From: John Light @ 2023-08-06 20:35 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs
2023-08-06 20:35 [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs John Light
@ 2023-08-08 1:34 ` ZmnSCPxj
2023-08-09 13:06 ` Murch
1 sibling, 0 replies; 4+ messages in thread
From: ZmnSCPxj @ 2023-08-08 1:34 UTC (permalink / raw)
To: John Light; +Cc: bitcoin-dev
Good morning John Light,
> 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?
As I understand it, `OP_RETURN` outputs are already pruned, in the sense that they are never put in the UTXO database in the first place.
Indeed, as I understand it, "pruning" in this context is about removing (or not inserting at all, in the case of `OP_RETURN`) from the UTXO database.
UTXO database is best to keep small to reduce lookups of UTXOs being spent, as that impacts speed of validation.
Archival nodes still retain the raw `OP_RETURN` data as part of the raw block data, as it is necessary to prove that those transactions are (1) valid transactions and (2) part of (i.e. in the Merkle tree of) a valid block on the block header chain.
Block-pruning nodes also still retain this data, as they can at least serve recent blocks with the same requirement of proving that transactions containing `OP_RETURN` are valid transactions in a valid block on the block header chain.
If you want to prove that a block is valid, you need to present even `OP_RETURN` data, as you need to be able to show the actual transaction containing it, so that the verifier can see that the transaction is correctly formatted and its txid matches the supposed location in the Merkle tree.
Block relay requires that the node relaying a block prove that that block is indeed valid, thus you need to retain the `OP_RETURN` data.
Thus, in this context "pruning" refers to not keeping `OP_RETURN` TXOs in the UTXO database.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs
2023-08-06 20:35 [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs John Light
2023-08-08 1:34 ` ZmnSCPxj
@ 2023-08-09 13:06 ` Murch
1 sibling, 0 replies; 4+ messages in thread
From: Murch @ 2023-08-09 13:06 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/html, Size: 4857 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs
@ 2023-08-03 11:42 Peter Todd
0 siblings, 0 replies; 4+ messages in thread
From: Peter Todd @ 2023-08-03 11:42 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
https://github.com/bitcoin/bitcoin/pull/28130
Sjors Provoost suggested that I email this mailing list as notice of my intent
to get a pull-req merged that would remove the arbitrary 80-byte, 1 output /
tx, standardness restrictions on OP_Return outputs. His rationale was that
removing these standardness restrictions could potentially open up additional
transaction pinning(1) vectors. Since this is a potential problem with any
relaxation of standardness rules, I don't consider this to be an important
concern. But consider this email your notice.
At least some miners appear to be mining non-bitcoin-core-standard
transactions. So with respect to the hash power of those miners these pinning
vectors may in fact exist already.
# References
1) https://bitcoinops.org/en/topics/transaction-pinning/
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-09 13:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-06 20:35 [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs John Light
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox