📅 Original date posted:2023-02-07
🗒️ Summary of this message: Taproot/MAST spends have variable size, allowing for unfair fee extraction in multiparty transactions. Mitigations include RBF, minimum weight before signing, and a trusted coordinator.
📝 Original message:> Since Taproot (more generally any kind of MAST) spends have variable size
Isn't this the case with any arbitrary script execution? Non-taproot
P2(W)SH can also have multiple (OP_IF-gated) script branches. For example
with `<pk> CHECKSIG IF SHA256 <hash> EQUALVERIFY ENDIF`, Mallory can
initially demonstrate that she can spend with `FALSE <sig>`, then later
switch to spending with `<some large preimage> TRUE <sig>`. (or I guess
even `DROP <pk> CHECKSIG`, then just switch from DROPing a 0 length item to
a larger one)
It seems that supporting arbitrary scripts would require analyzing them and
verifying that all spend paths are acceptable, with or without Taproot/MAST.
If the goal is to only allow registering simple singlesig-encumbered UTXOs
like P2(W)PKH, the participants could be asked to prove that their P2TR
output commits to an unspendable script path [0].
shesek
[0]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_ref-23-0
On Tue, Feb 7, 2023 at 4:59 AM Yuval Kogman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> ## 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/20230207/85947d66/attachment-0001.html>;
Nadav Ivgi [ARCHIVE] /
npub1f2…ydpll
2023-06-07 23:19:25
in reply to nevent1q…rtvz
Author Public Key
npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpllPublished at
2023-06-07 23:19:25Event JSON
{
"id": "76b41068ee28f219d249387522eaabc0e05823a5563b818ddf6458a4c7389655",
"pubkey": "4a9c50edfac56c5e90e382fdea7977edd0a5a46b6be7aad0461ae0075d9d2407",
"created_at": 1686179965,
"kind": 1,
"tags": [
[
"e",
"1cb271826c48de88a6304ac8ffedd6340167a6ad4b82c11ba779c915dfc4192e",
"",
"root"
],
[
"e",
"884260541044b3de1fb47589d3071011215f5383a33b721acc6a951b8e827e80",
"",
"reply"
],
[
"p",
"b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e"
]
],
"content": "📅 Original date posted:2023-02-07\n🗒️ Summary of this message: Taproot/MAST spends have variable size, allowing for unfair fee extraction in multiparty transactions. Mitigations include RBF, minimum weight before signing, and a trusted coordinator.\n📝 Original message:\u003e Since Taproot (more generally any kind of MAST) spends have variable size\n\nIsn't this the case with any arbitrary script execution? Non-taproot\nP2(W)SH can also have multiple (OP_IF-gated) script branches. For example\nwith `\u003cpk\u003e CHECKSIG IF SHA256 \u003chash\u003e EQUALVERIFY ENDIF`, Mallory can\ninitially demonstrate that she can spend with `FALSE \u003csig\u003e`, then later\nswitch to spending with `\u003csome large preimage\u003e TRUE \u003csig\u003e`. (or I guess\neven `DROP \u003cpk\u003e CHECKSIG`, then just switch from DROPing a 0 length item to\na larger one)\n\nIt seems that supporting arbitrary scripts would require analyzing them and\nverifying that all spend paths are acceptable, with or without Taproot/MAST.\n\nIf the goal is to only allow registering simple singlesig-encumbered UTXOs\nlike P2(W)PKH, the participants could be asked to prove that their P2TR\noutput commits to an unspendable script path [0].\n\nshesek\n\n[0]\nhttps://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_ref-23-0\n\nOn Tue, Feb 7, 2023 at 4:59 AM Yuval Kogman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e ## Summary\n\u003e\n\u003e Since Taproot (more generally any kind of MAST) spends have variable size\n\u003e which\n\u003e depends on the path being used, the last such input to be signed in a\n\u003e multiparty\n\u003e transaction can always use a larger than estimated signature to unfairly\n\u003e extract\n\u003e a fee contribution from the other parties to the transaction (keeping the\n\u003e absolute fees the same and reducing the feerate for the transaction).\n\u003e\n\u003e ## Attack Scenario\n\u003e\n\u003e Alice et al wish to perform a multiparty transaction, such as a CoinJoin or\n\u003e lightning dual funding at a relatively high feerate.\n\u003e\n\u003e Mallory has a P2TR output with a large script spend path, e.g. an ordinal\n\u003e inscription commitment transaction output.\n\u003e\n\u003e Mallory registers this coin as an input into the multiparty transaction\n\u003e with a\n\u003e fee obligation calculated on the basis of a key spend. When all other\n\u003e participants have provided signatures, the script spend path can be used.\n\u003e\n\u003e Since the absolute fee amount is already committed to by the provided\n\u003e (`SIGHASH_ALL`) signatures but the total transaction weight is not,\n\u003e Mallory can\n\u003e broadcast any valid signatures up to the maximum standard weight and\n\u003e minimum\n\u003e relay fees, or in collusion with a miner, up to consensus limits.\n\u003e\n\u003e This effectively steals a fee from Alice et al, as their signatures do not\n\u003e commit to a feerate directly or indirectly.\n\u003e\n\u003e ## Mitigations\n\u003e\n\u003e ### RBF\n\u003e\n\u003e All parties could negotiate a (series of) transaction(s) ahead of time at a\n\u003e lower feerate, giving a lower bound minimum feerate that Mallory can force.\n\u003e\n\u003e ### Minimum Weight Before Signing\n\u003e\n\u003e Enforcing a minimal weight for all non-witness data in the transaction\n\u003e before\n\u003e the transaction is considered fully constructed can limit the\n\u003e effectiveness of\n\u003e this attack, since the difference between the predicted weight and the\n\u003e maximum\n\u003e weight decreases.\n\u003e\n\u003e ### Trusted Coordinator\n\u003e\n\u003e In the centralized setting if BIP-322 ownership proofs are required for\n\u003e participation and assuming the server can be trusted not to collude with\n\u003e Mallory, the server can reject signatures that do not exercise the same\n\u003e spend\n\u003e path as the ownership proof, which makes the ownership proof a commitment\n\u003e to the\n\u003e spend weight of the input.\n\u003e\n\u003e ### Reputation\n\u003e\n\u003e Multiparty protocols with publicly verifiable protocol transcripts can be\n\u003e provided as weak evidence of a history of honest participation in\n\u003e multiparty\n\u003e transactions.\n\u003e\n\u003e A ring signature from keys used in the transaction or its transcript\n\u003e committing\n\u003e to the new proposed transaction can provide weak evidence for the honesty\n\u003e of the\n\u003e peer.\n\u003e\n\u003e Such proofs are more compelling to an entity which has participated in\n\u003e (one of)\n\u003e the transcripts, or proximal transactions. Incentives are theoretically\n\u003e aligned\n\u003e if public coordinators publish these transcripts as a kind of server\n\u003e reputation.\n\u003e\n\u003e ### Increasing Costliness\n\u003e\n\u003e A minimum feerate for the previous transaction or a minimum confirmation\n\u003e age\n\u003e (coindays destroyed implies time value, analogous to fidelity bonds) can be\n\u003e required for inputs to be added, in order to make such attacks less\n\u003e lucrative\n\u003e (but there is still a positive payoff for the attacker).\n\u003e\n\u003e ### Signature Ordering\n\u003e\n\u003e Signatures from potentially exploitative inputs can be required ahead of\n\u003e legacy\n\u003e or SegWit v0 ones. The prescribed order can be determined based on\n\u003e reputation or\n\u003e costliness as described in the previous paragraphs.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/85947d66/attachment-0001.html\u003e",
"sig": "2449a2d1a007213a3c025a0fa4cde0e14b5d213c57761710b5d25d20f64c8cf267c0997a2bf7919fc3a34e3aba39d19098c47d6c4aec05d29f5daf65f34a7213"
}