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.
each of the items in my ideas (all but one) would be first proposed as filters
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.
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!
Each tx will be limited to 0.2kb of Segwit total data per input.
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.
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/3d909442563bf7a167af9fdd521520dc66ab15356371d4fb8eabbdc40956548aThe 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 wonder, will you block for example 4-of-6 multisig, coming from exchanges? Will you accidentally block your own withdrawals?
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.
Spammers who keep abusing Segwit would be incentivised to make their garbage jpegs smaller and smaller. All the while this would have no effect on every day monetary users who almost never ever need more than 0.2kb of Segwit data per input.
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.
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.
Should you wish to send me 19,000 sats, you would be able to do so with a multisig
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.
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.
smaller spends would be better served with L2's
Your multisig restriction will block many L2s, which will force these users to deploy everything on-chain instead.
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.
Require all outputs of <100,000 sats to have two signed messages
Which will double the spam. Great.
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.
Not to mention, that users will just put their spam in their private keys, and weak signatures can be used to reveal it.
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.
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 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.
Say 100 op_return per block.
You know, why OP_RETURN was invented in the first place? Because other ways of pushing data are more harmful.
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!
Any UTXO of <1,000 sats older than 18 years would be removed from the UTXO set and become unspendable.
Which will make anchors unspendable. You know, why
bc1pfeessrawgf is used?
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.
I would love for you to tell me how you are going to get around my new rules.
Data can be put into private keys instead.
Go ahead and stuff all your spam and scams in your pdivate keys. Nobody cares because your keys are stored locally, Einstein.
How would you stop it?
I wouldn't.
Any weak signature can reveal the private key later, and allow reading it by anyone.
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.
message="Hello world from my private key!"
privkey=48656c6c6f20776f726c642066726f6d206d792070726976617465206b657921
pubkey=036914D6B4D7E602A1EAD67C9B70499666C7B24E251B76852DF7BB28075B1BD4FF
weak_R_value=0200000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
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.
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.
