Re: [bitcoin-dev] The Pinning & Replacement Problem Set

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Thu, Nov 02, 2023 at 08:58:36AM +0000, John Carvalho via bitcoin-dev wrote:
> Good morning,
> 
> All layers and technologies "on" Bitcoin will fail in situations where
> miners misbehave or the blocks & mempool remain consistently, overly full.
> Consider this as a "law" of Bitcoin/blockchains.
> 
> In hindsight (for you, not me) it was very unwise to start messing with
> mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought
> a fragile harmony and utility to Bitcoin, which we were lucky to have for
> as long as we could.

Replacement cycling has nothing to do with full-rbf. You are being disingenuous
by bringing up your pet topic in relation to this exploit.

In fact, in the anchor channels case, it isn't even possible for the relevant
transactions to turn BIP-125 RBF off, as the 1 block CSV delay forces RBF to be
enabled.

Note that at the moment, the largest pool - AntPool - has full-RBF enabled.
Thus we have at least 40.1% of hash power mining with full-RBF:

AntPool: 28%
Binance Pool: 7.8%
Luxor: 2.5%
BTC.com: 1.8%


Obviously, the sane thing to do is design protocols that are made secure by
clear incentives, rather than vague hopes. Thats why I proposed OP_Expire, a
solution that does not rely on any particular mempool behavior. Indeed, it's a
solution that unlike the current mitigations relying on mempools, has good
resistance to mempool sybil attacks.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]