Filters work! Prove me wrong!

[PepeLapiu]

So we've been told that filters don't work. And the main evidence for this claim is that spammers can go around the filters.

Okay. So if filters don't work and the spammers can go around them, why can't Citrea do the same? Why does Citrea need the filters dropped in order to do op_return of more than 83 bytes?

I know some of you will tell me that filters don't work because some transactions that should have been filtered get mined anyways. But that ignores what filters really do.

Filters are not meant to censor any transaction, nobody can do that in bitcoin. Filters just add hurdles to anyone who would try to do a large op_return by making it more expensive.

And this has worked so well that in the 11 years the op_return filter was up, more than 99% of the op_return tx's were under 83 bytes.

And the funniest evidence that filters do work has been provided to us by none other than core spam in chief dev Peter Todd.

Peter Todd sent an op_return tx to prove that filters don't work. He did it about a couple of weeks ago. You can see the tx here:

https://mempool.space/tx/8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c?mode=details#flow=&vout=0

You'll notice that Todd paid $100 in miner fees to get his transaction confirmed. He had to pay over 2x the market rate, and that's with Core 30 having been run for over a month already. 10% of the nodes with filters down. And he still had to pay a handsome fee to get it confirmed.

Had the mining industry been less centralized, and everyone running the filters, he likely would have had to pay 5x the market rate.

Filters work, prove me wrong!

[retaur]

I'd guess it's to avoid chain splits, consensus issues and orphaning. Regardless of how and whether filters work they likely only target spv and other light wallets well. If you're running core and willing to pay the fees, you might get the transaction accepted just by broadcasting it enough. If you're sending your transaction directly to miners (some might still have their fee accelerator programmes) then you're even more likely to get one accepted.

As for paying 2x v 5x, I don't see the point of that bit. The transaction is still a size the miners could want to mine and I assume larger transactions take up less space in a block (Merkel tree storage wise) than smaller ones so there could be additional incentive there.

[PepeLapiu]

I'd guess it's to avoid chain splits, consensus issues and orphaning.

Did you conveniently forget to mention that a miner who puts stuff that's been filtered out will have an increased change of getting chain split and his block orphaned?

Regardless of how and whether filters work they likely only target spv and other light wallets well.

Speak English please. No idea what you are talking about.

If you're running core and willing to pay the fees, you might get the transaction accepted just by broadcasting it enough. If you're sending your transaction directly to miners (some might still have their fee accelerator programmes) then you're even more likely to get one accepted.

Of course if you have to repeatedly try to send your spam, and pay more to the miner, that creates an incentive to go back to your shitcoinery elsewhere.

As for paying 2x v 5x, I don't see the point of that bit.

So when you people have been telling me that the fee market will shake off the miners when the fees go up, that was all a lie?

[BlackHatCoiner]

He had to pay over 2x the market rate, and that's with Core 30 having been run for over a month already.

Huh? You do know that you can overpay a transaction just to make sure it stays into the candidate block in case the network becomes more congested and is being dropped to the second candidate block, right?

Did you conveniently forget to mention that a miner who puts stuff that's been filtered out will have an increased change of getting chain split and his block orphaned?

A miner is at risk of having his block orphaned if the other mining pools have a different mempool, because they need to download those extra transactions and during that time they can find a block and broadcast that instead. However, that risk is irrelevant to the nodes. All nodes might run Knots, but if the main mining pools run Core 30, then there is no tangible risk, as they are well connected to reduce that potential risk. They do have a great monetary benefit by including spam, though.

Also, as I've mentioned many times already, what you consider "spam" can take other forms that are much cheaper to use, and impossible to distinguish from regular transactions. And you'll probably push "spammers" toward that direction if you keep being hysteric about a non-issue.

[retaur]

Did you conveniently forget to mention that a miner who puts stuff that's been filtered out will have an increased change of getting chain split and his block orphaned?

Speak English please. No idea what you are talking about.

So you got the answers you asked for but don't want to comprehend or refute them?

[PepeLapiu]

