Expanding my BIP concept. Thoughts?

I've been thinking a lot about my BIP concept to tackle spam, and it’s grown quite a bit. Would love to hear your opinions. First off, it's key to know that nearly all parts of my suggestions (except one) would initially be introduced as filters. These filters will help users and wallets get organized until they’re adopted into the consensus via a fork. The last suggestion can only happen at the time of the fork. 1- Segwit limit There will be a cap of 0.2kb of Segwit data per input in each transaction. So if your transaction has just one input, the allowed Segwit data is 0.2kb. If you want to include your fancy 5kb dickbutt.jpeg in Segwit, you’d need to merge or create 25 UTXOs to hit that 5kb Segwit data limit. This approach would make it way pricier for spammers to misuse Segwit and push them into consolidating their countless spammy dust UTXOs, which is a win for the UTXO set. Once they’ve run out of UTXOs to consolidate, they’ll need to generate a ton of UTXOs, making it too costly. At this point, spamming Segwit becomes more expensive than other spamming tactics. Spammers who continue to abuse Segwit would be motivated to shrink their junk jpegs in size. Meanwhile, this wouldn’t impact regular users who typically don’t need more than 0.2kb of Segwit data per input. 2- Increase dust limit from 540 sats to 20,000 sats. We’d bump the dust limit up from 540 sats to 20,000 sats. Plus, every four years during the halvening, that dust limit would be halved.

And then, you will see, that many miners don't follow them, so you will move quickly into proposing it as consensus rules. Also, if you have a node, without incoming connections, then even if you filter everything, it has almost no effect on other nodes. 200 bytes per input? One signature and one public key means around 100 bytes. Which means, that you will block everything more complex than 2-of-2 multisig. I wonder, will you block for example 4-of-6 multisig, coming from exchanges? Will you accidentally block your own withdrawals? Spammers can easily use multiple coins with single keys. For regular users with multisigs, you will just make life harder, because they will have to execute a multisig outside of Bitcoin, and only deploy the end result on-chain, which is difficult for many users to understand. Only with two people, because you will block everything bigger than 2-of-2 multisig. Even simple escrow with 2-of-3 multisig may be blocked by your filters. Your multisig restriction will block many L2s, which will force these users to deploy everything on-chain instead. Which will double the spam. Great. Not to mention, that users will just put their spam in their private keys, and weak signatures can be used to reveal it. Two signatures is actually beneficial for that kind of spammers, because they can then agree on a specific distance between R-values, and easily decode all data, while you will mistakenly mark it as a regular payment. It can be similar to Silent Payments, but instead of hiding the destination, it can be used to hide any data pushes. You know, why OP_RETURN was invented in the first place? Because other ways of pushing data are more harmful. Which will make anchors unspendable. You know, why bc1pfeessrawgf is used? Because in this way, second layer transactions can bump fees. And they use exactly zero satoshis, for example: https://mempool.space/tx/0e780555b3243748ea451723a2af2f3ef24b2cc5986fd5876a24d9d7c3d544be Data can be put into private keys instead. How would you stop it? Any weak signature can reveal the private key later, and allow reading it by anyone. And of course, you can try to block R-values of 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, but it would also block dust-sweeping people from using small signatures, and spammers can always switch to a different weak R-value, or even put additional data in their R-values.

