From: Peter Todd <pete@petertodd•org>
To: John Carvalho <john@synonym•to>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] The Pinning & Replacement Problem Set
Date: Thu, 2 Nov 2023 15:42:29 +0000 [thread overview]
Message-ID: <ZUPDZTSbTBxDnlRa@petertodd.org> (raw)
In-Reply-To: <CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2023-11-02 15:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
2023-11-02 8:58 ` John Carvalho
2023-11-02 15:42 ` Peter Todd [this message]
2023-11-03 19:57 ` Antoine Riard
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=ZUPDZTSbTBxDnlRa@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@synonym$(echo .)to \
/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