Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)

[Peter Todd <pete@petertodd.org>]

[-- 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 --]