Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

From: Peter Todd <[email-masked]>
Date: Fri, 21 Oct 2022 15:43:33 -0400

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 <[email-masked]> 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.

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.

> 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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org