pull down to refresh
362 sats \ 9 replies \ @DarthCoin 5 May \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
- What was the main reason /concern to add this PR?
- If the concern was that the blockchain size is too big for IBD, can we let things "AS IS" but somehow "archive" the past blocks, let's say pre-2017-fork era? And those who still want to use UTXOs from that era, could just do a simple migration or something ?
- What will happen if we do nothing?
-
The main reason for the PR (in my opinion) is that it achieves harm reduction. Similar to how local governments might provide a drug addict clean needles, giving data embedders the option to utilize OP_RETURN is better than having them stuff witnesses. This is because (1) OP_RETURN is provably unspendable and does not bloat the UTXO set and (2) does not leave dust outputs behind like witness stuffing (i.e. inscriptions). Secondly, removing the limit reduces the need for nodes to need to pull transactions at block-sync time because the next block will be made up of transactions already in your local mempool. Finally, because mining pools don't care about standardness, relay should not either. I think it was gmax that said what is relayed should closely match what is mined.
-
IBD solutions already exist today. I forgot the name of one of them but it essentially has UTXO set hints that allow you to parallelize the process of sync. This is the main reason why IBD is slow today, and if you setup a node from scratch you'll see that CPU/networking are not utilized to their full potential. Libbitcoin is another example of how parallelizing can make it such that your network speed is the bottleneck for sync.
-
If we do nothing then block updates are slightly worse for everyone as mentioned before. Additionally, if your code relies on mempool estimates for fees it will have a less accurate prediction of what to use for a fee rate. It would be similar to someone running the ordisrespector patch. Even if the transactions they don't like are not in their own mempool, they will need to store it anyway when a block is mined that contains them. Finally, if we do nothing there is a very real likelihood that a third party may resort to VERY BAD data storage methods like Bitcoin Stamps which utilize fake pubkeys and stuff data in them. These are much worse because they permanently bloat the UTXO set with each transaction created.
reply
Good answer, a couple remarks:
-
Embedding data in witnesses does not inherently pollute the UTXO set, but it is often (mis-)used in a way that does. Even worse is data embedded in fake pubkeys or fake pubkey hashes as that data needs to be stored in the UTXO set.
-
You are thinking of SwiftSync.
reply
Is not also what Lopp explain in this article with UTXO snapshot?
https://blog.lopp.net/bitcoin-node-sync-with-utxo-snapshots/
Follow up question:
Would phasing out OP_Return limits stop a third party from resorting to VERY BAD data storage methods?
In other words, if there is nothing stopping them from using, for example, fake pubkeys now, what would stop them from using them if we relaxed some OP_Return filters?
reply
We can’t stop anyone from using fake pubkeys, but using OP_RETURN would be cheaper and less malicious, so if they want to be perceived as good actors they would switch. If they continue to use fake pubkeys, even while having other options, they reveal themselves as obviously malicious.
reply
That means if they are malicious we can't do anything at the protocol level, regardless of whether OP_return is there or not, correct?
This is something that is confusing to me, because if that is the case, then no matter what happens with this debate, Bitcoin is just a sitting duck waiting to be defenestrated by someone with the right backing and know-how.
And if there is something we can do against a bad actor, then why not do it now, instead of rolling the red carpet and hoping they will behave themselves?
By the way, the long form replies are very helpful. Thank you for taking the time.
reply
That means if they are malicious we can't do anything at the protocol level, regardless of whether OP_return is there or not, correct?
The only effective recourse would be a protocol change that amends all output types such that they incorporate a proof that the output scripts are spendable when they are created. Even then, data could be embedded via other transaction fields or grinding pubkeys and signatures.
This is something that is confusing to me, because if that is the case, then no matter what happens with this debate, Bitcoin is just a sitting duck waiting to be defenestrated by someone with the right backing and know-how.
Pretty much. That’s why many people were upset about Stamps specifically. Stamps were unabashedly malicious by needlessly polluting the UTXO set. (They were even explicitly marketed as "unprunable".)
And if there is something we can do against a bad actor, then why not do it now, instead of rolling the red carpet and hoping they will behave themselves?
As explained, there isn’t much that can be done, except social pressure or hard forks with really horrible trade-offs. OP_RETURN is a mitigation in the sense that it would have 5–10 bytes less overhead for a small data payload and more for large data payload than fake pubkeys. So, it’s not only a request to be a good citizen, but also provides a (small) financial incentive to be a good citizen by being cheaper.
By the way, the long form replies are very helpful. Thank you for taking the time.
You’re welcome. I’m glad that people are reading this and find it useful.
reply
If you were insane and mandated that txns came with signatures you could prove they were spendable but yeah.
Within the realm of reasonable solutions there's not much you can do. That's the nature of a digital ledger that ultimately is a distributed database.
People are going to store arbitrary content. Trying to stop it is futile. What we can do though is provide aligned incentives.