nostr:nevent1qqsf59x7fxkhx96ewqe4wrqshmyg2j383jxd4vds5a2hj3ax3m9wlqgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg5ywq98

"Censorship-resistant" always meant "no one can stop you from sending value wherever you want to send it." It never meant sending whatever data, files, or messages you want. Allowing ultra-tiny designators to ride along with the value can perhaps be tolerated, so long as they are not viewed as a precedent for anything else. People who want to mess around or get rich quick should do it somewhere else and leave one of humanity's greatest discoveries the Hell alone.

Individuals controlling their own mempool is not censorship.

I just want a ledger of financial transactions ... I don't want to host your kiddie porn.

here's its' take on what would resolve the issue:

To address the problem of users pushing large, cheap blobs of arbitrary data into the witness data section of Bitcoin transactions, a protocol rule change could focus on limiting the size and/or the type of data allowed in the witness, or increasing its economic cost. Here are possible solutions, with pros and cons:

1. Reinstate Per-Push Size Limits in Tapscript

Change:

Reintroduce a maximum byte limit (e.g., 520 bytes) for each individual data push in Tapscript, similar to pre-Taproot script rules.

Effect:

Prevents single pushes of multi-kilobyte or megabyte blobs, making it much harder to inscribe large files in a single input.

Pros:

Simple, familiar limit.

Stops most large data blobs.

Cons:

Can be circumvented by splitting data into many smaller pushes.

May break legitimate advanced scripts relying on larger pushes.

2. Reduce or Remove Witness Discount for Non-Signature Data

Change:

Alter the "witness discount" so that non-signature data (i.e., arbitrary data not used for script validation) is charged at full block weight, or even at a premium.

Effect:

Makes inscribing large blobs much more expensive economically, discouraging abuse.

Pros:

Targets the economic incentive directly.

Preserves flexibility for legitimate witness uses.

Cons:

Requires distinguishing between signature/script data and arbitrary data, which may be challenging in practice.

More complex to implement and enforce.

3. Explicit Protocol-Level Data Push Limits per Input

Change:

Set a maximum total witness size per input (e.g., 10 KB), not just per push.

Effect:

Directly caps the amount of data that can be inscribed in any given input.

Pros:

Simple enforcement.

No need to parse content type.

Cons:

May restrict legitimate use cases needing large scripts or multisigs.

May push abusers to use more inputs per transaction.

4. Disallow Script-Path Spends That Only Push Data

Change:

Add a rule that script-path spends must perform some cryptographic or script validation (e.g., require the use of OP_CHECKSIG or OP_CHECKSIGADD).

Effect:

Prevents witness data from being used purely as a data dump, forcing spends to be "meaningful."

Pros:

Targets the abuse pattern directly.

Still allows legitimate Taproot scripts.

Cons:

May break certain advanced scripting techniques.

Could be hard to define "meaningful" scripts.

5. Soft Fork to Add OP_RETURN-like Restriction to Witness Data

Change:

Forbid non-payment outputs (like OP_RETURN) in witness, or set a strict size limit for such data.

Effect:

Prevents using Taproot witness as a replacement for OP_RETURN, which is already limited.

Pros:

Consistent with existing OP_RETURN policy.

Cons:

Could require complex script analysis.

May impact future extensibility.

Summary Table

Solution Stops Large Blobs? Breaks Existing Use? Economic Impact Implementation Complexity

Per-Push Limit Yes (mostly) Possible None Low

Remove Discount Yes (by cost) No High Medium

Per-Input Limit Yes Possible Moderate Low

Require Checksigs Yes (pattern) Possible None Medium

OP_RETURN Restriction Yes Possible None Medium

Recommended:

A combination of reducing the witness discount for non-signature/script data and reinstating a reasonable per-push size limit would be most effective, minimizing protocol breakage while curbing abuse.

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.

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