Hi Yuval,
> Since the absolute fee amount is already committed to by the provided > (`SIGHASH_ALL`) signatures but the total transaction weight is not, Mallory can > broadcast any valid signatures up to the maximum standard weight and minimum > relay fees, or in collusion with a miner, up to consensus limits. > > This effectively steals a fee from Alice et al, as their signatures do not > commit to a feerate directly or indirectly. >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. 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]. To mitigate, among the peer-to-peer style of mitigations, one is of course a reputation strategy or monetary strategy, where the asymmetries in counterparties reputation are compensated with out-of-band fees/credentials. 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). Signature ordering supposes also a reputation basis, and it doesn't exclude giving a transaction construction edge to the reputational counterparty (e.g a LSP "promising" a dual-funding UTXO to X distinct participant, picking up the first to yield back a signature). Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html [1] https://github.com/bitcoin/bitcoin/pull/19645 [2] https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af#witness-malleability Le mar. 7 févr. 2023 à 02:59, Yuval Kogman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > ## Summary > > Since Taproot (more generally any kind of MAST) spends have variable size > which > depends on the path being used, the last such input to be signed in a > multiparty > transaction can always use a larger than estimated signature to unfairly > extract > a fee contribution from the other parties to the transaction (keeping the > absolute fees the same and reducing the feerate for the transaction). > > ## Attack Scenario > > Alice et al wish to perform a multiparty transaction, such as a CoinJoin or > lightning dual funding at a relatively high feerate. > > Mallory has a P2TR output with a large script spend path, e.g. an ordinal > inscription commitment transaction output. > > Mallory registers this coin as an input into the multiparty transaction > with a > fee obligation calculated on the basis of a key spend. When all other > participants have provided signatures, the script spend path can be used. > > Since the absolute fee amount is already committed to by the provided > (`SIGHASH_ALL`) signatures but the total transaction weight is not, > Mallory can > broadcast any valid signatures up to the maximum standard weight and > minimum > relay fees, or in collusion with a miner, up to consensus limits. > > This effectively steals a fee from Alice et al, as their signatures do not > commit to a feerate directly or indirectly. > > ## Mitigations > > ### RBF > > All parties could negotiate a (series of) transaction(s) ahead of time at a > lower feerate, giving a lower bound minimum feerate that Mallory can force. > > ### Minimum Weight Before Signing > > Enforcing a minimal weight for all non-witness data in the transaction > before > the transaction is considered fully constructed can limit the > effectiveness of > this attack, since the difference between the predicted weight and the > maximum > weight decreases. > > ### Trusted Coordinator > > In the centralized setting if BIP-322 ownership proofs are required for > participation and assuming the server can be trusted not to collude with > Mallory, the server can reject signatures that do not exercise the same > spend > path as the ownership proof, which makes the ownership proof a commitment > to the > spend weight of the input. > > ### Reputation > > Multiparty protocols with publicly verifiable protocol transcripts can be > provided as weak evidence of a history of honest participation in > multiparty > transactions. > > A ring signature from keys used in the transaction or its transcript > committing > to the new proposed transaction can provide weak evidence for the honesty > of the > peer. > > Such proofs are more compelling to an entity which has participated in > (one of) > the transcripts, or proximal transactions. Incentives are theoretically > aligned > if public coordinators publish these transcripts as a kind of server > reputation. > > ### Increasing Costliness > > A minimum feerate for the previous transaction or a minimum confirmation > age > (coindays destroyed implies time value, analogous to fidelity bonds) can be > required for inputs to be added, in order to make such attacks less > lucrative > (but there is still a positive payoff for the attacker). > > ### Signature Ordering > > Signatures from potentially exploitative inputs can be required ahead of > legacy > or SegWit v0 ones. The prescribed order can be determined based on > reputation or > costliness as described in the previous paragraphs. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
