path: root/16/4fb5dd27876564cb99c2e4933c0f4e5e0d70ec

Return-Path: <john@synonym.to>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E7D4BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Dec 2022 09:57:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CAB324045C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Dec 2022 09:57:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CAB324045C
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
 header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=oiEiWSkq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LV5xRgTl8XH1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Dec 2022 09:57:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C54A4400F2
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com
 [IPv6:2607:f8b0:4864:20::d2a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C54A4400F2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Dec 2022 09:57:49 +0000 (UTC)
Received: by mail-io1-xd2a.google.com with SMTP id d123so5459572iof.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Dec 2022 01:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=synonym-to.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=mblHE7ypkab4NnZcTpas4q5Z4A0XebXuvyMfI3y6CTI=;
 b=oiEiWSkqgAxujDcwxiyrzs+4ebxOYkEnrW2jAF8HtL/GBhVbPswR13B/AIQ8BC0ztm
 UBwHrmjyAzoKaUSgqo4RJku1JKYYeeqRzFLrWekROZG0KVZ8j5w3nUlnXdlxTJR6xz7D
 ulqs2GDk7Mo/LENd3HNXQiHpqbsaraUglo/8ZTHaKSy3DmaEJYsbYcAWDc2spY5ZtYYH
 c+18L03R7cbJRMGC/CZZOT20lmvyAx+s4TxuC3Yase2vo3rS7OjyP+9ghJQ/llKx269A
 RhEjdXicUGtmHWagfS7FIPCNSijk8UcNek7TRjs9s2XokXRkCwD71/zgHEuU0IYGkSxF
 EyyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=mblHE7ypkab4NnZcTpas4q5Z4A0XebXuvyMfI3y6CTI=;
 b=03X7gSDSS15bBqDDDKpDvgJofclCnq7M+rJChBbzWI++no7yo6LMnQ5srb6GNAgPqZ
 KN5dOw/i6VHLesN8ol9cSzkZBgH9/u9fToP2rystPDX4Wd6pp3oyqrpe3efkxrdqbcex
 9kophsJjfzES/DlAlfmqczXOQdmio52gpA6/U7GpJqXew5f5wtYd4LkFhcg+mBmjFwcD
 TAHIUUtVF/+FkBIHFcMUY1sb0SjywpU23k2InxliFIJPTmfDNHLntL0c/3amcn9efZvX
 5a+ENiGJD2O6yLvpuK21t86Goe3VjwE6ktYdueR4Xw4y7f+LMiKp9SNZtX876mwU5WwM
 oPHg==
X-Gm-Message-State: ANoB5pmhApPCefPrEVRsCnyeKi7vI+R0Jy/fBxHO/boINKwNcF+VY7iZ
 EuFpUgT/Gbn7CTmu5ELS2/zIRtaOi9PFiZBhZX8KOA==
X-Google-Smtp-Source: AA0mqf75laE0W8ZDV6nnrhBPGMyPAUlVDWd5EW/+p8/LV8/lbqn87MtzJQVvsAfteadvuOtWVYh2G6Xa0BBxwplXgbM=
X-Received: by 2002:a5e:8e0b:0:b0:6e2:cbf3:9c9c with SMTP id
 a11-20020a5e8e0b000000b006e2cbf39c9cmr2156528ion.34.1670839068655; Mon, 12
 Dec 2022 01:57:48 -0800 (PST)
MIME-Version: 1.0
References: <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wri-edhivrtqZCoEzAPEmwZFap12mM4yzxgp77O-+JYA@mail.gmail.com>
 <mbdvMAocVkRVOHgwFJQ6z9c0IY1GxfhPKrIhd4yFYsYed_-m_0AzoELUhbBNEN1HByblCPmZmWyQ5Ow5TtGIY036az6gbfYUnyPtO_SkI18=@protonmail.com>
In-Reply-To: <mbdvMAocVkRVOHgwFJQ6z9c0IY1GxfhPKrIhd4yFYsYed_-m_0AzoELUhbBNEN1HByblCPmZmWyQ5Ow5TtGIY036az6gbfYUnyPtO_SkI18=@protonmail.com>
From: John Carvalho <john@synonym.to>
Date: Mon, 12 Dec 2022 09:57:37 +0000
Message-ID: <CAHTn92xmZLCbcEnTm6VvCX7=khdgkNjyoDh53OQtWb1HMj-_kA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000002a1de205ef9e89e8"
X-Mailman-Approved-At: Mon, 12 Dec 2022 17:46:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
 danger (angus)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 09:57:51 -0000

--0000000000002a1de205ef9e89e8
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=3D"ltr"><div>Zman,</div><div><br></div><div>Price Theory simply ex=
plains the relationship between supply &amp; demand. Your post makes some l=
ogical 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 les=
s utility, it will have less demand, regardless of whether it is well-optim=
ized to allow for capacity saturation.</div><div><br></div><div>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 &quot;reasonable,&quot; as you say, is irrelevant other tha=
n whether I personally, subjectively choose to participate.)=C2=A0</div><di=
v><br></div><div>The optimal state (most fees earned), would surely be a re=
sult of the most value provided (per blockspace, per=C2=A0time period). Whi=
le we must do our best to make sure txns have the smallest footprint, and t=
hat people have ways to pay a fee proportional to their time preference, th=
ere is always a maximum quantity of demand willing to pay any given fee. My=
 arguments express how zero-conf currently creates added demand for blocksp=
ace, by merchants/consumers, and additionally, demand for *next-block* incl=
usion (maximum time preference) due to merchants qualifying fee rates to be=
 eligible for zero-conf acceptance.</div><div><br></div><div>So, me saying =
that RBF is fee-minimization, which you have conceded, is apt, in that we s=
hould probably not trade off something like zero-conf utility (demand) for =
something like mempoolfullrbf=C2=A0(blanket replaceability that overrides s=
tatus quo use cases).=C2=A0</div><div><br></div><div>Your statement of &quo=
t;If more people could use RBF onchain, more people would use Bitcoin and i=
ncrease the value to miners.&quot; is not economically rational unless you =
truly can prove that supply creates demand. This is observably false, as bl=
ocks are not full.</div><div><br></div><div>Also, you stated &quot;Unfortun=
ately many 0-conf acceptors outright reject opt-in-RBF, despite the improve=
d 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=
.&quot; This is also irrational and incorrect. First, merchants do not &quo=
t;outright reject&quot; opt-in RBF, they simply make the customer wait 1 co=
nf. Second, full-rbf has no positive effect on price discovery for blockspa=
ce if it results in less people using Bitcoin for actual trade.</div><div><=
br></div><div>~John</div><div><br></div><div><br></div><div><br></div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It is helpful to remember that the fees are a price on confirmation.<br>
And in economics, there is a &quot;price theory&quot;:<br>
<br>
* As price goes down, demand goes up.<br>
* As price goes up, net-earning-per-unit goes up.<br>
<br>
The combination of both forces causes a curve where *total* earnings vs pri=
ce has a peak somewhere, an &quot;optimum price&quot;, and that peak is *un=
likely* to be at the maximum possible price you might deem reasonable.<br>
And this optimum price may very well be *lower* than the prevailing market =
price of a good.<br>
<br>
Thus, saying &quot;RBF is actually a fee-minimization feature&quot; neglect=
s the economics of the situation.<br>
If more people could use RBF onchain, more people would use Bitcoin and inc=
rease the value to miners.<br>
<br>
Rather than a fee-minimization feature, RBF is really an optimization to *s=
peed up* the discovery of the optimum price, and is thus desirable.<br>
<br>
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 p=
revalent.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--0000000000002a1de205ef9e89e8--