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.