> That is why it is better -- I can activate my own thing, without bothering you all.
After reading BIP-300 in its current form, I think it is too complex. Instead, much simpler constructions are already available, without any soft-forks. What is more: they were possible since 2009, and they can be implemented by raw Script, if needed, which makes them portable between many altcoins, which copy-pasted Bitcoin's source code, and also between different address types (excluding TapScript, because OP_SIZE will work only with DER signatures).
Example testnet transaction:
https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5Example address:
https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9dExample Script: OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG
Here, each coin sender can decide, which difficulty should be picked for a given transaction output. When the size is required to be less than 60, then that coin can be moved after grinding around 256 hashes (one byte). Then, by lowering that value, it can be made 256 times harder, each time this value is decremented (down to 10, because 9-byte signature is the smallest valid one).
So, to sum up, the ability to lock output Scripts with Proof of Work is possible here and now, without any consensus changes. The only need for further changes is related to Merged Mining, because the way of transaction hashing is obviously different, than the way of hashing existing block headers. However, that model given above should be sufficient, to deploy some real, decentralized sidechains, on top of some existing chains, and see, how they would be used in practice.