a script bip-110 bans (like a larger more complicated multisig)
All you need is just some P2PK, even with compressed public key. Single key, single signature, and coins will be splitted between BIP-110, and non-BIP-110. Initially I thought about something like 100 bytes in OP_RETURN, but this is cheaper, and takes more than 34 bytes (33-byte public key, one byte for stack push, and one byte for OP_CHECKSIG).
Strangely I've not found a single 110 proponent willing to trade at any price.
Yes, even though the code for doing that is publicly released, for example:
https://github.com/jlopp/BIP-110-FuturesBut even if someone doesn't want to touch Taproot, then still: there are a lot of things, blocked by BIP-110. I still wonder, what is the cheapest ways to split coins, and make it "a monetary transaction". So far, using P2PK seems to be the easiest way to do that.
it's fundamentally impossible to prevent embedding data
They won't believe, that trying to prevent data pushes can be harmful. They have to try, fork to their own minority chain, and be spammed, to be convinced.
Anyway, if we ignore the bad side of BIP-110, it can still have some good sides: by using it as a warnet, and checking, how the coin would work in an adversarial environment, where you want to transact, but developers are constantly trying to block you, we can at least see, how resistant to that Bitcoin really is. Because if nobody will want to buy BIP-110 coins, then how else they could be used? It would be funny, if they would be used for more testing, than testnet4 or signet is. For now, signet is missing "warnet-like" testing, so it can be just an opportunity to try it, if these coins will have no other use.
if the 'spam' cared about that they wouldn't use bitcoin at all as they could transact 1000 times cheaper with some other blockchain
Which is why I assume BIP-110 will be more spammy than BTC, if it would produce any blocks. Because if there would be for example 1% hashrate support, and one BIP-110 coin would be worth for example 0.01 BTC or less, then spamming on BTC with 1 sat/vB will have similar cost, as spamming on BIP-110 with 100 sat/vB or more.
It wouldn't be accepted for discussion unlike the BIP-110.
The discussion about the Pull Request was closed:
https://github.com/bitcoin/bitcoin/pull/34930Of course, BIP was merged, and assigned a number, but it doesn't mean, that it should be implemented, or is "good", or "accepted". We have many BIPs, which are harmful, but are published, just because the author completed all needed things, to see it published.
BIPs are just for standardizing things: if you want to send "ping", and receive "pong" as a response, then you can make "BIP-ping-pong", and it could be published. It doesn't mean, that all clients should implement it, or that it is endorsed by anyone else, than the author.
Those are lies and sophisms.
What is a lie? The fact, that BIP-110 content was
pushed on-chain? Or the fact, that it would block regular users, doing simple things, like sending coins to P2PK?
Can't wait to read that putting 5MB spam in a block is unstoppable.
Because it is. When you have *.blk files, then they usually contain more than one block. If you will push 4 MB into one block, and 1 MB into another block, then you can make it "contiguous".
Another thing is that these files are XORed, but it won't change it that much. If someone would have enough determination, to push a specific content, then by knowing the xored value, it could be formatted properly, to make it visible in plaintext. Who knows, maybe someone with enough free time will demonstrate it in regtest?
They will filter spam transactions out.
How exactly do you want to filter private keys, without confiscating coins from real users?
That's not a serious comment.
Why not? Who will decide, that the whole spam is now filtered properly? Any transaction can be always spammy. Only empty blocks would meet a definition of "there is no on-chain spam anymore".
There aren't any coins confiscated by BIP-110.
Good to know, that sending coins to P2PK is not considered as "payment" by BIP-110.
It is illogical to reject BIP-110 because of fear of imaginative changes that it doesn't introduce.
It is logical, that if you block someone else's transaction today, then that person may want to block your transaction in the future. Today's miners have no guarantee, that they would be in the same position in the future, after some years. If they will agree to block some transactions today, then later, when they will lose their domination, another mining pool in the future can decide, to do the same with their coins, because the code for that will be already activated, and there will be a precedent for that. Which means, that future users will have all tools they need, to do that in practice in future BIPs.
There would not be confiscation of either that or any other coin.
If some coin is timelocked, then it doesn't help, that you allow to move it once.
+--------------------------------+
| Alice 1.01 BTC -> Bob 1.00 BTC |
+--------------------------------+
| timelock: 2026-10-11 |
+--------------------------------+
If that's all Bob has, then it doesn't help, that this payment will be processed. If Bob's output is blocked by BIP-110, then he will lose his coins on BIP-110 chain.