path: root/57/34913505e6113c4bd039b9f0b3664308d01be8

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9645CC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 00:35:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9174160B97
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 00:35:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kIYPNOhETHuH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 00:35:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
 [IPv6:2607:f8b0:4864:20::b2b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2C35E6F79D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 00:35:15 +0000 (UTC)
Received: by mail-yb1-xb2b.google.com with SMTP id e140so16341406ybh.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Feb 2022 16:35:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=mJkZyrtHfMCWNFGd7xPoeAS/el/DiFqRnTbtHnDnMBM=;
 b=Xle8OazA6nNXCRhJ446EN+j3VgdzCR0IjJvd08KT9L+Teb3McnZ/mHTYrHdWKzsn1O
 C7eU+4z7gADw4WBjvJH2LO0gWBTELLRmFK0NEhTOG1GiS3qkvacqfil8cWlIBi5dQmZX
 Tw4W4JrAFcNesL844QaalCwlbpYMxL3tEc3TPNU5TGGva0sPPN2tarv4uJ9bqF+G7cUg
 c1FvA3sCRYY0biYt8UE4zAbpZSGVa75KTwy7+Aa8LL8FkBR2fJHZZ2zFxikqf+SWa3CR
 /1Y6dJ/NkwAPowDW7F5ZTUHYSzTH4pWcAz43KjI0aB+pcH2hj0XjcG8VnCTylXEHPB9B
 MxSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=mJkZyrtHfMCWNFGd7xPoeAS/el/DiFqRnTbtHnDnMBM=;
 b=xNxlAHIvuBjdPN16qdZF+Gwj4VCdkdvdi6eOknyuNWjADnubGcyeSKz3IsFolALWee
 wrOZuHsAgFBirkwDsF62bz8yV6TztoiruO7zoiZwg7e3HhesEN70ccctKlQWSxlkpNGU
 3NrSEGtOGLeS4AzPz/rPSIWg2y8lJoqxvTKACMmesp4WuxZgkkB7kEFYj/CxlmF0YzaV
 L7Z7gjq6pS9pC6+JBZ69EzBRrg2Yvhl9+tyjrhanF9aCC1AoWXQKCz3Qr8+/iFUjUPnf
 LvC8JRVYD0lRzkkN+aAv1xlsNuQYZQsx8ksjzK35l+kKMYk7qPXNWm2zlkLSeimUbvBH
 LZkg==
X-Gm-Message-State: AOAM530c+Rdk5pr5jY/60tXSpoZvF/tEQG/PBdFStMmPlAdLpEJMpTlz
 6YcBWbYdGSMlClSmhPP8wB+L1NUb5uO8kxtKBdQ=
X-Google-Smtp-Source: ABdhPJwnC673je8I0laF9c/ryj3TbN9BLR335qLXz9aZMPwsTryfI3qsCqCQSONfi+xXXdbVakrhQ7Z2mVwC8m86+dc=
X-Received: by 2002:a25:e204:0:b0:610:cb53:b753 with SMTP id
 h4-20020a25e204000000b00610cb53b753mr5037475ybe.267.1645144513827; Thu, 17
 Feb 2022 16:35:13 -0800 (PST)
MIME-Version: 1.0
References: <9Vw6LCkr2d2uOBanXeIuGxA1fUGGOeV1OHlgBifbmij1Afs0ISjfKK-vmcnRZfBG4GwJhIVLMisjvS_zohS-cW0FkzZaCKa6Mn7VWolznJs=@protonmail.com>
 <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
 <20220217143225.GB1429@erisian.com.au>
In-Reply-To: <20220217143225.GB1429@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 17 Feb 2022 19:35:01 -0500
Message-ID: <CALZpt+Hx5JoQFZ=G4gNSUo4yiP-FyZfPr2qusc9+okRoLOEpaQ@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000059d96005d8400e00"
X-Mailman-Approved-At: Fri, 18 Feb 2022 08:45:43 +0000
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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: Fri, 18 Feb 2022 00:35:17 -0000

--00000000000059d96005d8400e00
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

While I roughly agree with the thesis that different replacement policies
offer marginal block reward gains _in the current state_ of the ecosystem,
I would be more conservative about extending the conclusions to the
medium/long-term future.

> I suspect the "economically rational" choice would be to happily trade
> off that immediate loss against even a small chance of a simpler policy
> encouraging higher adoption of bitcoin, _or_ a small chance of more
> on-chain activity due to higher adoption of bitcoin protocols like
> lightning and thus a lower chance of an empty mempool in future.

This is making the assumption that the economic interests of the different
class of actors in the Bitcoin ecosystem are not only well-understood but
also aligned. We have seen in the past mining actors behaviors delaying the
adoption of protocol upgrades which were expected to encourage higher
adoption of Bitcoin. Further, if miners likely have an incentive to see an
increase of on-chain activity, there is also the possibility that lightning
will be so throughput-efficient to drain mempools backlog, to a point where
the block demand is not high enough to pay back the cost of mining hardware
and operational infrastructure. Or at least not matching the return on
mining investments expectations.

Of course, it could be argued that as a utxo-sharing protocol like
lightning just compresses the number of payments per block space unit, it
lowers the fees burden, thus making Bitcoin as a payment system far more
attractive for a wider population of users. In fine increasing the block
space demand and satisfying the miners.

In the state of today's knowledge, this hypothesis sounds the most
plausible. Though, I would say it's better to be cautious until we
understand better the interactions between the different layers of the
Bitcoin ecosystem ?

> Certainly those percentages can be expected to double every four years as
> the block reward halves (assuming we don't also reduce the min relay fee
> and block min tx fee), but I think for both miners and network stability,
> it'd be better to have the mempool backlog increase over time, which
> would both mean there's no/less need to worry about the special case of
> the mempool being empty, and give a better incentive for people to pay
> higher fees for quicker confirmations.

Intuitively, if we assume that liquidity isn't free on lightning [0], there
should be a subjective equilibrium where it's cheaper to open new channels
to reduce one's own graph traversal instead of paying too high routing fees=
.

As the core of the network should start to be more busy, I think we should
see more LN actors doing that kind of arbitrage, guaranteeing in the
long-term mempools backlog.

> If you really want to do that
> optimally, I think you have to have a mempool that retains conflicting
> txs and runs a dynamic programming solution to pick the best set, rather
> than today's simple greedy algorithms both for building the block and
> populating the mempool?

As of today, I think power efficiency of mining chips and access to
affordable sources of energy are more significant factors of the
rentability of mining operations rather than optimality of block
construction/replacement policy. IMO, making the argument that small deltas
in block reward gains aren't that much relevant.

That said, the former factors might become a commodity, and the latter one
become a competitive advantage. It could incentivize the development of
such greedy algorithms, potentially in a covert way as we have seen with
AsicBoost ?

> Is there a plausible example where the difference isn't that marginal?

The paradigm might change in the future. If we see the deployment of
channel factories/payment pools, we might have users competing to spend a
shared-utxo with different liquidity needs and thus ready to overbid. Lack
of a "conflict pool" logic might make you lose income.

> Always accepting (package/descendent) fee rate increases removes the
possibility of pinning entirely, I think

I think the pinnings we're affected with today are due to the ability of a
malicious counterparty to halt the on-chain resolution of the channel. The
presence of a  pinning commitment transaction with low-chance of
confirmation (abuse of BIP125 rule 3)
prevents the honest counterparty to fee-bump her own version of the
commitment, thus redeeming a HTLC before timelock expiration. As long as
one commitment confirms, independently of who issued it, the pinning is
over. I think moving to replace-by-feerate allows the honest counterparty
to fee-bump her commitment, thus offering a compelling block space demand,
or forces the malicious counterparty to enter in a fee race.


To gather my thinking on the subject, the replace-by-feerate policy could
produce lower fees blocks in the presence of today's environment of
empty/low-fulfilled blocks. That said, the delta sounds marginal enough
w.r.t other factors of mining business units
to not be worried (or at least low-key) about the potential implications on
centralization. If the risk is perceived as too intolerable, it could be
argued an intermediate solution would be to deploy a "dual" RBF policy
(replace-by-fee for the top of the mempool, replace-by-feerate
for the remaining part).

Still, I believe we might have to adopt more sophisticated replacement
policies in the long term to level the field among the mining ecosystem if
block construction/mempool acceptance strategies become a competitive
factor. Default to do so might provoke a latent centralization of mining
due to heterogeneity in the block reward offered. This heterogeneity would
also likely downgrade the safety of L2 nodes, as those actors wouldn't be
able to know how to format their fee-bumpings, in the lack of _a_ mempool
replacement standard.

> Note that if we did have this policy, you could abuse it to cheaply drain
> people's mempools: if there was a 300MB backlog, you could publish 2980
> 100kB txs paying a fee rate just below the next block fee, meaning you'd
> kick out the previous backlog and your transactions take up all but the
> top 2MB of the mempool; if you then replace them all with perhaps 2980
> 100B txs paying a slightly higher fee rate, the default mempool will be
> left with only 2.3MB, at an ultimate cost to you of only about 30% of a
> block in fees, and you could then fill the mempool back up by spamming
> 300MB of ultra low fee rate txs.

I believe we might have bandwidth-bleeding issues with our current
replacement policy. I think it would be good to have a cost estimate of
them and ensure a newer replacement policy would stay in the same bounds.

> I think spam prevention at the outbound relay level isn't enough to
> prevent that: an attacker could contact every public node and relay the
> txs directly, clearing out the mempool of most public nodes directly. So
> you'd want some sort of spam prevention on inbound txs too?

That we have to think about replacement spam prevention sounds reasonable
to me. I would be worried about utxo-based replacement limitations which
could be abused in the context of multi-party protocol (introducing a new
pinning vector). One solution
could be to have a per-party transaction "tag" and allocate a replacement
slot in function ? Maybe preventing a malicious counterparty to abuse a
"global" utxo slot during periods of low fees...

Antoine

[0] https://twitter.com/alexbosworth/status/1476946257939628035

Le jeu. 17 f=C3=A9vr. 2022 =C3=A0 09:32, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> On Thu, Feb 10, 2022 at 07:12:16PM -0500, Matt Corallo via bitcoin-dev
> wrote:
> > This is where *all* the complexity comes from. If our goal is to "ensur=
e
> a
> > bump increases a miner's overall revenue" (thus not wasting relay for
> > everyone else), then we precisely *do* need
> > > Special consideration for "what should be in the next
> > > block" and/or the caching of block templates seems like an imposing
> > > dependency
> > Whether a transaction increases a miner's revenue depends precisely on
> > whether the transaction (package) being replaced is in the next block -
> if
> > it is, you care about the absolute fee of the package and its
> replacement.
>
> On Thu, Feb 10, 2022 at 11:44:38PM +0000, darosior via bitcoin-dev wrote:
> > It's not that simple. As a miner, if i have less than 1vMB of
> transactions in my mempool. I don't want a 10sats/vb transaction paying
> 100000sats by a 100sats/vb transaction paying only 10000sats.
>
> Is it really true that miners do/should care about that?
>
> If you did this particular example, the miner would be losing 90k sats
> in fees, which would be at most 1.44 *millionths* of a percent of the
> block reward with the subsidy at 6.25BTC per block, even if there were
> no other transactions in the mempool. Even cumulatively, 10sats/vb over
> 1MB versus 100sats/vb over 10kB is only a 1.44% loss of block revenue.
>
> I suspect the "economically rational" choice would be to happily trade
> off that immediate loss against even a small chance of a simpler policy
> encouraging higher adoption of bitcoin, _or_ a small chance of more
> on-chain activity due to higher adoption of bitcoin protocols like
> lightning and thus a lower chance of an empty mempool in future.
>
> If the network has an "empty mempool" (say less than 2MvB-10MvB of
> backlog even if you have access to every valid 1+ sat/vB tx on any node
> connected to the network), then I don't think you'll generally have txs
> with fee rates greater than ~20 sat/vB (ie 20x the minimum fee rate),
> which means your maximum loss is about 3% of block revenue, at least
> while the block subsidy remains at 6.25BTC/block.
>
> Certainly those percentages can be expected to double every four years as
> the block reward halves (assuming we don't also reduce the min relay fee
> and block min tx fee), but I think for both miners and network stability,
> it'd be better to have the mempool backlog increase over time, which
> would both mean there's no/less need to worry about the special case of
> the mempool being empty, and give a better incentive for people to pay
> higher fees for quicker confirmations.
>
> If we accept that logic (and assuming we had some additional policy
> to prevent p2p relay spam due to replacement txs), we could make
> the mempool accept policy for replacements just be (something like)
> "[package] feerate is greater than max(descendent fee rate)", which
> seems like it'd be pretty straightforward to deal with in general?
>
>
>
> Thinking about it a little more; I think the decision as to whether
> you want to have a "100kvB at 10sat/vb" tx or a conflicting "1kvB at
> 100sat/vb" tx in your mempool if you're going to take into account
> unrelated, lower fee rate txs that are also in the mempool makes block
> building "more" of an NP-hard problem and makes the greedy solution
> we've currently got much more suboptimal -- if you really want to do that
> optimally, I think you have to have a mempool that retains conflicting
> txs and runs a dynamic programming solution to pick the best set, rather
> than today's simple greedy algorithms both for building the block and
> populating the mempool?
>
> For example, if you had two such replacements come through the network,
> a miner could want to flip from initially accepting the first replacement=
,
> to unaccepting it:
>
> Initial mempool: two big txs at 100k each, many small transactions at
> 15s/vB and 1s/vB
>
>  [100kvB at 20s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB] [1000kvB at
> 1s/vB]
>    -> 0.148 BTC for 1MvB (100*20 + 850*15 + 50*1)
>
> Replacement for the 20s/vB tx paying a higher fee rate but lower total
> fee; that's worth including:
>
>  [10kvB at 100s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB [1000kvB at 1s/v=
B]
>    -> 0.1499 BTC for 1MvB (10*100 + 850*15 + 100*12 + 40*1)
>
> Later, replacement for the 12s/vB tx comes in, also paying higher fee
> rate but lower total fee. Worth including, but only if you revert the
> original replacement:
>
>  [100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1s/v=
B]
>    -> 0.16 BTC for 1MvB (150*20 + 850*15)
>
>  [10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1s/v=
B]
>    -> 0.1484 BTC for 1MvB (10*100 + 50*20 + 850*15 + 90*1)
>
> Algorithms/mempool policies you might have, and their results with
> this example:
>
>  * current RBF rules: reject both replacements because they don't
>    increase the absolute fee, thus get the minimum block fees of
>    0.148 BTC
>
>  * reject RBF unless it increases the fee rate, and get 0.1484 BTC in
>    fees
>
>  * reject RBF if it's lower fee rate or immediately decreases the block
>    reward: so, accept the first replacement, but reject the second,
>    getting 0.1499 BTC
>
>  * only discard a conflicting tx when it pays both a lower fee rate and
>    lower absolute fees, and choose amongst conflicting txs optimally
>    via some complicated tx allocation algorithm when generating a block,
>    and get 0.16 BTC
>
> In this example, those techniques give 92.5%, 92.75%, 93.69% and 100% of
> total possible fees you could collect; and 99.813%, 99.819%, 99.84% and
> 100% of the total possible block reward at 6.25BTC/block.
>
> Is there a plausible example where the difference isn't that marginal?
> Seems like the simplest solution of just checking the (package/descendent=
)
> fee rate increases works well enough here at least.
>
> If 90kvB of unrelated txs at 14s/vB were then added to the mempool, then
> replacing both txs becomes (just barely) optimal, meaning the smartest
> possible algorithm and the dumbest one of just considering the fee rate
> produce the same result, while the others are worse:
>
>  [10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB=
]
>    -> 0.1601 BTC for 1MvB
>    (accepting both)
>
>  [100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB=
]
>    -> 0.1575 BTC for 1MvB
>    (accepting only the second replacement)
>
>  [10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/v=
B]
>    -> 0.1551 BTC for 1MvB
>    (first replacement only, optimal tx selection: 10*100, 850*15, 50*14,
> 100*12)
>
>  [100kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/v=
B]
>    -> 0.1545 BTC for 1MvB
>    (accepting neither replacement)
>
>  [10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/v=
B]
>    -> 0.1506 BTC for 1MvB
>    (first replacement only, greedy tx selection: 10*100, 850*15, 90*14,
> 50*1)
>
> Always accepting (package/descendent) fee rate increases removes the
> possibility of pinning entirely, I think -- you still have the problem
> where someone else might get a conflicting transaction confirmed first,
> but they can't get a conflicting tx stuck in the mempool without
> confirming if you're willing to pay enough to get it confirmed.
>
>
>
> Note that if we did have this policy, you could abuse it to cheaply drain
> people's mempools: if there was a 300MB backlog, you could publish 2980
> 100kB txs paying a fee rate just below the next block fee, meaning you'd
> kick out the previous backlog and your transactions take up all but the
> top 2MB of the mempool; if you then replace them all with perhaps 2980
> 100B txs paying a slightly higher fee rate, the default mempool will be
> left with only 2.3MB, at an ultimate cost to you of only about 30% of a
> block in fees, and you could then fill the mempool back up by spamming
> 300MB of ultra low fee rate txs.
>
> I think spam prevention at the outbound relay level isn't enough to
> prevent that: an attacker could contact every public node and relay the
> txs directly, clearing out the mempool of most public nodes directly. So
> you'd want some sort of spam prevention on inbound txs too?
>
> So I think you'd need to carefully think about relay spam before making
> this sort of change.  Also, if we had tx rebroadcast implemented then
> having just a few nodes with large mempools might allow the network to
> recover from this situation automatically.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">While I roughly agree with the thesis that different repla=
cement policies offer marginal block reward gains _in the current state_ of=
 the ecosystem, I would be more conservative about extending the conclusion=
s to the medium/long-term future.<br><br>&gt; I suspect the &quot;economica=
lly rational&quot; choice would be to happily trade<br>&gt; off that immedi=
ate loss against even a small chance of a simpler policy<br>&gt; encouragin=
g higher adoption of bitcoin, _or_ a small chance of more<br>&gt; on-chain =
activity due to higher adoption of bitcoin protocols like<br>&gt; lightning=
 and thus a lower chance of an empty mempool in future.<br><br>This is maki=
ng the assumption that the economic interests of the different class of act=
ors in the Bitcoin ecosystem are not only well-understood but also aligned.=
 We have seen in the past mining actors behaviors delaying the adoption of =
protocol upgrades which were expected to encourage higher adoption of Bitco=
in. Further, if miners likely have an incentive to see an increase of on-ch=
ain activity, there is also the possibility that lightning will be so throu=
ghput-efficient to drain mempools backlog, to a point where the block deman=
d is not high enough to pay back the cost of mining hardware and operationa=
l infrastructure. Or at least not matching the return on mining investments=
 expectations.<br><br>Of course, it could be argued that as a utxo-sharing =
protocol like lightning just compresses the number of payments per block sp=
ace unit, it lowers the fees burden, thus making Bitcoin as a payment syste=
m far more attractive for a wider population of users. In fine increasing t=
he block space demand and satisfying the miners.<br><br>In the state of tod=
ay&#39;s knowledge, this hypothesis sounds the most plausible. Though, I wo=
uld say it&#39;s better to be cautious until we understand better the inter=
actions between the different layers of the Bitcoin ecosystem ?<br><br>&gt;=
 Certainly those percentages can be expected to double every four years as<=
br>&gt; the block reward halves (assuming we don&#39;t also reduce the min =
relay fee<br>&gt; and block min tx fee), but I think for both miners and ne=
twork stability,<br>&gt; it&#39;d be better to have the mempool backlog inc=
rease over time, which<br>&gt; would both mean there&#39;s no/less need to =
worry about the special case of<br>&gt; the mempool being empty, and give a=
 better incentive for people to pay<br>&gt; higher fees for quicker confirm=
ations.<br><br>Intuitively, if we assume that liquidity isn&#39;t free on l=
ightning [0], there should be a subjective equilibrium where it&#39;s cheap=
er to open new channels=C2=A0 to reduce one&#39;s own graph traversal inste=
ad of paying too high routing fees.<br><br>As the core of the network shoul=
d start to be more busy, I think we should see more LN actors doing that ki=
nd of arbitrage, guaranteeing in the long-term mempools backlog.<br><br>&gt=
; If you really want to do that<br>&gt; optimally, I think you have to have=
 a mempool that retains conflicting<br>&gt; txs and runs a dynamic programm=
ing solution to pick the best set, rather<br>&gt; than today&#39;s simple g=
reedy algorithms both for building the block and<br>&gt; populating the mem=
pool?<br><br>As of today, I think power efficiency of mining chips and acce=
ss to affordable sources of energy are more significant factors of the rent=
ability of mining operations rather than optimality of block construction/r=
eplacement policy. IMO, making the argument that small deltas in block rewa=
rd gains aren&#39;t that much relevant.<br><br>That said, the former factor=
s might become a commodity, and the latter one become a competitive advanta=
ge. It could incentivize the development of such greedy algorithms, potenti=
ally in a covert way as we have seen with AsicBoost ?<br><br>&gt; Is there =
a plausible example where the difference isn&#39;t that marginal?<br><br>Th=
e paradigm might change in the future. If we see the deployment of channel =
factories/payment pools, we might have users competing to spend a shared-ut=
xo with different liquidity needs and thus ready to overbid. Lack of a &quo=
t;conflict pool&quot; logic might make you lose income.<br><br>&gt; Always =
accepting (package/descendent) fee rate increases removes the<br>possibilit=
y of pinning entirely, I think <br><br>I think the pinnings we&#39;re affec=
ted with today are due to the ability of a malicious counterparty to halt t=
he on-chain resolution of the channel. The presence of a=C2=A0 pinning comm=
itment transaction with low-chance of confirmation (abuse of BIP125 rule 3)=
<br>prevents the honest counterparty to fee-bump her own version of the com=
mitment, thus redeeming a HTLC before timelock expiration. As long as one c=
ommitment confirms, independently of who issued it, the pinning is over. I =
think moving to replace-by-feerate allows the honest counterparty to fee-bu=
mp her commitment, thus offering a compelling block space demand, or forces=
 the malicious counterparty to enter in a fee race.<br><br><br>To gather my=
 thinking on the subject, the replace-by-feerate policy could produce lower=
 fees blocks in the presence of today&#39;s environment of empty/low-fulfil=
led blocks. That said, the delta sounds marginal enough w.r.t other factors=
 of mining business units<br>to not be worried (or at least low-key) about =
the potential implications on centralization. If the risk is perceived as t=
oo intolerable, it could be argued an intermediate solution would be to dep=
loy a &quot;dual&quot; RBF policy (replace-by-fee for the top of the mempoo=
l, replace-by-feerate<br>for the remaining part).<br><br>Still, I believe w=
e might have to adopt more sophisticated replacement policies in the long t=
erm to level the field among the mining ecosystem if block construction/mem=
pool acceptance strategies become a competitive factor. Default to do so mi=
ght provoke a latent centralization of mining due to heterogeneity in the b=
lock reward offered. This heterogeneity would also likely downgrade the saf=
ety of L2 nodes, as those actors wouldn&#39;t be able to know how to format=
 their fee-bumpings, in the lack of _a_ mempool replacement standard.<br><b=
r>&gt; Note that if we did have this policy, you could abuse it to cheaply =
drain<br>&gt; people&#39;s mempools: if there was a 300MB backlog, you coul=
d publish 2980<br>&gt; 100kB txs paying a fee rate just below the next bloc=
k fee, meaning you&#39;d<br>&gt; kick out the previous backlog and your tra=
nsactions take up all but the<br>&gt; top 2MB of the mempool; if you then r=
eplace them all with perhaps 2980<br>&gt; 100B txs paying a slightly higher=
 fee rate, the default mempool will be<br>&gt; left with only 2.3MB, at an =
ultimate cost to you of only about 30% of a<br>&gt; block in fees, and you =
could then fill the mempool back up by spamming<br>&gt; 300MB of ultra low =
fee rate txs.<br><br>I believe we might have bandwidth-bleeding issues with=
 our current replacement policy. I think it would be good to have a cost es=
timate of them and ensure a newer replacement policy would stay in the same=
 bounds.<br><br>&gt; I think spam prevention at the outbound relay level is=
n&#39;t enough to<br>&gt; prevent that: an attacker could contact every pub=
lic node and relay the<br>&gt; txs directly, clearing out the mempool of mo=
st public nodes directly. So<br>&gt; you&#39;d want some sort of spam preve=
ntion on inbound txs too?<br><br>That we have to think about replacement sp=
am prevention sounds reasonable to me. I would be worried about utxo-based =
replacement limitations which could be abused in the context of multi-party=
 protocol (introducing a new pinning vector). One solution<br>could be to h=
ave a per-party transaction &quot;tag&quot; and allocate a replacement slot=
 in function ? Maybe preventing a malicious counterparty to abuse a &quot;g=
lobal&quot; utxo slot during periods of low fees...<br><br>Antoine<br><br>[=
0] <a href=3D"https://twitter.com/alexbosworth/status/1476946257939628035">=
https://twitter.com/alexbosworth/status/1476946257939628035</a><br></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
jeu. 17 f=C3=A9vr. 2022 =C3=A0=C2=A009:32, Anthony Towns via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On Thu, Feb 10, 2022 at 07:12:16PM -0500,=
 Matt Corallo via bitcoin-dev wrote:<br>
&gt; This is where *all* the complexity comes from. If our goal is to &quot=
;ensure a<br>
&gt; bump increases a miner&#39;s overall revenue&quot; (thus not wasting r=
elay for<br>
&gt; everyone else), then we precisely *do* need<br>
&gt; &gt; Special consideration for &quot;what should be in the next<br>
&gt; &gt; block&quot; and/or the caching of block templates seems like an i=
mposing<br>
&gt; &gt; dependency<br>
&gt; Whether a transaction increases a miner&#39;s revenue depends precisel=
y on<br>
&gt; whether the transaction (package) being replaced is in the next block =
- if<br>
&gt; it is, you care about the absolute fee of the package and its replacem=
ent.<br>
<br>
On Thu, Feb 10, 2022 at 11:44:38PM +0000, darosior via bitcoin-dev wrote:<b=
r>
&gt; It&#39;s not that simple. As a miner, if i have less than 1vMB of tran=
sactions in my mempool. I don&#39;t want a 10sats/vb transaction paying 100=
000sats by a 100sats/vb transaction paying only 10000sats.<br>
<br>
Is it really true that miners do/should care about that?<br>
<br>
If you did this particular example, the miner would be losing 90k sats<br>
in fees, which would be at most 1.44 *millionths* of a percent of the<br>
block reward with the subsidy at 6.25BTC per block, even if there were<br>
no other transactions in the mempool. Even cumulatively, 10sats/vb over<br>
1MB versus 100sats/vb over 10kB is only a 1.44% loss of block revenue.<br>
<br>
I suspect the &quot;economically rational&quot; choice would be to happily =
trade<br>
off that immediate loss against even a small chance of a simpler policy<br>
encouraging higher adoption of bitcoin, _or_ a small chance of more<br>
on-chain activity due to higher adoption of bitcoin protocols like<br>
lightning and thus a lower chance of an empty mempool in future.<br>
<br>
If the network has an &quot;empty mempool&quot; (say less than 2MvB-10MvB o=
f<br>
backlog even if you have access to every valid 1+ sat/vB tx on any node<br>
connected to the network), then I don&#39;t think you&#39;ll generally have=
 txs<br>
