thinking about the history here lol
after much debate, Bitcoin decided to keep blocks small and start scaling using its limited scripting instead.
this way made it much easier to also use those scripts to store arbitrary data.
putting that data in op_return keeps it out of the UTXO set. core maintains the network is agnostic about what is being stored.
and there's a financial incentive, that data storage has a dollar value.
and otoh
should we do whatever we can to whackamole all Objectional Content and even go so far to create a process where we can rollback any that gets onto the chain?
These are stupid options 😂
Replies (4)
I don't think they're the only options. Am I right in thinking that the objectionable content put in op_return is prunable? Eventually most nodes will have to be pruned anyways. Maybe the other option is making lightning nodes work with pruned nodes and just being more okay with pruning.
Pruning isn't by field type. Pruning means keeping the UTXO set and a certain count of blocks or space dedicated to storing blocks. Even pruned you are storing that chain content until it ages out of your block storage.
In order to validate you need to be able to hash the entire block. Change any field and the hash changes. The hash from last block is included in the next block so you can't tell if it is valid unless you have the entire block before that which you can't tell if it is valid unless you have the entire block before that, and so on forever back to the Genesis block.
Pruning works by validating the entire chain then discarding and trusting your own prior work.
If i was a banking elite i would sabotage any atempt that bitcoin has at scaling in a private sovereign way. Be that larger blocks or drivetrains using opreturn. Then i would make sure all the ppl use custodians, make bitcoin digital gold and ensure a place for myself as the banker of tm.
checks out afaict 👍
