* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)
[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
0 siblings, 2 replies; 3+ messages in thread
From: John Carvalho @ 2022-10-17 6:23 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
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.
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.
Now RBF just kinda haunts us as the establishment keeps baking it deeper
and deeper into Bitcoin, despite almost no one using it, and despite it
having negative consequences on more popular use cases.
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?
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
[-- Attachment #2: Type: text/html, Size: 1752 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)
2022-10-17 6:23 ` [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) John Carvalho
@ 2022-10-18 13:40 ` Murch
2022-10-20 22:52 ` Peter Todd
1 sibling, 0 replies; 3+ messages in thread
From: Murch @ 2022-10-18 13:40 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1.1: Type: text/plain, Size: 1887 bytes --]
Hello John,
On 17.10.22 02:23, 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.
29% of all transactions explicitly signal replaceability (see
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/), trend
rising. If ignoring risk is an acceptable approach now, why would it no
longer work when the remaining 71% of transactions also became subject
to replaceability?
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
> Now RBF just kinda haunts us as the establishment keeps baking it deeper and deeper into Bitcoin, despite almost no one using it, and despite it having negative consequences on more popular use cases.
How can RBF at the same time be hardly used as well as an incalculable risk?
Fact of the matter is that one can neither rely on having seen all
transactions that miners are considering for their block templates, nor
that a replacement be received by the miners before the original is
picked into a block.
We're between seats: first-seen is an unstable gentlemen's agreement,
inevitable to fail eventually once a few defect. Meanwhile propping up
the illusion of "reliable payment promises" is hampering price discovery
of blockspace and complicating protocol development. By converging on
the inevitable outcome and facilitating replaceability for all
transactions, we can rip off the band-aid rather than suffer uncertainty
indefinitely—even if it requires some to honestly reassess their
business approach in light of the natural modus operandi of Bitcoin's
gossip system.
Cheers,
Murch
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 121137 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)
2022-10-17 6:23 ` [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) John Carvalho
2022-10-18 13:40 ` Murch
@ 2022-10-20 22:52 ` Peter Todd
1 sibling, 0 replies; 3+ messages in thread
From: Peter Todd @ 2022-10-20 22:52 UTC (permalink / raw)
To: John Carvalho, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-10-20 22:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.34559.1665948998.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-17 6:23 ` [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) John Carvalho
2022-10-18 13:40 ` Murch
2022-10-20 22:52 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox