From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D1EA5C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Dec 2023 09:58:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9A3044027D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Dec 2023 09:58:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A3044027D
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com
header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256
header.s=20230601 header.b=zDuLtNDZ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id VTyqRpxE3FLr
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Dec 2023 09:58:55 +0000 (UTC)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
[IPv6:2607:f8b0:4864:20::1136])
by smtp4.osuosl.org (Postfix) with ESMTPS id 8FCD8401CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Dec 2023 09:58:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8FCD8401CA
Received: by mail-yw1-x1136.google.com with SMTP id
00721157ae682-5eb8b6e8d76so8500827b3.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Dec 2023 01:58:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1703930334; x=1704535134;
darn=lists.linuxfoundation.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=ZMzTy5/MaFpjZSSpRdmQK6Ae3vFQIKpl8BjPpLaHnxo=;
b=zDuLtNDZpmdSK4aEZ8/1UfQ4LdGb2mIYzJvl+qpXdrXhantGwy0Z5PLokLzdW1tOP6
0CEsxIYJTSjniZLcVvH+XUi4DM95ixH0+8JAq/u+2ez6fYy32xh/4/SofBuOL47iEgfh
pyFPHFh4dXINXUgA1Fl+3fD9bzwusQ1yKwIUtaLwHFcWnkQkme1Xk9zD+p18zBfUsKe7
JKF8KUE7ep6E+1zItBA4hhqh8yefFxKT6cm5cw/jMIBnzTV6WkpgGFFKhrsMRElqFBtw
FRDc77647BiyuhFy3K6Nbj1IXa0IUsv7HF5Gft57Lri2EOYfwLQ/0D1HpA4bmfM1GBVD
xa3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1703930334; x=1704535134;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=ZMzTy5/MaFpjZSSpRdmQK6Ae3vFQIKpl8BjPpLaHnxo=;
b=ADHkHzdqnljzgkz3Xml99ag5uG9otTVhZEw8ImMd+H0g5dPXVCuC0HvcCFWJVCBXgQ
PUaqLftK1imulxN3PojkjxITF0EO1GJBb0lCpyYOQJy7Q8EVUwiIssXUWJC/8UtH4KXU
9m+TjYVWHZWmj/k2XyVFN3TPX46fWyS5x3nQh9mFDfOkhibJYVP0w43KS8jah0HmvpZa
m5bFUeAiDCnxtTGZb8WppBZqaLoBYpWjJbQaqwG40BTAkwbjYSKxxB7OsoqzC2v7TluS
IlW1UkqXnnRQuJLzxpXe6XNpMSik0wIKDU3s1RaO1ozdXjk0P4pQ+mT1Ms83Hs4Xk8jN
qBeA==
X-Gm-Message-State: AOJu0YwJX3+OgioqxbeHPZjuLNRIxGYagDTq/pauh3dPAJwpNym/u0As
y888Q+0q3NAZK5tYyTAM+GJM/Tztsz1XegQfsWZOuuo=
X-Google-Smtp-Source: AGHT+IGnyJYz2PrAwBsYX80jdr/pxevYtYJiTn2GMLj9TW1pUF0zFQFLOnWxvNCHildXAfteJGanntHwjsJh69Y0+og=
X-Received: by 2002:a25:c444:0:b0:daf:f8b6:2d5e with SMTP id
u65-20020a25c444000000b00daff8b62d5emr9261760ybf.4.1703930334239; Sat, 30 Dec
2023 01:58:54 -0800 (PST)
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"
X-Mailman-Approved-At: Sat, 30 Dec 2023 15:58:26 +0000
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Dec 2023 09:58:57 -0000
--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 "=
;fees".=C2=A0 =C2=A0I don't believe it'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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">> Unfortunately, as near as I can tell there is no sensible wa=
y to<br>
> prevent people from storing arbitrary data in witnesses ...<br>
<br>
To prevent "from storing arbitrary data in witnesses" is the extr=
eme<br>
case of the size limit discussed in this thread. Let's consider it alon=
g<br>
with other (less radical) options in order not to lose perspective, perhaps=
.<br>
<br>
> ...without incentivizing even worse behavior and/or breaking<br>
> legitimate use cases.<br>
<br>
I can't find evidence that would support the hypothesis. There had not<=
br>
been "even worse behavior and/or breaking legitimate use cases" 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 ("this sort of data is toxic=
<br>
to the network") and breaks legitimate use cases like a simple transfe=
r<br>
of BTC.<br>
<br>
> If we ban "useless data" then it would be easy for would-be =
data<br>
> storers to instead embed their data inside "useful" data suc=
h as dummy<br>
> 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 "useless data" seems to be not the only option sugg=
ested<br>
by the author who asked about imposing "a size limit similar to OP_RET=
URN".<br>
<br>
> But from a technical point of view, I don't see any principled way=
to<br>
> stop this.<br>
<br>
Let's discuss ways that bring improvement rather than inexistence of a<=
br>
perfect technical solution that would have stopped "toxic data"/&=
quot;crap on<br>
the chain". 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'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--