Skip to content

Instantly share code, notes, and snippets.

@nothingmuch
Last active February 7, 2023 14:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nothingmuch/a6ce459475a527a0e51f0600e354ef0e to your computer and use it in GitHub Desktop.
Save nothingmuch/a6ce459475a527a0e51f0600e354ef0e to your computer and use it in GitHub Desktop.
An attack on multiparty protocols that can make some SegWit v1 inputs unfairly cheap

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 witness 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 witness 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 MAX_STANDARD_TX_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 witnesses 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment