You are repeating false talking points. Knots relays cp too and that doesn’t change even with 100% knots node coverage

Reply to this note

Please Login to reply.

Discussion

How old r u, 12?

If we all run knots the cp will not end up in opreturn because there will not be 100kb opreturn. Its that simple. Stop the loser semantics, its painfully pathetic.

This is 100% false, because filters is not consensus code. I suggest you learn how bitcoin works.

N,o what ur saying is false 💩

Nope, you are being lied to. Sorry. I know cognitive dissonance is hard to recover from. Good luck!

This i litterally the only thing coretards do, say that understand things better and thats why everykne else is wrong. With no proof or argumentation to show for.

Kruger dunning all day bro

you literally haven’t made any point this entire conversation or explained how i’m wrong. You just throw out words like kruger and coretards. I feel like i am losing brain cells so i’ll stop wasting my tjme.

Ivory tower all the way bro

another one 😂

Y? Because u can dissmiss my arguments and then claim u dont need arguments? Its not the flex u think 😆

Kruger-dunning is a bitch bro

Ironic coming from someone who obviously has no idea how bitcoin works

Ironically thechnically sound coding is not the topic we are discussing. The opreturn debate is about block space purpose and the monetarry mission of bitcoin to save the world from fiat tyrrany. U look really stupid beating around that bush.

Sorry? Is this happening now as we speak?

people have been storing data in bitcoin since the beginning. I wrote a bash one liner for extracting the whitepaper from the utxoset, even without txindex on.

That is the worst kind of spam since it permanently bloats the utxoset (unprunable). Luckily we have unfiltered op_return to encourage people not to do that.

Yes, storing data, but seems one of the biggest issues is what the data is.

having consensus code that discriminates different types of data would be a consensus nightmare (chaotic hardfork generator)

So consensus code that limits the size of the data would be better?

yes of course, that would prevent large op_returns, but it would push people into storing large amounts of data in worse ways, like multisig outputs, witness data, etc.

I like eriks analogy here:

“Look, no one wants garbage on the timechain, but people are gonna litter.

So, we can either make garbage cans for garbage (i.e. op_return) and people can put their garbage there, or people will put their garbage on the streets (UTXOs) b/c there are no garbage cans.”

https://x.com/erikcason/status/1962988112080187674?s=46