📅 Original date posted:2022-11-02
📝 Original message:------- Original Message -------
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev <bitcoin-dev at 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
AdamISZ [ARCHIVE] /
npub1nv…kqw2t
2023-06-07 23:16:32
in reply to nevent1q…n5k6
Author Public Key
npub1nv7tjpn2g8tvt8qfq5ccyl00ucfcu98ch998sq4g5xp65vy6fc4sykqw2tPublished at
2023-06-07 23:16:32Event JSON
{
"id": "a1c86806ca57111f314db672a80593284a0e274d22709086b48bc329f04dc91c",
"pubkey": "9b3cb9066a41d6c59c090531827defe6138e14f8b94a7802a8a183aa309a4e2b",
"created_at": 1686179792,
"kind": 1,
"tags": [
[
"e",
"74daa1302adbcb6a1e812b52c3dcb2125e87eb52aba4f3e988451888f9d45c6f",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-11-02\n📝 Original message:------- Original Message -------\nOn Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:\n\u003e \n\u003e \u003e \u003e And the\n\u003e \u003e \u003e impression I got from the PR review club discussion more seemed like\n\u003e \u003e \u003e devs making assumptions about businesses rather than having talked to\n\u003e \u003e \u003e them (eg \"[I] think there are fewer and fewer businesses who absolutely\n\u003e \u003e \u003e cannot survive without relying on zeroconf. Or at least hope so\").\n\u003e \u003e \n\u003e \u003e 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.\n\u003e \n\u003e \n\u003e FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.\n\u003e He gave me permission to republish our conversation:\n\u003e \n\u003e \u003e Hey, I wanted to know if you had any comments on full-rbf re: wasabi?\n\u003e \n\u003e \n\u003e Doesn't really affect us, afaik\n\u003e The cj doesn't signal rbf right now\n\u003e And I guess it's a DoS vector if any input double spent will be relayed after successful signing\n\u003e But we have way bigger / cheaper DoS vectors that don't get \"exploited\"\n\u003e So probably doesn't matter\n\u003e Wasabi client handles replacements / reorgs gracefully, so should be alright\n\u003e We don't yet \"use\" rbf in the sense of fee bumping tx, but we should / will eventually\n\u003e \n\u003e I haven't asked Joinmarket yet. But the impact on their implementation should\n\u003e be very similar.\n\u003e \n\nHi Peter,\n\nRe: Joinmarket\nYes, 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).\nSecond, 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.\n\nCheers,\nAdamISZ/waxwing",
"sig": "55048c0dfc39efbf64f46475014c652b75fbfbe06f0f6dae3f5cc8c2a45e086d7550e986ce5e452ec259a98f693dc12e68a83afb584536d4138be4b5f2a3bf55"
}