pull down to refresh
0 sats \ 3 replies \ @unschooled 5h \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
Thank you for your response.
Sorry, maybe you misunderstood my question, as my assumption has been that the proposed pr will do the opposite.
To perhaps rephrase (respond if you wish): if demand for arbitrary data-anchoring in Bitcoin increases in the near- to long-term, and it seems it might, is this pr a preemptive attempt at defending would-be node runners by making this data prunable?
And if that's the case what would the implications be if average plebs started being unable to run full nodes?
Sorry, I mixed in a bit of what I have been seeing in other discussions here. There seem to be many people claiming that relaxing the OP_RETURN limits would make it more expensive to run nodes. I am trying to push back on that argument, as I don’t consider it tenable.
AFAIA, some people at Ocean feel that the blocksize generally should be reduced to 300 kB because it is already too expensive to IBD.
To perhaps rephrase (respond if you wish): if demand for arbitrary data-anchoring in Bitcoin increases in the near- to long-term, and it seems it might, is this pr a preemptive attempt at defending would-be node runners by making this data prunable?
Yeah, I think that would be a fair characterization of an argument in this debate. There are a bunch of 2nd-layer protocols, sidechains, and rollups, etc. in development that aim to use the Bitcoin blockchain for anchoring, proofs, or data storage in some other way. Dropping the OP_RETURN limit would ensure that they can at least use OP_RETURNs if they must write data to the blockchain instead of writing in more harmful ways like fake pubkeys or fake pubkey hashes. OP_RETURNs would need to be part of a complete copy of the blockchain, but would not live in the UTXO set which needs to be kept highly available. Fake pubkeys/pubkey hashes live in both the UTXO set and the blockchain.
And if that's the case what would the implications be if average plebs started being unable to run full nodes?
A pruned node keeps the last two days of blockchain and the entire UTXO set. A node with a complete copy of the blockchain would retain the data in the blockchain and will also keep the UTXO set of course. The UTXO set is also stored on disk and usually only recent outputs are in the cache in the memory. A bloated UTXO set especially affects IBD and generally slows down loading UTXOs from disk.
reply
Ok so as I'm understanding you: given increasing interest in data anchoring on Bitcoin, with this merge, block size still doesn't exceed 4mb, meaning there's no new burden in storage requirement on noderunners. The nature of using op_return instead of other arbitrary data means this merge will mitigate the problem of lengthy network synchronization as well as improved mempool uniformity and therefore faster block relaying (which benefits miners) 🫡
I very much appreciate all the back-and-forths you've afforded me here on SN as I try to wrap my mind around all this. Not to mention all your other contributions to Bitcoin.