MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <Y9PPvBiWOXpBefmD@camus> <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
In-Reply-To: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sat, 30 Dec 2023 02:58:41 -0700
Message-ID: <CAJowKgJ8n0GFj3S88qW+rk2RcLg-1JH9aL22YtTB-55EEQzsYw@mail.gmail.com>
To: Greg Tonoski <gregtonoski@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004b6243060db73262"
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Precedence: list

--0000000000004b6243060db73262
Content-Type: text/plain; charset="UTF-8"

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
>

--0000000000004b6243060db73262
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Bitcoin already has a spam prevention system called &quot=
;fees&quot;.=C2=A0 =C2=A0I don&#39;t believe it&#39;s insufficient.=C2=A0 T=
he only issue is the stochastic nature of its effectiveness<div dir=3D"auto=
"><br></div><div dir=3D"auto">Which can be resolved with things like paymen=
t pools, tree payments (<a href=3D"https://utxos.org/uses/scaling/">https:/=
/utxos.org/uses/scaling/</a>), etc.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">&gt; Unfortunately, as near as I can tell there is no sensible wa=
y to<br>
&gt; prevent people from storing arbitrary data in witnesses ...<br>
<br>
To prevent &quot;from storing arbitrary data in witnesses&quot; is the extr=
eme<br>
case of the size limit discussed in this thread. Let&#39;s consider it alon=
g<br>
with other (less radical) options in order not to lose perspective, perhaps=
.<br>
<br>
&gt; ...without incentivizing even worse behavior and/or breaking<br>
&gt; legitimate use cases.<br>
<br>
I can&#39;t find evidence that would support the hypothesis. There had not<=
br>
been &quot;even worse behavior and/or breaking legitimate use cases&quot; o=
bserved<br>
before witnesses inception. The measure would probably restore<br>
incentives structure from the past.<br>
<br>
As a matter of fact, it is the current incentive structure that poses<br>
the problem - incentivizes worse behavior (&quot;this sort of data is toxic=
<br>
to the network&quot;) and breaks legitimate use cases like a simple transfe=
r<br>
of BTC.<br>
<br>
&gt; If we ban &quot;useless data&quot; then it would be easy for would-be =
data<br>
&gt; storers to instead embed their data inside &quot;useful&quot; data suc=
h as dummy<br>
&gt; signatures or public keys.<br>
<br>
There is significant difference when storing data as dummy signatures<br>
(or OP_RETURN) which is much more expensive than (discounted) witness.<br>
Witness would not have been chosen as the storage of arbitrary data if<br>
it cost as much as alternatives, e.g. OP_RETURN.<br>
<br>
Also, banning &quot;useless data&quot; seems to be not the only option sugg=
ested<br>
by the author who asked about imposing &quot;a size limit similar to OP_RET=
URN&quot;.<br>
<br>
&gt; But from a technical point of view, I don&#39;t see any principled way=
 to<br>
&gt; stop this.<br>
<br>
Let&#39;s discuss ways that bring improvement rather than inexistence of a<=
br>
perfect technical solution that would have stopped &quot;toxic data&quot;/&=
quot;crap on<br>
the chain&quot;. There are at least a few:<br>
- <a href=3D"https://github.com/bitcoin/bitcoin/pull/28408" rel=3D"noreferr=
er noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/28=
408</a><br>
- <a href=3D"https://github.com/bitcoin/bitcoin/issues/29146" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/issue=
s/29146</a><br>
- deprecate OP_IF opcode.<br>
<br>
I feel like the elephant in the room has been brought up. Do you want to<br=
>
maintain Bitcoin without spam or a can&#39;t-stop-crap alternative, everybo=
dy?<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000004b6243060db73262--