From: "David A. Harding" <dave@dtrt•org>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Sergej Kotliar <sergej@bitrefill•com>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Thu, 20 Oct 2022 11:05:36 -1000 [thread overview]
Message-ID: <fd38a49c86ca11015239a2f17f5bed36@dtrt.org> (raw)
In-Reply-To: <Y1Gocf216O+yKqqS@erisian.com.au>
On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
> bitcoin-dev wrote:
>> AJ previously wrote:
>> > presumably that makes your bitcoin
>> > payments break down as something like:
>> > 5% txs are on-chain and seem shady and are excluded from zeroconf
>> > 15% txs are lightning
>> > 20% txs are on-chain but signal rbf and are excluded from zeroconf
>> > 60% txs are on-chain and seem fine for zeroconf
>> Numbers are right. [...]
>
> [...]
>
> So the above suggests 25% of payments already get a sub-par experience
> [...]
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
Is it worth considering incremental steps between opt-in only (BIP125)
and replace anything full RBF? For example, in addition to opt-in RBF
rules, treat any transaction with a txid ending in `0x1` as replacable?
I assume 1/16th (6.25%) of transactions would match that pattern (some
of which already opt-in to RBF, so the net effect would be smaller).
This would have the following advantages:
1. We could see if miners are willing to enable unsignaled RBF at all
2. We could gather more evidence on how the change affects zeroconf
businesses and everyday users, hopefully without requiring they make
immediate and huge changes
3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding
their txids, at least until full RBF is accomplished
4. We can increase the percentage of transactions subject to unsignaled
RBF in later releases of Bitcoin Core, steadily moving the system
towards full RBF without any sudden leaps (assuming nobody builds a
successful relay and mining network with less restrictive replacement
rules)
I don't think this directly helps solve the problems with non-replacable
transactions suffered by contract protocols since any adversary can
opt-out of this scheme by grinding their txid, but I do think there's an
advantage in transitioning slowly when people are still depending on
previous behaviors.
Thanks,
-Dave
next prev parent reply other threads:[~2022-10-20 21:05 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45 ` Erik Aronesty
2022-10-19 15:43 ` Jeremy Rubin
2022-10-19 15:51 ` Greg Sanders
2022-10-19 16:04 ` Sergej Kotliar
2022-10-19 16:08 ` Greg Sanders
2022-10-20 1:37 ` Antoine Riard
2022-10-20 14:11 ` Sergej Kotliar
2022-10-21 1:04 ` Antoine Riard
2022-10-20 4:05 ` Peter Todd
2022-10-21 19:35 ` Peter Todd
2022-10-20 7:22 ` Anthony Towns
2022-10-20 12:37 ` Sergej Kotliar
2022-10-20 14:14 ` Ruben Somsen
2022-10-20 14:17 ` Sergej Kotliar
2022-10-20 19:58 ` Anthony Towns
2022-10-20 21:05 ` David A. Harding [this message]
2022-10-20 21:07 ` Greg Sanders
2022-10-20 22:02 ` Eloy
2022-10-21 12:02 ` Sergej Kotliar
2022-10-21 14:01 ` Greg Sanders
2022-10-21 14:19 ` Sergej Kotliar
2022-10-21 14:47 ` Greg Sanders
2022-10-21 19:43 ` Peter Todd
2022-10-24 7:55 ` Sergej Kotliar
2022-10-20 22:13 ` Peter Todd
2022-10-21 9:34 ` Sergej Kotliar
2022-10-21 19:33 ` Peter Todd
2022-10-24 7:45 ` Sergej Kotliar
2022-10-21 11:56 ` Sergej Kotliar
2022-10-23 19:20 ` David A. Harding
2022-10-23 20:51 ` alicexbt
[not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02 6:34 ` Daniel Lipshitz
2022-12-02 1:52 ` Antoine Riard
2022-12-02 6:59 ` Daniel Lipshitz
2022-12-02 4:30 ` Peter Todd
2022-12-02 7:06 ` Daniel Lipshitz
2022-12-03 8:50 ` Peter Todd
2022-12-03 11:01 ` Daniel Lipshitz
2022-12-03 11:51 ` Daniel Lipshitz
2022-12-03 12:12 ` Peter Todd
2022-12-03 13:17 ` Daniel Lipshitz
2022-12-03 14:03 ` Daniel Lipshitz
2022-12-05 12:21 ` angus
[not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04 ` Peter Todd
2022-10-14 16:28 ` Erik Aronesty
2022-10-15 4:08 ` John Carvalho
2022-10-15 4:20 ` John Carvalho
-- strict thread matches above, loose matches on Subject: below --
2022-10-07 16:20 Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding
2022-10-07 17:28 ` Greg Sanders
2022-10-07 21:37 ` Dario Sneidermanis
2022-10-11 16:18 ` Pieter Wuille
2022-10-12 5:42 ` Anthony Towns
2022-10-12 16:11 ` Pieter Wuille
2022-10-12 21:44 ` Dario Sneidermanis
2022-10-13 4:35 ` Anthony Towns
2022-10-16 8:08 ` Anthony Towns
2022-10-17 14:25 ` Greg Sanders
2022-10-17 21:41 ` Antoine Riard
2022-10-18 7:00 ` Anthony Towns
2022-10-19 3:01 ` Antoine Riard
2022-10-19 3:17 ` alicexbt
2022-10-20 22:08 ` Peter Todd
2022-11-02 15:04 ` AdamISZ
2022-10-20 23:18 ` Peter Todd
2022-11-09 13:19 ` ArmchairCryptologist
2022-11-10 9:35 ` ZmnSCPxj
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14 2:44 ` alicexbt
2022-10-14 15:02 ` Peter Todd
2022-10-17 20:31 ` Antoine Riard
2022-10-17 22:14 ` 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=fd38a49c86ca11015239a2f17f5bed36@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sergej@bitrefill$(echo .)com \
/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