with fee rates greater than ~20 sat/vB (ie 20x the minimum fee rate),<br>
which means your maximum loss is about 3% of block revenue, at least<br>
while the block subsidy remains at 6.25BTC/block.<br>
<br>
Certainly those percentages can be expected to double every four years as<b=
r>
the block reward halves (assuming we don&#39;t also reduce the min relay fe=
e<br>
and block min tx fee), but I think for both miners and network stability,<b=
r>
it&#39;d be better to have the mempool backlog increase over time, which<br=
>
would both mean there&#39;s no/less need to worry about the special case of=
<br>
the mempool being empty, and give a better incentive for people to pay<br>
higher fees for quicker confirmations.<br>
<br>
If we accept that logic (and assuming we had some additional policy<br>
to prevent p2p relay spam due to replacement txs), we could make<br>
the mempool accept policy for replacements just be (something like)<br>
&quot;[package] feerate is greater than max(descendent fee rate)&quot;, whi=
ch<br>
seems like it&#39;d be pretty straightforward to deal with in general?<br>
<br>
<br>
<br>
Thinking about it a little more; I think the decision as to whether<br>
you want to have a &quot;100kvB at 10sat/vb&quot; tx or a conflicting &quot=
;1kvB at<br>
100sat/vb&quot; tx in your mempool if you&#39;re going to take into account=
<br>
unrelated, lower fee rate txs that are also in the mempool makes block<br>
building &quot;more&quot; of an NP-hard problem and makes the greedy soluti=
on<br>
we&#39;ve currently got much more suboptimal -- if you really want to do th=
at<br>
optimally, I think you have to have a mempool that retains conflicting<br>
txs and runs a dynamic programming solution to pick the best set, rather<br=
>
than today&#39;s simple greedy algorithms both for building the block and<b=
r>
populating the mempool?<br>
<br>
For example, if you had two such replacements come through the network,<br>
a miner could want to flip from initially accepting the first replacement,<=
br>
to unaccepting it:<br>
<br>
Initial mempool: two big txs at 100k each, many small transactions at<br>
15s/vB and 1s/vB<br>
<br>
=C2=A0[100kvB at 20s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB] [1000kvB at =
1s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.148 BTC for 1MvB (100*20 + 850*15 + 50*1)<br>
<br>
Replacement for the 20s/vB tx paying a higher fee rate but lower total<br>
fee; that&#39;s worth including:<br>
<br>
=C2=A0[10kvB at 100s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB [1000kvB at 1=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1499 BTC for 1MvB (10*100 + 850*15 + 100*12 + 40*1)<br=
>
<br>
Later, replacement for the 12s/vB tx comes in, also paying higher fee<br>
rate but lower total fee. Worth including, but only if you revert the<br>
original replacement:<br>
<br>
=C2=A0[100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.16 BTC for 1MvB (150*20 + 850*15)<br>
<br>
=C2=A0[10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1484 BTC for 1MvB (10*100 + 50*20 + 850*15 + 90*1)<br>
<br>
Algorithms/mempool policies you might have, and their results with<br>
this example:<br>
<br>
=C2=A0* current RBF rules: reject both replacements because they don&#39;t<=
br>
=C2=A0 =C2=A0increase the absolute fee, thus get the minimum block fees of<=
br>
=C2=A0 =C2=A00.148 BTC<br>
<br>
=C2=A0* reject RBF unless it increases the fee rate, and get 0.1484 BTC in<=
br>
=C2=A0 =C2=A0fees<br>
<br>
=C2=A0* reject RBF if it&#39;s lower fee rate or immediately decreases the =
block<br>
=C2=A0 =C2=A0reward: so, accept the first replacement, but reject the secon=
d,<br>
=C2=A0 =C2=A0getting 0.1499 BTC<br>
<br>
=C2=A0* only discard a conflicting tx when it pays both a lower fee rate an=
d<br>
=C2=A0 =C2=A0lower absolute fees, and choose amongst conflicting txs optima=
lly<br>
=C2=A0 =C2=A0via some complicated tx allocation algorithm when generating a=
 block,<br>
=C2=A0 =C2=A0and get 0.16 BTC<br>
<br>
In this example, those techniques give 92.5%, 92.75%, 93.69% and 100% of<br=
>
total possible fees you could collect; and 99.813%, 99.819%, 99.84% and<br>
100% of the total possible block reward at 6.25BTC/block.<br>
<br>
Is there a plausible example where the difference isn&#39;t that marginal?<=
br>
Seems like the simplest solution of just checking the (package/descendent)<=
br>
fee rate increases works well enough here at least.<br>
<br>
If 90kvB of unrelated txs at 14s/vB were then added to the mempool, then<br=
>
replacing both txs becomes (just barely) optimal, meaning the smartest<br>
possible algorithm and the dumbest one of just considering the fee rate<br>
produce the same result, while the others are worse:<br>
<br>
=C2=A0[10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s=
/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1601 BTC for 1MvB<br>
=C2=A0 =C2=A0(accepting both)<br>
<br>
=C2=A0[100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s=
/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1575 BTC for 1MvB <br>
=C2=A0 =C2=A0(accepting only the second replacement)<br>
<br>
=C2=A0[10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1551 BTC for 1MvB<br>
=C2=A0 =C2=A0(first replacement only, optimal tx selection: 10*100, 850*15,=
 50*14, 100*12)<br>
<br>
=C2=A0[100kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1545 BTC for 1MvB<br>
=C2=A0 =C2=A0(accepting neither replacement)<br>
<br>
=C2=A0[10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12=
s/vB]<br>
=C2=A0 =C2=A0-&gt; 0.1506 BTC for 1MvB <br>
=C2=A0 =C2=A0(first replacement only, greedy tx selection: 10*100, 850*15, =
90*14, 50*1)<br>
<br>
Always accepting (package/descendent) fee rate increases removes the<br>
possibility of pinning entirely, I think -- you still have the problem<br>
where someone else might get a conflicting transaction confirmed first,<br>
but they can&#39;t get a conflicting tx stuck in the mempool without<br>
confirming if you&#39;re willing to pay enough to get it confirmed.<br>
<br>
<br>
<br>
Note that if we did have this policy, you could abuse it to cheaply drain<b=
r>
people&#39;s mempools: if there was a 300MB backlog, you could publish 2980=
<br>
100kB txs paying a fee rate just below the next block fee, meaning you&#39;=
d<br>
kick out the previous backlog and your transactions take up all but the<br>
top 2MB of the mempool; if you then replace them all with perhaps 2980<br>
100B txs paying a slightly higher fee rate, the default mempool will be<br>
left with only 2.3MB, at an ultimate cost to you of only about 30% of a<br>
block in fees, and you could then fill the mempool back up by spamming<br>
300MB of ultra low fee rate txs.<br>
<br>
I think spam prevention at the outbound relay level isn&#39;t enough to<br>
prevent that: an attacker could contact every public node and relay the<br>
txs directly, clearing out the mempool of most public nodes directly. So<br=
>
you&#39;d want some sort of spam prevention on inbound txs too?<br>
<br>
So I think you&#39;d need to carefully think about relay spam before making=
<br>
this sort of change.=C2=A0 Also, if we had tx rebroadcast implemented then<=
br>
having just a few nodes with large mempools might allow the network to<br>
recover from this situation automatically.<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000059d96005d8400e00--