@sipa I also want to ask another question… what is so wrong about this type of censorship?
To be clear, an oracle emulating an op_code or an entire different type of locking predicate, is censorship, not enforced by the entire network, but by a specific predetermined group of signers.
Now, what is wrong with current PoW majority, enforcing some “censorship” over a very specific pattern that is impossible for anyone to be using without opting-in that behavior?
Put another way, why is this ok to be enforced by oracles[1]:
<INPUT> <PROGRAM> OP_2DROP <oracle_1_pk> OP_CHECKSIG
But this is not ok to be enforced by miners:
<INPUT> <hash(PROGRAM)> OP_NOP10 OP_2DROP OP_1
where <hash(PROGRAM)> OP_NOP10 is basically used as an ad-hoc (yet only opt-in) OP_CHECKPROGRAMVERIFY
Would that censorship be any cause of concern? And if not, who other than miners (persuaded by a minority of users interested in such use-case) are supposed to be involved in that “agreement”.
Now if that _is_ acceptable arrangement, if only risk for the users trusting miners (just as it is risky for users to trust oracles), does that mean the only problem with using OP_SUCCESS126 is the scarcity of OP_SUCCESSS codes?
Are miners then allowed to signal their intent to censor transactions (and blocks) that doesn’t respect a specific program’s hash? Or is that considered an attack on Bitcoin, because a broader “ecosystem agreement” hasn’t been reached? Of course other miners are affected, and will be required to react, but so would they in the case of an OP_SUCCESS soft fork. The rest of the ecosystem need not concern itself, no?
Thanks again for engaging with this.
[1] A more detailed example of how oracle-based emulation can be done that makes more sense than the script above GitHub - Nuhvi/sake: Script Army Knife Emulator