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