From: Peter Todd <pete@petertodd•org>
To: John Carvalho <john@synonym•to>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)
Date: Thu, 20 Oct 2022 18:52:03 -0400 [thread overview]
Message-ID: <Y1HRE5ybTrQZWg6F@petertodd.org> (raw)
In-Reply-To: <CAHTn92zSBHQAf=i--+dwhWHEX3U9pQPN5uc5ryGkbEb3R3H8Gw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wrote:
> Simply, 0conf acceptance can be monitored and enforced by the merchant and
> exposure to doublespends can be both mitigated and limited in size per
> block. It is less expensive to be double-spent occasionally than to have a
> delayed checkout experience. Responsible 0conf acceptance is both rational
> and trusting.
>
> RBF assurances are optionally enforced by miners, and can be assisted by
> node mempool policies. It is not reliable to expect replaceable payments to
> be enforced in a system designed to enforce integrity of payments. RBF is
> both irrational and trusting.
My OpenTimestamps calendars all use RBF for optimal fee discovery. The fact is,
about 95% of OTS transactions mined are replacements rather than originals. I
also took a quick look, and found examples of replacements mined by Foundry
USA, AntPool, F2Pool, Binance Pool, ViaBTC, SlushPool, Luxor, MARA Pool, and
Poolin. That's at least 97.21% of all hashing power supporting opt-in RBF.
Are you claiming that almost all hashing power is irrational?
> RBF is a whim of a feature where engineers made the mistake of thinking a
> hack that basically incentivizes rollbacks and uncertainty might be useful
> because we can pretend Bitcoin has an undo button, and we can pretend to
> game the fee market by low-balling rates until txns get in.
Electrum *literally* has an undo button, implemented with RBF. I've used it a
half dozen times, and it's worked every time.
> Miners serve full nodes. What is more likely, a node set that prefers
> blocks with replaced txns, or a node set that rejects blocks with replaced
> txns?
Has anyone _ever_ implemented a node that rejects blocks containing
double-spends? I don't believe the code to reject such blocks even exists. Note
that it should: that's a terrible idea that could lead to sever consensus
problems.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2022-10-20 22:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.34559.1665948998.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-17 6:23 ` John Carvalho
2022-10-18 13:40 ` Murch
2022-10-20 22:52 ` Peter Todd [this message]
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=Y1HRE5ybTrQZWg6F@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