To everyone else. I personally contacted @ertil by PM and invited him to comment on this thread. The reason for this is so I can expose his tactics. Notice in his post that he makes all sorts of technical sounding claims. The vast majority of readers won't have a clue what he is really saying or if it's even true or false. So most of you will conclude he sounds very technical, therefore he must by correct. But don't fall in that trap. If you don't understand something, ask him to clarify until you do understand. And watch him refuse to simplify anything for you. His goal is to throw as much shit on the wall as posiblle, and hope that some of it sticks. ertil rejects every single anti-spam idea and he supports blowing up of the op_return. His agenda is clear for all to see. Let's see together how full of shit ertil really is. Only two scenarios are available: after a year or two, either the filters work, or they don't work. If the filters work well enough, than problem solved. Nothing more needs to be done. Goal accomplished. If the filters don't work, if the large centralized spam pools keep defying the nodes policy, than we move the filters to the consensus layer with a soft fork, 2 to 4 years down the road. I would prefer to go directly to consensus via a soft fork. But there are two reasons why we should move to filters first: 1- I don't want to steal any thunder away from BIP110. I support BIP110 and I would prefer to wait until the BIP110 dust settles before I can start the fork proposal. 2- A year or two of the filters up would give time for wallets and users to update gradually and smoothly before we move to consensus. BIP110 is urgent, my proposal is not. We can afford to go to policy first and see if we can make that work. If not, soft fork we go! Is this where we pretend multisig only came to exist with Segwit? Here is a 2-of-3 multisig that uses a legacy public key. Please point to which aspect of this multisig my restrictions would prevent from occurring: https://mempool.space/tx/3d909442563bf7a167af9fdd521520dc66ab15356371d4fb8eabbdc40956548a The only part of that multisig that would require some modifications to work is that the 16,905 sats output would fall under the 20,000 sats dust limit. This could be worked around by re-using an input as that output. But even better would be for the recipient of the 16,905 sats to commit 20,000 to the multisig in order to receive an amount of 36,905 sats which is above the dust limit. I'm currently tabulating and compiling every single tx that makes use of Segwit. The scan is currently being done. So my numbers are not exact yet. But so far it's pretty grim and revealing. Over 99.32% of all monetary transactions that make use of Segwit have less than 0.2kb of Segwit data per input. So far only some rare exchange multisigs and liquid commits are going over the 0.2kb of Segwit data per input. These would have the option of adding more inputs to increase their Segwit data limit, or go back to what they were doing before Segwit came along. My Segwit spam transactions scan has not started yet. But my rough guesstimate tells me over 98-99% of transactions that go over the 0.2kb of Segwit data per input are spam. You full KYC centralized exchange can go back to doing whatever they were doing before Segwit came along. Those tx are so rare that their effect would barely be felt. What is difficult for many users to understand is what the fuck you are talking about. Go ahead people, re-read the quote above until you understand what he/she is talking about. You won't. Over 99% of monetary Segwit transactions use less than 0.2kb total per input. Bitcoin was functioning pretty well before Segwit. So even if we were to completely remove the Segwit upgrade, that would not amount to any confiscation. And I'm not suggesting to completely remove Segwit here, only assuring the spam abuses of Segwit are limited or stopped completely. Or at least made expensive enough to become undesirable. 2-of-3 multisigs would not be blocked by my rules. However some of those multisigs would have to be constructed differently. Especially if some of the outputs are under my raised dust limit. But they already have to deal with a dust limit. I would only raise the existing dust limit, not invent anything. Many of those L2's are scams and spam, such as citrea's suggested L2 for example. Sound and solid L2's like Lightening and Fedimint would still work perfectly fine. Merely stating that without expanding doesn't make your statement true. There is no evidence that requiring 2 signed messages per output under 100,000 sats would cause more spam. And this is why you just make the statement without ellaborating, and quickly move to change the subject to spam in private keys. Go ahead, put all the spam you want in your private keys. Private keys are not published on chain, they are stored locally on your wallet. Feel free to load up your wallet with all the dickpic.jpegs you desire. See if I care. You are just throwing random technical jargon at the wall, stuff nobody understands, and you hope some of it will stick. Requiring all outputs of <100,000 sats to have two signed messages would force spammers to put >100,000 sats in their fake pubkeys. This would prove too expensive. So spammers would be incentivized to make their fake pubkeys spendable, and eventually do spend them. Which would benefit the UTXO set. If signing messages to a pubkey was beneficial to spammers, they would already be doing it. And they are not doing it because it doesn't benefit them at all. Dealing with spammers and grifters, and conceding to them is what core does. We are no longer doing that. My other restrictions would make those other spam methods more expensive and incentivize spammers to use op_return instead. But within limits. No more blocks filled almost entirely with spam op_return! The link you provided is not valid. The address you provided is also not a valid bitcoin address.  But I'm pretty sure you are counting on readers to take your word and not click on it. The link you provided is to a fucking inscription in op_return. It's fucking spam. And my suggestions would not prevent that tx other than limiting them to 100 or so per block. My restrictions don't prevent the tx you linked to. But if it did, all he better. I'm okay with blocking spam. Go ahead and stuff all your spam and scams in your pdivate keys. Nobody cares because your keys are stored locally, Einstein. I wouldn't. That's a great idea! Why don't you go back to your spam friends and pitch that idea to them. I'd sure they would be delighted to expose to the world all the private keys of over 300 BTC of dust spam UTXOs for the rest of the world to steal their coin. For anyone else reading this, here is what spam loving ertil is suggesting: Spammers would store their spam on their private keys which are stored on their wallet, not on chain. Than the spammers would use a weak signature, so weak that other people would be able to figure out the private keys, and effectively be able to steal the 300+ BTC that is tied up in 100's of millions of spam dust UTXOs. It should be noted that I offered a test in my opening post for anyone who claims they can sign two messages to a fake pubkey. And ertil went out of his way to ignore it because he knows he can't pass that test. Instead, he goes on to make shit up, throw technical sounding bullshit at the wall, and hope some of it will stick. ertil counts on you not understanding what he is talking about.

