Feedback-ID: i525146e8:Fastmail
Date: Tue, 13 Dec 2022 16:41:44 -0500
From: Peter Todd <pete@petertodd.org>
To: Daniel Lipshitz <daniel@gap600.com>
Message-ID: <Y5jxmItJIpIUVY+x@petertodd.org>
References: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com>
 <CAAQdECAspoRJRz7j1ubAe=Cen==AVF5bm-Q2=0TiKc7NtbU65A@mail.gmail.com>
 <CACkWPs_4pjTo50=S86KPEznBs0PU7rd30rBGHq2Q5=6n6hYMgQ@mail.gmail.com>
 <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
 <CACkWPs9VawCYt7maiNqzafkFnHTiGJQkXMT4VXQQcG-rE2TTNw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="pfXsSGTCPVXVKpPF"
Content-Disposition: inline
In-Reply-To: <CACkWPs9VawCYt7maiNqzafkFnHTiGJQkXMT4VXQQcG-rE2TTNw@mail.gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf
 use case
Precedence: list


--pfXsSGTCPVXVKpPF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> I dont think there was anything technical with the implementation and as
> far as I can tell this is well developed and ready.

There are lots of problems with my first-seen-safe proposal. The only reaso=
n I
proposed it in 2015 was as a political compromise.

> The reasons I can find for not being adopted are listed here -
> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
> Replace-by-fee
>=20
>  Those reasons do not seem pertinent here - given OptinRBF already exists
> as an option and the added benefit of continuing to be able to support
> 0-conf.

First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
merged into Bitcoin Core: multi-party transactions.

With multi-party transactions such as coinjoins and multi-party lightning
channels, we want full-rbf behavior because it avoids accidental double-spe=
nds
holding up progress in these protocols. Second, for intentional DoS attacks=
, it
makes those attacks much more expensive by forcing the attacker to use
tx-pinning.

Nothing less than full-rbf without restritions on outputs works for this
use-case. The only compromise possible is Antoine Riard's spent-nVersion
signalling proposal=C2=B9, which has a significant, negative, privacy impac=
t=C2=B2. It
also increases costs and time in many cases, as you often have to create new
outputs to flag full-rbf.

Thus we have a political tradeoff between a handful of centralized services
such as yours that benefit from the first-seen status quo, and the much lar=
ger
group of users that use Lightning and coinjoins. We've already been through
such a political tradeoff before with the blocksize debate - again, the
centralized payment providers lost the debate.


Anyway, my advice to you is to either change your business model to make us=
e of
scalable instant payment tech such as Lightning. Or give up on Bitcoin and
expand your business with other chians, such as BSV=C2=B3. The fact is some=
 hashing
power is already beginning to run with full-rbf=E2=81=B4, and I fully expec=
t that % to
increase over time.

1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02=
1144.html
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/02=
1250.html
3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/02=
1260.html

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

--pfXsSGTCPVXVKpPF
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOY8ZUACgkQLly11TVR
Lzc86Q//UYEMcptXaourIDm1oQ+8kJDL4JZWvnGwu/O0rKoCjkLt+bKKf/QfYzQo
kcb9jTVNzggnwdFhiTaXwjMDpO3nbqChVV3BOlDJNswlDmCJu7KDrVrFA7D4LUS9
64XEgfmlOiZGrIrBtIfgikmGYdCICItJUedqJflUlcNwUZPome21ifyJHnpeQRe1
ZpkiRaoUBgmM45bhwiN/YQsPpgBd8u1TnAD2XeKN4bVK3oFUWC9ydRl9pUKlDshi
auxzntKgzSVg9mAHp0qHSS6Ps2bguE1rdaMSZdWnaKj6RFafxhxq5pP860ZmMQGx
SZXIHpFyJ+Y38jcAdIVzJDbASKny7WhPH+zKE04+4yXMwHZaXMg5htrB8ofu1Lk+
lut3APuOyhcfaROU/TDfR9r5QInhW+HvO9ca5xLLXxztcczC7K8CzgEFrpJm1kVj
s0hJH6Lpiv51I02aNPw4o/n3os4cKrOvwNhfJxqEBa04aK6OJYf9Rcwlz8iBhJdF
0z10JxyIQz4417oTY+1SvDjxI+PsSP/lIJ+nbGac1X5Cz9fqa2Sq/N22TKJEK6w9
7mxCFT41LkrR8vCDvCZiAtF5nXo5rETnRzs9EtM87pix5ZFhjePFD8LMARLX+/8s
wWwdHSO7J8+xUQQzqg073KJtro4fkU3YU/JrkzN66k8pjTeuzyo=
=gOFH
-----END PGP SIGNATURE-----

--pfXsSGTCPVXVKpPF--