And in fact, a URSF is the only way to stop a UASF that has gained some traction.
Ignoring a minority soft-fork is easier, and less risky in case, when URSF would lose. And it ends up on the same chain, as all old clients.
That's a no-brainer.
If defining a spam is so easy, then why BIP-110 didn't do that? Is P2PK a spam or not? BIP-110 proponents won't tell you, because they don't know, and they never tried to test things properly, to even notice, that it is blocked by this BIP.
Nobody says that P2PK outputs are not a payment.
Then, why BIP-110 blocks P2PK payments? It was declared to contain no bugs, and affect no users.
The truth is that nobody sends anything to P2PK outputs anymore.
Which means it would only hurt old users with old wallets, who may want to sweep their coins. So, why block it?
Only malware assholes still use P2PK outputs.
Bold words to call a Satoshi, and other early adopters like that.
BIP110 does not block you from using P2PK inputs, only outputs.
If you have an old transaction from 2009, that is timelocked, then you cannot change its outputs.
Which means you can spend you coin from it, but you just can't send your coin to a P2PK output.
If your coins will be in your outputs, then you are affected.
We will never do that.
If BIP-110, and next BIPs after that will never define the safe area of things, that wouldn't be blocked, then why users would trust that code? Why users could be sure, that their today's scripts won't be blocked in the future? The only thing you need is to call something "outdated", make a BIP, and convince people, that it is a spam, even if your coins could be moved with a single signature, below 120 bytes.
why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it.
See? Satoshi supported data pushes up to 120 bytes, specifically to allow pushing additional data on-chain, which would be just ignored. And he even supported "a third transaction type for timestamp hash sized arbitrary data", which is what is known today as OP_RETURN. And then, if you allow OP_RETURNs up to 83 bytes, then why you block all standard P2PKs, which are always smaller than that?
New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
Having two different limits here is just inconsistent. But you keep pretending, that BIP-110 has no bugs, and affects no users.