public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Keagan McClelland <keagan.mcclelland@gmail.com>
To: Erik Aronesty <erik@q32.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Wed, 10 May 2023 16:44:05 -0400	[thread overview]
Message-ID: <CALeFGL3h4mW00j1nRJXcxr1HUnkzHnbxUo7t34AFGc==MnzaSw@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]

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 PM 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 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)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5119 bytes --]

  parent reply	other threads:[~2023-05-10 20:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-07 17:22 [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? Ali Sherief
2023-05-08 12:33 ` Michael Folkson
2023-05-08 12:58 ` Erik Aronesty
2023-05-08 17:13   ` Michael Folkson
2023-05-08 19:31     ` Ali Sherief
2023-05-08 19:47     ` Erik Aronesty
2023-05-08 20:36       ` Michael Folkson
2023-05-08 20:59         ` Erik Aronesty
2023-05-08 21:01           ` Erik Aronesty
2023-05-09 15:21     ` Tom Harding
2023-05-08 16:37 ` Melvin Carvalho
2023-11-03 10:15   ` Brad Morrison
2023-11-03 10:39     ` Melvin Carvalho
2023-11-04  9:58     ` ArmchairCryptologist
2023-05-08 22:37 ` Luke Dashjr
2023-05-09  0:02   ` Peter Todd
2023-05-09  1:43     ` Ali Sherief
2023-05-09 16:32     ` Erik Aronesty
2023-05-09 21:06       ` Tom Harding
2023-05-10 20:44       ` Keagan McClelland [this message]
2023-05-09  8:41 jk_14
2023-05-09 12:50 ` Erik Aronesty
2023-05-10  3:08   ` Weiji Guo
2023-05-11 13:12 Aleksandr Kwaskoff
2023-05-12  9:36 jk_14

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALeFGL3h4mW00j1nRJXcxr1HUnkzHnbxUo7t34AFGc==MnzaSw@mail.gmail.com' \
    --to=keagan.mcclelland@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox