path: root/41/58d85f0e2c95a84737cb2fec5e70d72c6489d7

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 53834C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 20:44:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2539941498
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 20:44:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2539941498
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=b8bQLgDo
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 mC8NxHWKWoCU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 20:44:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 47A3B409A9
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [IPv6:2a00:1450:4864:20::32e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 47A3B409A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 20:44:19 +0000 (UTC)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-3f315712406so261739435e9.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 13:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1683751457; x=1686343457;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=78w51nIUNtrGdDZLG2sVWjQQG+cyJInkxW6+lvQ1hOk=;
 b=b8bQLgDogdv1QgeoAjY7WQxwaMf1qfUfwpDVK+TCYqqTOPQmllrq66vDk6b17VzRjT
 58P4b16WWV/z2EQ4+VJx0+ZarYU55kWuTVtfHdt+annvDkVAceTEuN3YBmI81atw3TSN
 XRn1trmWrEiCF3fb6mWrIb6NH/7O89KhyYAavQ7q5vTcG1sprjLoyLs0mljl7K+M3eMm
 XOp0z/KFlk0vFiir9oGI6OilavKWPObvLso3efLiLNUIrGauUwgIOjeWgZ0nvumwjtZr
 ERSlTIJugLMH1z1Dzp5Guw76UpqFLa+G9YaZwf6ktanYMMpDBQeUrnQ0PZM9+qC+Xi/M
 KYCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683751457; x=1686343457;
 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=78w51nIUNtrGdDZLG2sVWjQQG+cyJInkxW6+lvQ1hOk=;
 b=Cb2bsHti5rgH2aa0gQzVIPZWdqMuhp2Kd9tdNG2suDYpRzRiU4PU37sFg7z9XSXuSK
 rCcl+t4FbV7ZNQRm77FGlqKNwl/hTJEzpqjBXaCGYnXgQwz8E51C21eKMppz07s0Q0Nd
 UHI167QaGhNnHhxiV8pae8Rp3cmKmYXB7awlqH0CIlhG/mutpG5i+jKx9+r6H7gmSx95
 IO+1puV7/u6pJlHalCpsZZQw6DldOwti2HImUp0X7gQvSUw/DpMSBDCOzISmIieYIfQ9
 tDd24IObhRCBcewHJO7Rk/jf/KgOdgXPjlICoMuwU2pPrwxj+l2fm+DIN9o+a+QIcfNp
 jqAg==
X-Gm-Message-State: AC+VfDyVGf3QHq0gTPQkeDHFKo9KASY8N7UaYn6yD2R2GT1Fr68m1jQN
 wyfn+ZjWn/3kjDg9Hu4+31nz70Zv+xtF3zEzrJL9ALmAOE8=
X-Google-Smtp-Source: ACHHUZ6uuc+iKuo3/2qj3DkFbHTtdqdtoM+sSlXny2EWcrtXWT5ektE47qiAqLAroA1WZdBCPf2NEPQYjoC37L4tZqs=
X-Received: by 2002:a5d:4b0f:0:b0:2cf:e313:2860 with SMTP id
 v15-20020a5d4b0f000000b002cfe3132860mr11043978wrq.33.1683751457031; Wed, 10
 May 2023 13:44:17 -0700 (PDT)
MIME-Version: 1.0
References: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>
 <0aea4ec5-7d6a-f358-3c20-854001588031@dashjr.org>
 <ZFmNq6NzH4ruDsER@petertodd.org>
 <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com>
In-Reply-To: <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Wed, 10 May 2023 16:44:05 -0400
Message-ID: <CALeFGL3h4mW00j1nRJXcxr1HUnkzHnbxUo7t34AFGc==MnzaSw@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007c8cb605fb5cefe7"
X-Mailman-Approved-At: Thu, 11 May 2023 11:56:59 +0000
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
 non-standard Taproot transactions from full nodes?
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: Wed, 10 May 2023 20:44:21 -0000

--0000000000007c8cb605fb5cefe7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Erik,

I'm curious about what you believe to be "non-economic" txs. As far as I
can tell, any transaction included in the blockchain is economically
motivated by the very evidence of fees paid. That said, for the sake of
argument if we assume that there exists a category of information that
constitutes "non-economic" information, then so long as there is any
variance in the way to express a single economic intention, there exists a
vector for including "non-economic" information. I'll add beyond this that
there must always be variance in the way to express the same intent because
the signature data must be indistinguishable from entropy for Bitcoin's
security to hold.

Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of
the day that is currently being used to propagate such "non-economic"
information, we will always have the potential variance in the signature
data to do so. The best you can hope for is to make such means so
inefficient that the real cost-per-bit is expensive enough that there are
fewer distinct use cases. However, this isn't enough to actually *prevent*
the "spam". By increasing the cost-per-bit, it may limit it to only
"non-economic" information of extremely high value (note the
contradiction), it limits the number of use cases while also increasing the
impact of the use cases that make it past that threshold. Thus, it isn't
the impact of spam that is being reduced so much as it is reducing the
number of distinct use cases that result in "spam". Perhaps this is enough
to make spam more intermittent, and maybe on those grounds alone it could
be worth it, but I doubt it.

IMO the proper way to handle things like this isn't to introduce consensus
or relay policy to incentivize the expansion of the chain weight these
"non-economic" use cases require, but rather to reduce the necessary chain
footprint of supposed "economically motivated" transactions, which
incidentally is the entire point of all layered scaling tech. The current
fees we are experiencing are still significantly lower than they need to be
if Bitcoin is going to survive in a post-subsidy era. If our layered
protocols can't survive the current fee environment, the answer is to fix
the layered protocols.

Food for thought.

Stay Inspired,
Keags

On Tue, May 9, 2023 at 12:38=E2=80=AFPM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>> > no data at all
>
>
> exactly, which is why a relationship between "cpfp-inclusive outputs" and
> "fees" makes sense.   it's clear that's a good definition of dust, and no=
t
> too hard to get a working pr up for the network-layer.   i get that your
> node will still route.   i get that it would break timestamps, indeed, it
> would break all non-economic use cases if we made it a consensus change.
>
> but that's the point of the discussion.
>
> the question is whether breaking all non-economic use cases is the right
> move, given the game-theory of what underpins bitcoin
>
> i'm sad (honestly) to say that it might be
>
> it may very well be that bitcoin *cannot* be a "global ledger of all
> things" in order to remain useful and decentralized, and instead the
> monetary use case must be it's only goal
>
> also, i'm not really advocating for this solution so much as i would like
> a
>
> - rational conversation about the incentives
> - whether this solution would be an effective enough barrier to keep most
> non-economic tx off bitcoin
>
> obviously it's easy enough to evade if every non-economic user simply
> keeps enough bitcoin around and sends it back to himself
>
> so maybe it's a useless idea?   but maybe that's enough of a hassle to
> stop people (it certainly breaks ordinals, since it can never be 1 sat)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Erik,<div><br></div><div>I&#39;m curious about what you be=
lieve to be &quot;non-economic&quot; txs. As far as I can tell, any transac=
tion included in the blockchain is economically motivated by the very evide=
nce of fees paid. That said, for the sake of argument if we assume that the=
re exists a category of information that constitutes &quot;non-economic&quo=
t; information, then so long as there is any variance in the way to express=
=C2=A0a single economic intention, there exists a vector for including &quo=
t;non-economic&quot; information. I&#39;ll add beyond this that there must =
always be variance in the way to express the same intent because the signat=
ure data must be indistinguishable from entropy for Bitcoin&#39;s security =
to hold.</div><div><br></div><div>Even if we eliminate small UTXOs, OP_RETU=
RN, or whatever other vector of the day that is currently being used to pro=
pagate such &quot;non-economic&quot; information, we will always have the p=
otential variance in the signature data to do so. The best you can hope for=
 is to make such means so inefficient that the real cost-per-bit is expensi=
ve enough that there are fewer distinct use cases. However, this isn&#39;t =
enough to actually <b>prevent</b> the &quot;spam&quot;. By increasing the c=
ost-per-bit, it may limit it to only &quot;non-economic&quot; information o=
f extremely high value (note the contradiction), it limits the number of us=
e cases while also increasing the impact of the use cases that make it past=
 that threshold. Thus, it isn&#39;t the impact of spam that is being reduce=
d so much as it is reducing the number of distinct use cases that result in=
 &quot;spam&quot;. Perhaps this is enough to make spam more intermittent, a=
nd maybe on those grounds alone it could be worth it, but I doubt it.</div>=
<div><br></div><div>IMO the proper way to handle things like this isn&#39;t=
 to introduce consensus or relay policy to incentivize the expansion of the=
 chain weight these &quot;non-economic&quot; use cases require, but rather =
to reduce the necessary chain footprint of supposed &quot;economically moti=
vated&quot; transactions, which incidentally is the entire point of all lay=
ered scaling tech. The current fees we are experiencing are still significa=
ntly lower than they need to be if Bitcoin is going to survive in a post-su=
bsidy era. If our layered protocols can&#39;t survive the current fee envir=
onment, the answer is to fix the layered protocols.</div><div><br></div><di=
v>Food for thought.</div><div><br></div><div>Stay Inspired,</div><div>Keags=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Tue, May 9, 2023 at 12:38=E2=80=AFPM Erik Aronesty via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><br>&gt; no data at all</blockqu=
ote><div><br></div><div>exactly, which is why a relationship between &quot;=
cpfp-inclusive outputs&quot; and &quot;fees&quot; makes sense.=C2=A0 =C2=A0=
it&#39;s clear that&#39;s a good definition of dust, and not too hard to ge=
t a working pr up for the network-layer.=C2=A0 =C2=A0i get that your node w=
ill still route.=C2=A0 =C2=A0i get that it would break timestamps, indeed, =
it would break all non-economic use cases if we made it a consensus change.=
</div><div><br></div><div>but that&#39;s the point of the discussion.=C2=A0=
 =C2=A0</div><div><br></div><div>the question is whether breaking all non-e=
conomic use cases is the right move, given the game-theory of what underpin=
s bitcoin</div><div><br></div><div>i&#39;m sad (honestly) to say that it mi=
ght be</div><div><br></div><div>it may very well be that bitcoin *cannot* b=
e a &quot;global ledger of all things&quot; in order to remain useful and d=
ecentralized, and instead the monetary use case must be it&#39;s only goal<=
/div><div>=C2=A0</div><div>also, i&#39;m not really advocating for this sol=
ution so much as i would like a=C2=A0</div><div><br></div><div>- rational=
=C2=A0conversation about the incentives=C2=A0</div><div>- whether this solu=
tion would be an effective enough barrier to keep most non-economic tx off =
bitcoin</div><div><br></div><div>obviously it&#39;s easy enough to evade if=
 every non-economic user simply keeps enough bitcoin around and sends it ba=
ck to himself</div><div><br></div><div>so maybe it&#39;s a useless idea?=C2=
=A0 =C2=A0but maybe that&#39;s enough of a hassle to stop people (it certai=
nly breaks ordinals, since it can never be 1 sat)</div><div><br></div></div=
></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000007c8cb605fb5cefe7--