Date: Wed, 02 Nov 2022 15:04:58 +0000
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <f6FZEWGizm0HEqfu-CMgoj9maAHBgk1XUkniYjI81S3le2sMi8jFOMLXT3ANgmIGufJscI0--aJfXOcEFJq-9UHnixgcYlzO-kAx73ggqEI=@protonmail.com>
In-Reply-To: <Y1HG0TyuppR0uC+X@petertodd.org>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
 <Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au>
 <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com>
 <Y05PHYtrNmA0vg7U@erisian.com.au>
 <PC-7ALULc67cy0mTKzk_uj-pbCcwDoMuJQmmevzLPexK32B11vuzCusGSrx1wNCQ5YtMqfQeI1N5AmdemvfHEJNJ5VmZxAeaWS6E3tNZxIs=@protonmail.com>
 <Y1HG0TyuppR0uC+X@petertodd.org>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list


------- Original Message -------
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:


> On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:
>=20
> > > And the
> > > impression I got from the PR review club discussion more seemed like
> > > devs making assumptions about businesses rather than having talked to
> > > them (eg "[I] think there are fewer and fewer businesses who absolute=
ly
> > > cannot survive without relying on zeroconf. Or at least hope so").
> >=20
> > Even I noticed this since I don't recall the developers of the 3 main c=
oinjoin implementations that are claimed to be impacted by opt-in RBF makin=
g any remarks.
>=20
>=20
> FYI I personally asked Max Hillebrand from Wasabi about full-rbf last nig=
ht.
> He gave me permission to republish our conversation:
>=20
> > Hey, I wanted to know if you had any comments on full-rbf re: wasabi?
>=20
>=20
> Doesn't really affect us, afaik
> The cj doesn't signal rbf right now
> And I guess it's a DoS vector if any input double spent will be relayed a=
fter successful signing
> But we have way bigger / cheaper DoS vectors that don't get "exploited"
> So probably doesn't matter
> Wasabi client handles replacements / reorgs gracefully, so should be alri=
ght
> We don't yet "use" rbf in the sense of fee bumping tx, but we should / wi=
ll eventually
>=20
> I haven't asked Joinmarket yet. But the impact on their implementation sh=
ould
> be very similar.
>=20

Hi Peter,

Re: Joinmarket
Yes, it's largely as you would expect. First, we did not ever signal opt-in=
 RBF in coinjoins (it'd be nice if we had CPFP as a user-level tool in the =
wallet, to speed up low fee coinjoins, but nobody's done it).
Second, yes we have DOS vectors of the trivial kind based on non-protocol-c=
ompletion (signatures) and RBF would be another one, I don't think it chang=
es our security model at all really (coinjoins being atomic, intrinsically)=
. Nothing in the logic of the protocol relies on unconfirmed txs. Maker *ma=
y* reannounce offers when they see broadcast but it's probabilistic (depend=
s on distribution of funds in (BIP32) accounts), and they do / do not reann=
ounce anyway for various reasons (reconnections on different message channe=
ls, confirmation of a coinjoin). We should probably take a new look at it i=
f this becomes the norm but there shouldn't be any security issue.

Cheers,
AdamISZ/waxwing