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

[AdamISZ <AdamISZ@protonmail.com>]

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


> On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:
> 
> > > 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 absolutely
> > > cannot survive without relying on zeroconf. Or at least hope so").
> > 
> > Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.
> 
> 
> FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.
> He gave me permission to republish our conversation:
> 
> > Hey, I wanted to know if you had any comments on full-rbf re: wasabi?
> 
> 
> 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 after 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 alright
> We don't yet "use" rbf in the sense of fee bumping tx, but we should / will eventually
> 
> I haven't asked Joinmarket yet. But the impact on their implementation should
> be very similar.
> 

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-completion (signatures) and RBF would be another one, I don't think it changes our security model at all really (coinjoins being atomic, intrinsically). Nothing in the logic of the protocol relies on unconfirmed txs. Maker *may* reannounce offers when they see broadcast but it's probabilistic (depends on distribution of funds in (BIP32) accounts), and they do / do not reannounce anyway for various reasons (reconnections on different message channels, confirmation of a coinjoin). We should probably take a new look at it if this becomes the norm but there shouldn't be any security issue.

Cheers,
AdamISZ/waxwing