From: Erik Aronesty <erik@q32•com>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Ali Sherief <ali@notatether•com>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Tue, 9 May 2023 12:32:09 -0400 [thread overview]
Message-ID: <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com> (raw)
In-Reply-To: <ZFmNq6NzH4ruDsER@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
>
>
> > 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)
[-- Attachment #2: Type: text/html, Size: 1794 bytes --]
next prev parent reply other threads:[~2023-05-09 16:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-07 17:22 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 [this message]
2023-05-09 21:06 ` Tom Harding
2023-05-10 20:44 ` Keagan McClelland
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=CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=ali@notatether$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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