Quote from: pooya87 on Today at 06:04:34 AM

Quote from: be.open on Today at 05:20:44 AM

So, you are sure that in this section one more topic is needed to discuss the current situation. What are your constructive proposals for overcoming this crisis?

The fact that you have to ask this question proves you haven't seen my proposals ergo we did need a new topic.

To summarize the way to prevent this attack should have been the same method we have been using forever to prevent similar attacks and exploits. It could have been introduction of standard rules that would have made such malicious transactions non-standard hence majority of full nodes would have refused to relay them and that would have successfully prevented this attack from growing.
Standard rules are easy to implement too since they don't need a fork, we just had to get full nodes to run a patch for their old clients or run the newest release to enforce the new rule.

However, I don't see this method being effective anymore considering how the scam has grown big and the market size of it is considerable enough to encourage the scammers to run full nodes themselves without enforcing the said standard rule to relay their spam. There is also incentive for them to pay the miners behind the scene to mine their malicious transactions.

But what do you think of making transaction with script size above 10000 bytes or script which contain OP_PUSH (and it's variant) become non-standard?

Quote from: pooya87 on Today at 06:04:34 AM

--snip--

At this point I'm afraid we need a soft fork to make these transactions invalid/illegal as part of the consensus rules which is much more challenging since it requires implementation, locked-in period, getting miners to vote and accept this fork, etc.
But that effectively and easily prevent this attack whilst keeping the protocol flexible for future improvements. For example the rule can only limit the witness size for version 1 program (similar to version 0) and leave any bigger size for any future possible usages (if they arise) to future versions which are already non-standard and not relayed by any of the full nodes.

Both of us know Bitcoin community won't agree to such fork, especially considering some Bitcoiner heavily favor freedom or think Ordinals have acceptable usage (such as storing information about banned history on certain country).