From: Sergej Kotliar <sergej@bitrefill•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>,
Greg Sanders <gsanders87@gmail•com>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Mon, 24 Oct 2022 09:55:59 +0200 [thread overview]
Message-ID: <CABZBVTBXwTKyVcnaMRxK1_VW7FzS285fUDEgEz+UQ8CJJ2ZZAw@mail.gmail.com> (raw)
In-Reply-To: <Y1L2ZSklbwm41f4u@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]
On Fri, 21 Oct 2022 at 21:43, Peter Todd <pete@petertodd•org> wrote:
> On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail•com> wrote:
> >
> > > A large number of coins/users sit on custodial rails and this would
> > > essentially encumber protocol developers to those KYC/AML
> institutions. If
> > > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> > > should this be an issue at all for reasoning about a path forward?
> > >
> >
> > This is a big question here, with the caveat that it's not just binance
> but
> > in fact the majority of wallets and services that people use with bitcoin
> > today.
> > But the question remains as you phrased: At which point do we break
> > backwards compatibility? Another analogy would be to have sunset the old
> > P2PKH addresses during rollout of Segwit - it would certainly have led to
> > Segwit getting rolled out faster. The rbf change actually breaks more
> > things than that, takes more effort to address than just implementing a
> new
> > address format. Previously in the Bitcoin Core process we've chosen to
> keep
>
> RBF certainly does not break more things than depreciating an entire
> address
> standard. P2PKH addresses are still used by old wallets, and it's often not
> worth the risk to upgrade to new software for old coins kept offline by
> ordinary users. I personally have used P2PKH addresses in the past few
> months.
>
> Zeroconf on the other hand has never worked reliably, so you can't even
> claim
> it's a "supported feature". And the fact is, it breaks all the time because
> every time miners change their acceptance rules - eg with new releases - we
> break it every single time we do a new release with different you can
> easily
> exploit zeroconf.
>
Haven't heard of any release breaking zeroconf. I would absolutely say it's
working reliably.
> Frankly, the fact that we didn't widely implement full-rbf sooner is quite
> unfortunate, as Bitrefill, Muun, etc. should have never been using it in
> the
> first place.
>
You make it sound like we're the odd ones out when it's in fact ~every
service that lets you buy stuff with bitcoin. It's just that we're the only
ones raising voices on the mailing list so far. On the contrary side, can
you name one service that lets you buy stuff with bitcoin that doesn't rely
on zeroconf? Maybe with the caveat that it should have some level of scale
and an audience not consisting of only power users.
> > If a majority of bitcoin wallets and services continue using legacy
> > patterns and features, preventing progress, at which point do we want to
> > break compatibility with them?
>
> It's clearly false to claim that the "majority of bitcoin wallets and
> services"
> are using zeroconf. A tiny minority are attempting to use it, with the vast
> majority of previous users having given up on it.
>
I didn't claim that. But it's definitely true that the vast majority of
wallets and services do not allow users to do RBF. This is easy to validate
as the list of wallets with RBF support is short), the list of exchanges
with RBF support is zero.
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/
29% of txs signal RBF, meaning 71% do not. And let's be honest, it's not
like the majority of those were given a choice and chose not to, for the
majority their wallet just doesn't support RBF.
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
Sergej Kotliar
CEO
Twitter: @ziggamon <https://twitter.com/ziggamon>
www.bitrefill.com
Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
[-- Attachment #2: Type: text/html, Size: 9027 bytes --]
next prev parent reply other threads:[~2022-10-24 7:56 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
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 [this message]
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=CABZBVTBXwTKyVcnaMRxK1_VW7FzS285fUDEgEz+UQ8CJJ2ZZAw@mail.gmail.com \
--to=sergej@bitrefill$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/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