MIME-Version: 1.0
References: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>
 <0aea4ec5-7d6a-f358-3c20-854001588031@dashjr.org>
 <ZFmNq6NzH4ruDsER@petertodd.org>
In-Reply-To: <ZFmNq6NzH4ruDsER@petertodd.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 9 May 2023 12:32:09 -0400
Message-ID: <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000093525f05fb454c1e"
Cc: Ali Sherief <ali@notatether.com>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
 non-standard Taproot transactions from full nodes?
Precedence: list

--00000000000093525f05fb454c1e
Content-Type: text/plain; charset="UTF-8"

>
>
> > 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 not
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)

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><br>&gt; no data at all</blockquote><div><br></div><div>=
exactly, which is why a relationship between &quot;cpfp-inclusive outputs&q=
uot; and &quot;fees&quot; makes sense.=C2=A0 =C2=A0it&#39;s clear that&#39;=
s a good definition of dust, and not too hard to get a working pr up for th=
e network-layer.=C2=A0 =C2=A0i get that your node will 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><d=
iv>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-economic use cases is th=
e right move, given the game-theory of what underpins bitcoin</div><div><br=
></div><div>i&#39;m sad (honestly) to say that it might be</div><div><br></=
div><div>it may very well be that bitcoin *cannot* be a &quot;global ledger=
 of all things&quot; in order to remain useful and decentralized, and inste=
ad 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 solution so much as i woul=
d like a=C2=A0</div><div><br></div><div>- rational=C2=A0conversation about =
the incentives=C2=A0</div><div>- whether this solution would be an effectiv=
e enough barrier to keep most non-economic tx off bitcoin</div><div><br></d=
iv><div>obviously it&#39;s easy enough to evade if every non-economic user =
simply keeps enough bitcoin around and sends it back 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 certainly breaks ordinals, sinc=
e it can never be 1 sat)</div><div><br></div></div></div>

--00000000000093525f05fb454c1e--