the stupidest thing about #coretard arguments about allowing OP_RETURN to be bigger (as much as to 100kb) on the basis that it costs more is absurd, because spammers specifically want to pay as little as possible for their pollution.

it is irrelevant to the discussion of how to counter bloat of the blocks, because the cheapest way to spam the chain is by using SEGWIT and the TAPROOT implementation bug that removes the datacarrier limit.

how about stop defending your bad takes, and actually apply your pea brains to the question in hand: how to fix what went wrong when taproot unlocked the size limit on witness?

because that's the hole that is most glaring. instead they are talking about opening up OP_RETURN which by no reasonable logic will have any impact on the material problem that exists.

i thought that taproot would be good, enabling malleability-free signatures, more compact multisig and actually the whole thing was cocked up and was how this whole shit with ordinals on the chain started when someone figured out there was a vulnerability.

almost 2 years later and there's still no resolution for that, but instead we are hearing about how we should change the non-consensus mempool filter to allow more arbitrary data in another place in the code.

like, what the fuck, guys, you aren't doing your job. if the intention was to enable smart contract shit, then sure, but this just lets noise onto the chain, and potentially ugly noise.

fix the datacarrier limit problem, and fuck off with your psychological warfare against people who don't want to relay or store spam on their nodes.

the whole reason why so many people have started running knots is because there is a glaring hole in bitcoin's security against spam and there has been PLENTY of time to do something about it, instead of opening the path to even more irrelevant data, both OP_RETURN and BitVM bullcrap.

it's hard to not wonder whether the core team has got people playing with their minds and nudging them towards turning bitcoin into a tire fire of garbage.

I'm so glad to see someone who's more tech savvy saying this. Segwit, too. I get that it solved a problem, but I don't see anyone saying the witness discount was a necessary part of that.

Reply to this note

Please Login to reply.

Discussion

yeah, the witness discount was a trojan horse, for sure

eliminating that shrinks the chain space to 1mb again. it's not gonna break anything, just raise the price of using the exploit.

that should be the first thing they do to fix the problem, not argue with people about the principle of not opening up bitcoin to spammers on idiotic irrelevant points.

the segwit per push limit also is easy to enforce especially at the mempool level but it should be re-enabled, maybe it can be a bit bigger but forcing the users to make more pushes in their script would raise the amount of non-witness data also. so you see, the witness discount is a primary issue that enabled other shit to come into play. i don't think there is any good reason to allow bigger scripts with taproot either. this is just plain shitcoining.

er, i mean taproot per-push limit. that's the second problem.

copilot nailed it on both points, this would be the easiest, least complex, and easiest to justify pair of changes that would quell the raging plebs.

it was a good idea. however the implementation you could say is too naive.

they could have just added a new P2PKH schnorr signature transaction type. it was on the table back then, i remember ranting about it one time after reading up on the options that were being discussed.

instead we have witness discount and a bloated scripting signature algorithm that leaks the spending keys immediately instead of only at the moment of spend. and why, is my question, does taproot not have a limit on push data size?

i remember also the hype around pushing people to roll out taproot and once it hit like 10% of nodes using it the ordinals arrived.

next time additions to the consensus protocol are being discussed i'm gonna sniff it very closely

discussed by whom?

"they could have just added a new P2PKH schnorr signature transaction type"

something like that could be coming with bip-360.

"does taproot not have a limit on push data size"

ofc it has. 520 bytes per op, same as elsewhere.