From: John Carvalho <john@synonym•to>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
Date: Mon, 12 Dec 2022 09:57:37 +0000 [thread overview]
Message-ID: <CAHTn92xmZLCbcEnTm6VvCX7=khdgkNjyoDh53OQtWb1HMj-_kA@mail.gmail.com> (raw)
In-Reply-To: <mbdvMAocVkRVOHgwFJQ6z9c0IY1GxfhPKrIhd4yFYsYed_-m_0AzoELUhbBNEN1HByblCPmZmWyQ5Ow5TtGIY036az6gbfYUnyPtO_SkI18=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]
Zman,
Price Theory simply explains the relationship between supply & demand. Your
post makes some logical leaps in that you are implying that demand follows
supply, which of course is not true, nor is that a claim of Price Theory.
If Bitcoin has less utility, it will have less demand, regardless of
whether it is well-optimized to allow for capacity saturation.
I do agree that there is an optimal state, and that such state is not
likely to be at the maximum price, because price maximization is exclusive.
(Whether I deem any of this as "reasonable," as you say, is irrelevant
other than whether I personally, subjectively choose to participate.)
The optimal state (most fees earned), would surely be a result of the most
value provided (per blockspace, per time period). While we must do our best
to make sure txns have the smallest footprint, and that people have ways to
pay a fee proportional to their time preference, there is always a maximum
quantity of demand willing to pay any given fee. My arguments express how
zero-conf currently creates added demand for blockspace, by
merchants/consumers, and additionally, demand for *next-block* inclusion
(maximum time preference) due to merchants qualifying fee rates to be
eligible for zero-conf acceptance.
So, me saying that RBF is fee-minimization, which you have conceded, is
apt, in that we should probably not trade off something like zero-conf
utility (demand) for something like mempoolfullrbf (blanket replaceability
that overrides status quo use cases).
Your statement of "If more people could use RBF onchain, more people would
use Bitcoin and increase the value to miners." is not economically rational
unless you truly can prove that supply creates demand. This is observably
false, as blocks are not full.
Also, you stated "Unfortunately many 0-conf acceptors outright reject
opt-in-RBF, despite the improved discovery of the optimum price, and thus
there is a need for full-RBF to improve price discovery of blockspace when
such acceptors are too prevalent." This is also irrational and incorrect.
First, merchants do not "outright reject" opt-in RBF, they simply make the
customer wait 1 conf. Second, full-rbf has no positive effect on price
discovery for blockspace if it results in less people using Bitcoin for
actual trade.
~John
It is helpful to remember that the fees are a price on confirmation.
> And in economics, there is a "price theory":
>
> * As price goes down, demand goes up.
> * As price goes up, net-earning-per-unit goes up.
>
> The combination of both forces causes a curve where *total* earnings vs
> price has a peak somewhere, an "optimum price", and that peak is *unlikely*
> to be at the maximum possible price you might deem reasonable.
> And this optimum price may very well be *lower* than the prevailing market
> price of a good.
>
> Thus, saying "RBF is actually a fee-minimization feature" neglects the
> economics of the situation.
> If more people could use RBF onchain, more people would use Bitcoin and
> increase the value to miners.
>
> Rather than a fee-minimization feature, RBF is really an optimization to
> *speed up* the discovery of the optimum price, and is thus desirable.
>
> Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite
> the improved discovery of the optimum price, and thus there is a need for
> full-RBF to improve price discovery of blockspace when such acceptors are
> too prevalent.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 4005 bytes --]
prev parent reply other threads:[~2022-12-12 9:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org>
2022-12-05 15:19 ` John Carvalho
2022-12-05 21:14 ` Erik Aronesty
2022-12-09 15:58 ` angus
2022-12-13 12:55 ` Anthony Towns
2022-12-12 2:27 ` ZmnSCPxj
2022-12-12 9:57 ` John Carvalho [this message]
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='CAHTn92xmZLCbcEnTm6VvCX7=khdgkNjyoDh53OQtWb1HMj-_kA@mail.gmail.com' \
--to=john@synonym$(echo .)to \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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