Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-07 🗒️ Summary of this message: An attacker can ...
📅 Original date posted:2023-02-07
🗒️ Summary of this message: An attacker can unfairly extract a fee contribution from other parties in a multiparty transaction by using an inflated signature. This can be mitigated through reputation or monetary strategies.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/2fb22540/attachment-0001.html>;
🗒️ Summary of this message: An attacker can unfairly extract a fee contribution from other parties in a multiparty transaction by using an inflated signature. This can be mitigated through reputation or monetary strategies.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/2fb22540/attachment-0001.html>;