Bitcoin already has a spam prevention system called "fees".   I don't
believe it's insufficient.  The only issue is the stochastic nature of its
effectiveness

Which can be resolved with things like payment pools, tree payments (
https://utxos.org/uses/scaling/), etc.



On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Unfortunately, as near as I can tell there is no sensible way to
> > prevent people from storing arbitrary data in witnesses ...
>
> To prevent "from storing arbitrary data in witnesses" is the extreme
> case of the size limit discussed in this thread. Let's consider it along
> with other (less radical) options in order not to lose perspective,
> perhaps.
>
> > ...without incentivizing even worse behavior and/or breaking
> > legitimate use cases.
>
> I can't find evidence that would support the hypothesis. There had not
> been "even worse behavior and/or breaking legitimate use cases" observed
> before witnesses inception. The measure would probably restore
> incentives structure from the past.
>
> As a matter of fact, it is the current incentive structure that poses
> the problem - incentivizes worse behavior ("this sort of data is toxic
> to the network") and breaks legitimate use cases like a simple transfer
> of BTC.
>
> > If we ban "useless data" then it would be easy for would-be data
> > storers to instead embed their data inside "useful" data such as dummy
> > signatures or public keys.
>
> There is significant difference when storing data as dummy signatures
> (or OP_RETURN) which is much more expensive than (discounted) witness.
> Witness would not have been chosen as the storage of arbitrary data if
> it cost as much as alternatives, e.g. OP_RETURN.
>
> Also, banning "useless data" seems to be not the only option suggested
> by the author who asked about imposing "a size limit similar to OP_RETURN".
>
> > But from a technical point of view, I don't see any principled way to
> > stop this.
>
> Let's discuss ways that bring improvement rather than inexistence of a
> perfect technical solution that would have stopped "toxic data"/"crap on
> the chain". There are at least a few:
> - https://github.com/bitcoin/bitcoin/pull/28408
> - https://github.com/bitcoin/bitcoin/issues/29146
> - deprecate OP_IF opcode.
>
> I feel like the elephant in the room has been brought up. Do you want to
> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>