pull down to refresh
212 sats \ 1 reply \ @kevin_lightning 4h \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
-
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.
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