MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
 <CALZpt+E2XKmqAELcedN8-5JkCOwmEH-CN8nwmpwW74xGUZPtbA@mail.gmail.com>
In-Reply-To: <CALZpt+E2XKmqAELcedN8-5JkCOwmEH-CN8nwmpwW74xGUZPtbA@mail.gmail.com>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Fri, 10 Feb 2023 21:35:06 +0200
Message-ID: <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
 protocols with Taproot inputs
Precedence: list

On Wed, 8 Feb 2023 at 02:56, Antoine Riard <antoine.riard@gmail.com> wrote:
> From what I understand, there are many inputs for the coinjoin transaction, the latest signer provides an inflated witness downgrading the multi-party transaction feerate.

Yep!

>  It doesn't sound to me a fee siphoning as occurring with loose malleability [0], rather another case of transaction-relay jamming where the adversary's goal is to slow down the confirmation of the transaction to waste everyone timevalue.
>
> I think the issue has already been mentioned to advocate updating Core's mempool acceptance policy, and allows wtxid-replacement [1]. There is also a description available here [2].

Yep, the mechanism is basically the same as witness malleability based jamming.

Apologies for not citing, I think I must have seen that before but
only remembered the pinning variants, and so did not recall it at the
time that I wrote this up, which I did rather hastily.

However, I do think the adversary model should be broadened, as there
is a potential positive externality to a party which simply wishes to
get some witness data confirmed in a block while paying less than the
market rate, without needing to assume time sensitive contracts in the
threat model.

What I had in mind was the estimated witness size messages in the dual
funding proposal and felt they would create a false sense of
validation, specifically in the context of an adversary interested in
having their ordinal inscriptions being paid for by someone else by
subverting the a priori agreed upon feerate. From my point of view
this is primarily an argument for RBF by default (ideally full RBF, as
rule 3 of BIP 125 imposes difficult constraints on multiparty
transaction construction) in such protocols.

> I don't think increasing adversary costliness is that efficient as there is a scaling effect (e.g the feerate of the previous transaction can be used to feed N outputs for N dissociated attack contexts).

Yes, that doesn't make things incentive compatible but allows the
potential victims to have clearer bounds on the potential positive
payoff to the adversary. I think that's mainly useful in conjunction
constraining the order of signature submission, going from smallest to
largest input seems intuitively compelling but it seems to me like
ordering by feerate of creating transaction or perhaps some
combination of the two might provide a stronger deterrent.

Either way the main takeaway in my opinion is not that this is a
serious attack, as it's hard to exploit in theory and as far as I know
none of the currently deployed protocols are in any way vulnerable:

1. dual funding supports RBF and quite amenable to reputation based mitigations
2. in JoinMarket the taker can protect themselves
3. centralized coinjoins, despite misleading claims to the contrary by
both vendors, currently strongly rely on a trusted server for many
other aspects of the protocol and all three protocols are not
currently exploitable as described (the attacker can't broadcast the
transaction with a witness that would otherwise be rejected by the
server)

... but rather that (full) RBF is required for incentive compatible
multiparty transactions (or the closest approximation of incentive
compatibility possible barring future soft forks).