From: Erik Aronesty <erik@q32•com>
To: vjudeu@gazeta•pl
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] tx max fee
Date: Wed, 10 May 2023 13:42:37 -0400 [thread overview]
Message-ID: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com> (raw)
In-Reply-To: <158873530-26c4ca5223c12fad28089c0ab56e9528@pmq8v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
confused. the rule was "cannot pay a fee > sum of outputs with
consideration of cpfp in the mempool"
your example is of someone paying a fee "< sum" which wouldn't be blocked
note: again, i'm not a fan of this, i like the discussion of "bitcoin as
money only" and using fee as a lever to do that
show me how someone could move 1 btc and pay 2 btc as fees... i think we
can block it at the network or even the consensus layer, and leave anything
but "non-monetary use cases" intact. the only way around it is to
maintain balances and use change addresses. which would force nft and
timestamp users to maintain these balances and would be a deterrent
im am much more in favor of doing something like op_ctv which allows many
users to pool fees and essentially "share" a single utxo.
.
On Wed, May 10, 2023 at 12:19 PM <vjudeu@gazeta•pl> wrote:
> > possible to change tx "max fee" to output amounts?
>
> Is it possible? Yes. Should we do that? My first thought was "maybe", but
> after thinking more about it, I would say "no", here is why:
>
> Starting point: 1 BTC on some output.
> Current situation: A single transaction moving 0.99999000 BTC as fees, and
> creating 1000 satoshis as some output (I know, allowed dust values are
> lower and depend on address type, but let's say it is 1k sats to make
> things simpler).
>
> And then, there is a room for other solutions, for example your rule,
> mentioned in other posts, like this one:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html
>
> > probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
> Possible situation after introducing your proposal, step-by-step:
>
> 1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as
> fees. Assuming your rules are on consensus level, the first transaction
> creates 0.5 BTC output and 0.5 BTC fee.
> 2) That person still wants to move 0.5 remaining BTC, and still is willing
> to pay 0.49999000 BTC as fees. Guess what will happen: you will see another
> transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
> ...
> N) Your proposal replaced one transaction, consuming maybe one kilobyte,
> with a lot of transactions, doing exactly the same, but where fees are
> distributed between many transactions.
>
> Before thinking about improving that system, consider one simple thing: is
> it possible to avoid "max fee rule", no matter in what way it will be
> defined? Because as shown above, the answer seems to be "yes", because you
> can always replace a single transaction moving 1 BTC as fees with multiple
> transactions, each paying one satoshi per virtual byte, and then instead of
> consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC,
> so 100 MvB per 1 BTC mentioned in the example above.
>
>
>
> On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> possible to change tx "max fee" to output amounts?
>
>
> seems like the only use case that would support such a tx is spam/dos type
> stuff that satoshi warned about
>
>
> its not a fix for everything, but it seems could help a bit with certain
> attacks
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4037 bytes --]
next prev parent reply other threads:[~2023-05-10 17:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 16:19 vjudeu
2023-05-10 17:42 ` Erik Aronesty [this message]
2023-05-11 11:02 ` vjudeu
2023-05-11 12:32 ` Kalle Rosenbaum
2023-05-11 15:20 ` Andrew Baine
2023-05-12 0:06 ` Tom Harding
-- strict thread matches above, loose matches on Subject: below --
2023-05-07 23:59 Erik Aronesty
2023-05-08 23:57 ` Peter Todd
2023-05-09 0:04 ` Erik Aronesty
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=CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/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