Huh? You do know that you can overpay a transaction just to make sure it stays into the candidate block in case the network becomes more congested and is being dropped to the second candidate block, right?

Yes, I am aware there are other reasons to overpay the miner fee. This doesn't deter from the fact that something that gets filtered out will require you pay a higher fee for it.

A miner is at risk of having his block orphaned if the other mining pools have a different mempool, because they need to download those extra transactions and during that time they can find a block and broadcast that instead. However, that risk is irrelevant to the nodes. All nodes might run Knots, but if the main mining pools run Core 30, then there is no tangible risk, as they are well connected to reduce that potential risk. They do have a great monetary benefit by including spam, though.

What you are talking about refers to mining being too centralized. It's a big problem. It needs to be addressed. But trying to make the nodes bend to the will of the too centralized miners matching our mempool close to what the miners what, that is a catastrophic way to go about it.

It's basically saying "Okay miners, you want to mine spam for profit, we are just going to conform to your desires and standardize our mempool to match yours."

If you can't see the flaw in that rational, I can't help you.

Also, interestingly, miners don't use core. They use Peter Todd's OpenRelay implementation. Which is optimized to go around what the majority of the nodes want. This makes it blatantly obvious core is not working for us, they are working for miners and spammers, against the nodes.

Also, as I've mentioned many times already, what you consider "spam" can take other forms that are much cheaper to use, and impossible to distinguish from regular transactions.

I'm sorry to have to explain this to you, but if you are sending a tx with a 4kb witness, or something that clearly gets identified as an ordinal, rune, brc token, or an op_return with 100kb of data, you are clearly a spammer.

You can try to send an ordinal or rune into a fake pubkey. But that will still get filtered as an ordinal or rune.

And you'll probably push "spammers" toward that direction if you keep being hysteric about a non-issue.

I'm getting very annoyed with the idea that we have to bend the knee to spammers and give them whatever they want by fear they might go to a fake pubkey and cause UTXO bloat.

Newsflash my friend: the UTXO set more than tripled in size in the last 2-3 years. All the while we were bending the knee to spammers and doing absolutely nothing about spam. Clearly that approach is not working.

[ABCbits]

Okay. So if filters don't work and the spammers can go around them, why can't Citrea do the same? Why does Citrea need the filters dropped in order to do op_return of more than 83 bytes?

I don't bother research how Citrea works. But in general, some sidechain / L2 would submit certain data to Bitcoin blockchain at regular internal (such as every day or every 144 blocks). If they do that with non-standard TX, their TX can't be included in block in regular interval. It's because they need to hope the mining pool/miner would mine a block as soon as after they submit their non standard TX.

Huh? You do know that you can overpay a transaction just to make sure it stays into the candidate block in case the network becomes more congested and is being dropped to the second candidate block, right?

Yes, I am aware there are other reasons to overpay the miner fee. This doesn't deter from the fact that something that gets filtered out will require you pay a higher fee for it.

Not really. As long as they don't underpay on TX fee rate, their TX will be included as soon as there are miner/mining pool who're willing to include their TX.

[PepeLapiu]

Not really. As long as they don't underpay on TX fee rate, their TX will be included as soon as there are miner/mining pool who're willing to include their TX.

Yes, that is true but it doesn't take into account how filters work.

When your node filters out a tx, you simply don't add it to your mempool, and you don't relay it to other nodes.

Once a miner has found a block, he propagates it to the nodes.

The nodes have to verify that it contains valid tx's. If it's a "clean" block, verifying the tx's in it is instantaneous as you already have most of them in your mempool. So you add the block to your copy of the chain and propagate it to other nodes.

If the block contains a lot of spam you filtered out, you can't verify those tx's as you filtered them out, you don't have those in your mempool. So you have to request those tx's, download them, and verify them. And only than will you add the block to your copy of the chain and propagate it to other nodes.

So it takes longer for a block full of spam to propagate, and the miner risk of orphaned block and lost of his $350,000 reward increases.

So to compensate for this risk, spam miners charge extra fees for the spammers to put their filth in their next block.