Let's parse the witness space from your example: https://mempool.space/api/tx/3d909442563bf7a167af9fdd521520dc66ab15356371d4fb8eabbdc40956548a/hex See? The total witness space consumed is bigger than 200 bytes. It will, because instead of storing a single signature, you will need to store two. And you will need to keep it for a long enough time, to be safe from potential chain reorganizations. It is valid, and you even got an example transaction using it. It doesn't matter, if the private key is known, when a coin is already spent. Public keys are stored on-chain. And if a given signature is weak, then anyone can calculate that key, and read the data. Also, if a coin is spent, then nobody can steal it, because it is just already sent somewhere else, to some random key. Revealing private keys is needed only during data pushing, later, random keys can be used, just to transfer JPEG "ownership". Edit: I think it is a clear signal, that no BIP-110 restrictions will ever be temporary. Users who don't like BIP-110 will just stay with the original rules. And users who will activate BIP-110, despite being in a hashrate minority, will just have their own chain, where they will restrict things further, with next BIPs. Which means, that BIP-110 restrictions will never be lifted from BIP-110 chain.

Signature campaign would hate your idea, when some of them sometimes send lower than 100000 satoshi to some participant each week. But on technical side, 1. What exactly does re-used input mean? 2. Who need to create the two signed message? Only the sender using sender's address? That multisig input use P2SH-P2WSH script, so it's NOT legacy in any way. If you click "Details" on website you share, it clearly shows "P2SH redeem script" and "P2WSH witness script". Here's brief explanation of it.

I guess it is about address reuse. Which is a bad practice, but if BIP-110 supporters want to shoot themselves harder, than by "mandatory activation", then they can make it easier to reuse addresses, and provide incentives for users, to degrade their privacy, by using the same address multiple times. There is a reason, why the cost of doing it is the same, as using different keys. I wonder, how they would handle scripts like "OP_CHECKSIG OP_NOT", where invalid signatures are accepted. Will they restrict OP_CHECKSIG? Or eliminate OP_NOT from the Script? Who knows. Don't expect technically correct answer from people, who think, that anchors from BIP-433 don't exist, or are invalid. If they will block for example anchors, then second layer protocols, like Lightning Network, would have to guess the correct fee rates upfront, or would have to switch from keyless anchors into weak keys (for example with the private key, equal to one), which would just slow down validation, for absolutely no reason.