In a way, you could say that mining is a race. And filters act as a speed bump that pops up only for miners who accept spam.

If you are the only one filtering spam, the speed bump will feel more like a grain of rice. The spam miner won't even feel it. But if the majority of nodes use the same filter, that becomes a major problem for the spam miner.

This filtering thing works so well that during the 11 years the op_return filter was in, more than 99% of the op_returns were under 83 bytes.

It's only now that core has blown up the filter that more and more op_returns are larger than 83 bytes. And if we allow them to keep growing, there will be more spam.

I suggest you look into BitcoinMechanic channel on YouTube. Maybe start watching his videos starting from 7-8 months ago.

[pooya87]

I'd guess it's to avoid chain splits, consensus issues and orphaning.

Stuff like OP_RETURN size are not consensus rules and they don't cause any kind of chain split.

If you're running core and willing to pay the fees, you might get the transaction accepted just by broadcasting it enough.

That is easy to verify. Choose any of the standard rules that still exist and try creating a transaction that breaks them and see if you broadcast them enough, it will get accepted or not!
One good one to test is using uncompressed pubkeys in a SegWit version 0 script...

[PepeLapiu]

Stuff like OP_RETURN size are not consensus rules and they don't cause any kind of chain split.

Actually, I believe he is referring to a different kind of soft fork which actually does happen all the time. Maybe less so now what with miner centralization.

Whenever two miners at the two extremes of the network find a block at the same time, that is a soft fork. And it gets settled a bit differently than a contentious soft fork. But it's a soft fork none the less.

That's why they say you wait for one confirm if you are buying a coffee, and you wait for 6 confirms if you are buying a luxury private jet.

[BlackHatCoiner]

Whenever two miners at the two extremes of the network find a block at the same time, that is a soft fork.

No, this is just a chain split. A soft fork is when the network is split into two different networks where one invalidates something that was previously valid. For example, if some nodes want to invalidate any transaction containing OP_RETURN, then that is a soft fork.

I'm sorry to have to explain this to you, but if you are sending a tx with a 4kb witness, or something that clearly gets identified as an ordinal, rune, brc token, or an op_return with 100kb of data, you are clearly a spammer.

What if I'm paying 1 satoshi to a thousand witness hashes? What then? Will you support a softfork for changing the minimum output value to something like 1000 sat? What if I include the data into the witness stack? What are you going to do in that case? Softfork to ScriptJr language? You keep whining about OP_RETURN, and how filters are supposed to make it more expensive to spam, while OP_RETURN is making 4x more expensive to use for spamming arbitrary data.

[PepeLapiu]

No, this is just a chain split.

A chain split is a kind of soft fork. Ask Andreas Antonopolos:

https://youtu.be/rpeceXY1QBM

A soft fork is when the network is split into two different networks where one invalidates something that was previously valid. For example, if some nodes want to invalidate any transaction containing OP_RETURN, then that is a soft fork.

Yeah, that's an other form of soft fork. Though I think your description is flawed, but I digress.

What if I'm paying 1 satoshi to a thousand witness hashes? What then?

I assume you are referring to the segwit size filter I mentioned earlier. I'm out of my dept on how that is calculated on Knots. But essentially, if you have a tx with two inputs and two outputs, and a segwit discount of 400kB, something is really wrong here. It's clear that even 1kB would be plenty sufficient unless you were trying to shove a jpeg in there.

Now, if you have a 1000 witness hashes? Not sure how the filter would address that.  

You keep whining about OP_RETURN, and how filters are supposed to make it more expensive to spam, while OP_RETURN is making 4x more expensive to use for spamming arbitrary data.

And that is my entire point here. Existing spammers are not likely to move to op_return and lose the witness discount to pay 4x more money. Even a few core devs agree with me that existing spammers will not switch to op_return, and it won't fix the UTXO set bloat.

So it's very clear this 100,000 bytes op_return is creating a new use care for spam while doing absolutely nothing about existing cases of spam.

So you tell me: what genuine bitcoin user needs 100,000 bytes of arb data in op_return?