[bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Yuval Kogman]

## 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.

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Lloyd Fournier]

[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]

Hi Yuval,

This is an interesting attack. Usually I think of spending with a big
weight witness in the context of slowing down a confirmation of a
transaction, especially a DLC creation tx. There you can delay its
confirmation past some time (i.e. see if your team won the game, and then
either trying to confirm it by providing the slimmed down witness or double
cancelling it by double spending). In this case you are not trying to delay
it but to dilute your portion of the fee.

Another mitigation is to aggresively RBF double spend your input any time a
counterparty doesn't use the spending path they said they would and don't
deal with them again. Of course, various pinning attacks may prevent this
depending on how your joint tx is structured.

LL

On Tue, 7 Feb 2023 at 13:59, Yuval Kogman via bitcoin-dev <
bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5290 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

> 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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5685 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Tue, Feb 07, 2023 at 11:36:58AM +0200, Nadav Ivgi via bitcoin-dev wrote:
> > Since Taproot (more generally any kind of MAST) spends have variable size
> 
> Isn't this the case with any arbitrary script execution? Non-taproot

This is even been true for P2PKH inputs: you can double the space of your
scriptSigs by using uncompressed pubkeys instead of compressed pubkeys.

> 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].

Technically, only the last person to sign needs to prove this in advance.
Everyone else can prove it with their signatures.

This distinction could be useful to support coinjoin participants spending
complex P2TR outputs into coinjoins, a perfectly valid use-case in theory so
long as they're paying appropriate fees. Though due to how difficult it is to
validate scripts reliably outside the consensus code base, allowing this for
arbitrary scripts could lead to DoS attacks where someone takes advantage of a
bug in script execution to create an invalid transaction.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]

On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrote:
> 
> 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).
>

Using Miniscript [1] it is possible for all participants to determine
the maximum witness size of the tree, which can bound the size of this
attack. In fact, they can bound the size *given that their own signature
is used*, or subject to other whatever other conditions they would like,
and only sign under those conditions.

Furthermore, under Taproot individual signatures have a maximum size of
65 bytes; an "attacker" can reduce this to 64 by not including a sighash
flag, but he has one byte of play. (Pre-Taproot signatures could take up
to 73 bytes with significant room to reduce this by using crypto tricks
and/or grinding).

Peter Todd also suggests in this thread that the use of uncompressed
keys can cause "surprise" witness inflation, but (a) since segwit
uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in
Taproot), and (b) we expect users of Miniscript to always know all the
keys used in a script that they're signing. Except perhaps in obscure
cases where, say, the "victim" is a somewhat passive countersigner of
a transaction, e.g. BitGo, ... in which case they're not the one putting
up fees or with an interest in the transaction going through.


With Miniscript, the problem is narrower:

* There is some more-expensive branch that could be taken without
  Alice's signature. In which case Alice is only signing at all to
  optimistically reduce the witness size... but she cannot assume
  that she is going to be successful!

  Notably, in this case Alice does not really have any interest in the
  coins, in the sense that they can move entirely without her consent,
  so it's hard to imagine that she has an interest in the transaction's
  speedy confirmation.

* There is some more-expensive branch that could be taken by moving
  Alice's signature. This is the case that you identify in the thread.

While the attack remains in both cases, fortunately Miniscript gives
Alice the tools to (a) determine which, if any, case applies to the
script under question, and (b) determine what the maximum witness size
might be, and just sign assuming that, treating any savings as "bonus".



[1] https://bitcoin.sipa.be/miniscript/
[2] In Taproot, if you want to prevent signatures migrating to another
    branch or within a branch, you can use the CODESEPARATOR opcode
    which was redisegned in Taproot for exactly this purpose... we
    really did about witness malleation in its design!

    If you want to prevent signatures from moving around *within* a
    branch,

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]


Some people highlighted some minor problems with my last email:

On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> 
> <snip> 
> 
> [1] https://bitcoin.sipa.be/miniscript/
> [2] In Taproot, if you want to prevent signatures migrating to another
>     branch or within a branch, you can use the CODESEPARATOR opcode
>     which was redisegned in Taproot for exactly this purpose... we
>     really did about witness malleation in its design!

In Taproot the tapleaf hash is always covered by the signature (though
not in some ANYONECANPAY proposals) so you can never migrate signatures
between tapbranches.

I had thought this was the case, but then I re-confused myself by
reading BIP 341 .... which has much of the sighash specified, but not
all of it! The tapleaf hash is added in BIP 342.

> 
>     If you want to prevent signatures from moving around *within* a
>     branch,
>

And this sentence I just meant to delete :)


-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.

The countermeasure is that you should always know the entire Taptree when
interacting with someone's Tapspend.


On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Some people highlighted some minor problems with my last email:
>
> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
> wrote:
> >
> > <snip>
> >
> > [1] https://bitcoin.sipa.be/miniscript/
> > [2] In Taproot, if you want to prevent signatures migrating to another
> >     branch or within a branch, you can use the CODESEPARATOR opcode
> >     which was redisegned in Taproot for exactly this purpose... we
> >     really did about witness malleation in its design!
>
> In Taproot the tapleaf hash is always covered by the signature (though
> not in some ANYONECANPAY proposals) so you can never migrate signatures
> between tapbranches.
>
> I had thought this was the case, but then I re-confused myself by
> reading BIP 341 .... which has much of the sighash specified, but not
> all of it! The tapleaf hash is added in BIP 342.
>
> >
> >     If you want to prevent signatures from moving around *within* a
> >     branch,
> >
>
> And this sentence I just meant to delete :)
>
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
>     -Justin Lewis-Webster
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2782 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Tue, Feb 07, 2023 at 01:35:12PM -0500, Russell O'Connor via bitcoin-dev wrote:
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
> 
> The countermeasure is that you should always know the entire Taptree when
> interacting with someone's Tapspend.

Another countermeasure could be to implement RBF on taproot witnesses, allowing
transactions with deeper, less efficient, tapleaf scripts to be replaced with
shallower, more efficient, tapleafs. If implemented by giving your peer some
kind of delta encoded update, the bandwidth efficiency may be sufficient to
always allow such updates.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

Hi Andrew

> There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates.
>> The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend.

I wouldn't say it is a "bug" unless there is a remedy for the bug that wasn't (and retrospectively should have been) included in the Taproot design. In retrospect and assuming you could redesign the Taproot consensus rules again today would you prevent spending from a valid P2TR address if a repeated Tapleaf hash was used to prove that a spending path was embedded in a Taproot tree? That's the only thing I can think of to attempt to remedy this "bug" and it would only be a partial protection as proving a spending path exists within a Taproot tree only requires a subset of the Tapleaf hashes.

I only point this out because there seems to be a push to find "bugs" and "accidental blowups" in the Taproot design currently. No problem with this if there are any, they should definitely be highlighted and discussed if they do exist. The nearest to a possible inferior design decision thus far that I'm aware of is x-only pubkeys in BIP340 [0].

Thanks
Michael

[0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend.
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>>>
>>> <snip>
>>>
>>> [1] https://bitcoin.sipa.be/miniscript/
>>> [2] In Taproot, if you want to prevent signatures migrating to another
>>> branch or within a branch, you can use the CODESEPARATOR opcode
>>> which was redisegned in Taproot for exactly this purpose... we
>>> really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341 .... which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>>>
>>> If you want to prevent signatures from moving around *within* a
>>> branch,
>>>
>>
>> And this sentence I just meant to delete :)
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 8042 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

On Wed, Feb 08, 2023 at 09:34:57AM +0000, Michael Folkson wrote:
> Hi Andrew
> 
> > There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates.
> >> The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend.
> 
> I wouldn't say it is a "bug" unless there is a remedy for the bug that wasn't (and retrospectively should have been) included in the Taproot design. In retrospect and assuming you could redesign the Taproot consensus rules again today would you prevent spending from a valid P2TR address if a repeated Tapleaf hash was used to prove that a spending path was embedded in a Taproot tree? That's the only thing I can think of to attempt to remedy this "bug" and it would only be a partial protection as proving a spending path exists within a Taproot tree only requires a subset of the Tapleaf hashes.
> 
> I only point this out because there seems to be a push to find "bugs" and "accidental blowups" in the Taproot design currently. No problem with this if there are any, they should definitely be highlighted and discussed if they do exist. The nearest to a possible inferior design decision thus far that I'm aware of is x-only pubkeys in BIP340 [0].
> 

I'm actually not certain what Russell's referring to, but if it's indeed
possible to construct TapTrees where the "same" leafhash appears multiple
times at different heights, that's something unintended and which we
could've fixed by changing the Merkle structure. I don't even think
there would've been an efficiency tradeoff.

So I think it's totally reasonable to call such a thing a "bug".

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 3759 bytes --]

The fix for the bug is to sign the entire tapbranch instead of the tapleaf.

On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <michaelfolkson@protonmail.com>
wrote:

> Hi Andrew
>
> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
> >
> > The countermeasure is that you should always know the entire Taptree
> when interacting with someone's Tapspend.
>
> I wouldn't say it is a "bug" unless there is a remedy for the bug that
> wasn't (and retrospectively should have been) included in the Taproot
> design. In retrospect and assuming you could redesign the Taproot consensus
> rules again today would you prevent spending from a valid P2TR address if a
> repeated Tapleaf hash was used to prove that a spending path was embedded
> in a Taproot tree? That's the only thing I can think of to attempt to
> remedy this "bug" and it would only be a partial protection as proving a
> spending path exists within a Taproot tree only requires a subset of the
> Tapleaf hashes.
>
> I only point this out because there seems to be a push to find "bugs" and
> "accidental blowups" in the Taproot design currently. No problem with this
> if there are any, they should definitely be highlighted and discussed if
> they do exist. The nearest to a possible inferior design decision thus far
> that I'm aware of is x-only pubkeys in BIP340 [0].
>
> Thanks
> Michael
>
> [0]:
> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when
> interacting with someone's Tapspend.
>
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
>> wrote:
>> >
>> > <snip>
>> >
>> > [1] https://bitcoin.sipa.be/miniscript/
>> > [2] In Taproot, if you want to prevent signatures migrating to another
>> > branch or within a branch, you can use the CODESEPARATOR opcode
>> > which was redisegned in Taproot for exactly this purpose... we
>> > really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341 .... which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>> >
>> > If you want to prevent signatures from moving around *within* a
>> > branch,
>> >
>>
>> And this sentence I just meant to delete :)
>>
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 8435 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Anthony Towns]

On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>The fix for the bug is to sign the entire tapbranch instead of the tapleaf.
>
>On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <michaelfolkson@protonmail.com>
>wrote:
>
>> Hi Andrew
>>
>> > There is a bug in Taproot that allows the same Tapleaf to be repeated
>> multiple times in the same Taproot, potentially at different Taplevels
>> incurring different Tapfee rates.
>> >
>> > The countermeasure is that you should always know the entire Taptree
>> when interacting with someone's Tapspend.
>>
>> I wouldn't say it is a "bug" unless there is a remedy for the bug that
>> wasn't (and retrospectively should have been) included in the Taproot
>> design. In retrospect and assuming you could redesign the Taproot consensus
>> rules again today would you prevent spending from a valid P2TR address if a
>> repeated Tapleaf hash was used to prove that a spending path was embedded
>> in a Taproot tree? That's the only thing I can think of to attempt to
>> remedy this "bug" and it would only be a partial protection as proving a
>> spending path exists within a Taproot tree only requires a subset of the
>> Tapleaf hashes.
>>
>> I only point this out because there seems to be a push to find "bugs" and
>> "accidental blowups" in the Taproot design currently. No problem with this
>> if there are any, they should definitely be highlighted and discussed if
>> they do exist. The nearest to a possible inferior design decision thus far
>> that I'm aware of is x-only pubkeys in BIP340 [0].
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> There is a bug in Taproot that allows the same Tapleaf to be repeated
>> multiple times in the same Taproot, potentially at different Taplevels
>> incurring different Tapfee rates.
>>
>> The countermeasure is that you should always know the entire Taptree when
>> interacting with someone's Tapspend.
>>
>>
>> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> Some people highlighted some minor problems with my last email:
>>>
>>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
>>> wrote:
>>> >
>>> > <snip>
>>> >
>>> > [1] https://bitcoin.sipa.be/miniscript/
>>> > [2] In Taproot, if you want to prevent signatures migrating to another
>>> > branch or within a branch, you can use the CODESEPARATOR opcode
>>> > which was redisegned in Taproot for exactly this purpose... we
>>> > really did about witness malleation in its design!
>>>
>>> In Taproot the tapleaf hash is always covered by the signature (though
>>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>>> between tapbranches.
>>>
>>> I had thought this was the case, but then I re-confused myself by
>>> reading BIP 341 .... which has much of the sighash specified, but not
>>> all of it! The tapleaf hash is added in BIP 342.
>>>
>>> >
>>> > If you want to prevent signatures from moving around *within* a
>>> > branch,
>>> >
>>>
>>> And this sentence I just meant to delete :)
>>>
>>>
>>> --
>>> Andrew Poelstra
>>> Director of Research, Blockstream
>>> Email: apoelstra at wpsoftware.net
>>> Web: https://www.wpsoftware.net/andrew
>>>
>>> The sun is always shining in space
>>> -Justin Lewis-Webster
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>

Is this something that should be fixed in bip118 signatures then?

Cheers,
aj
-- 
Sent from my phone.

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 4516 bytes --]

Yes.  If you would otherwise sign the tapleaf, then I would recommend also
signing the entire tapbranch.



On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns <aj@erisian.com.au> wrote:

> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >The fix for the bug is to sign the entire tapbranch instead of the
> tapleaf.
> >
> >On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <
> michaelfolkson@protonmail.com>
> >wrote:
> >
> >> Hi Andrew
> >>
> >> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> >> multiple times in the same Taproot, potentially at different Taplevels
> >> incurring different Tapfee rates.
> >> >
> >> > The countermeasure is that you should always know the entire Taptree
> >> when interacting with someone's Tapspend.
> >>
> >> I wouldn't say it is a "bug" unless there is a remedy for the bug that
> >> wasn't (and retrospectively should have been) included in the Taproot
> >> design. In retrospect and assuming you could redesign the Taproot
> consensus
> >> rules again today would you prevent spending from a valid P2TR address
> if a
> >> repeated Tapleaf hash was used to prove that a spending path was
> embedded
> >> in a Taproot tree? That's the only thing I can think of to attempt to
> >> remedy this "bug" and it would only be a partial protection as proving a
> >> spending path exists within a Taproot tree only requires a subset of the
> >> Tapleaf hashes.
> >>
> >> I only point this out because there seems to be a push to find "bugs"
> and
> >> "accidental blowups" in the Taproot design currently. No problem with
> this
> >> if there are any, they should definitely be highlighted and discussed if
> >> they do exist. The nearest to a possible inferior design decision thus
> far
> >> that I'm aware of is x-only pubkeys in BIP340 [0].
> >>
> >> Thanks
> >> Michael
> >>
> >> [0]:
> >>
> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
> >>
> >> --
> >> Michael Folkson
> >> Email: michaelfolkson at protonmail.com
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >>
> >> ------- Original Message -------
> >> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via
> bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> There is a bug in Taproot that allows the same Tapleaf to be repeated
> >> multiple times in the same Taproot, potentially at different Taplevels
> >> incurring different Tapfee rates.
> >>
> >> The countermeasure is that you should always know the entire Taptree
> when
> >> interacting with someone's Tapspend.
> >>
> >>
> >> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >>>
> >>> Some people highlighted some minor problems with my last email:
> >>>
> >>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via
> bitcoin-dev
> >>> wrote:
> >>> >
> >>> > <snip>
> >>> >
> >>> > [1] https://bitcoin.sipa.be/miniscript/
> >>> > [2] In Taproot, if you want to prevent signatures migrating to
> another
> >>> > branch or within a branch, you can use the CODESEPARATOR opcode
> >>> > which was redisegned in Taproot for exactly this purpose... we
> >>> > really did about witness malleation in its design!
> >>>
> >>> In Taproot the tapleaf hash is always covered by the signature (though
> >>> not in some ANYONECANPAY proposals) so you can never migrate signatures
> >>> between tapbranches.
> >>>
> >>> I had thought this was the case, but then I re-confused myself by
> >>> reading BIP 341 .... which has much of the sighash specified, but not
> >>> all of it! The tapleaf hash is added in BIP 342.
> >>>
> >>> >
> >>> > If you want to prevent signatures from moving around *within* a
> >>> > branch,
> >>> >
> >>>
> >>> And this sentence I just meant to delete :)
> >>>
> >>>
> >>> --
> >>> Andrew Poelstra
> >>> Director of Research, Blockstream
> >>> Email: apoelstra at wpsoftware.net
> >>> Web: https://www.wpsoftware.net/andrew
> >>>
> >>> The sun is always shining in space
> >>> -Justin Lewis-Webster
> >>>
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>
> >>
>
> Is this something that should be fixed in bip118 signatures then?
>
> Cheers,
> aj
> --
> Sent from my phone.
>

[-- Attachment #2: Type: text/html, Size: 6954 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Anthony Towns]

On Sat, Feb 11, 2023 at 09:40:38AM -0500, Russell O'Connor via bitcoin-dev wrote:
> Yes.  If you would otherwise sign the tapleaf, then I would recommend also
> signing the entire tapbranch.

Opened https://github.com/bitcoin-inquisition/bitcoin/issues/19 for
this.

(I think it's better to call it the path to the leaf, as "tapbranch"
seems more to refer to each splitting step in the tree)

Cheers,
aj

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> Peter Todd also suggests in this thread that the use of uncompressed
> keys can cause "surprise" witness inflation, but (a) since segwit
> uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in
> Taproot)

To be clear, I was just pointing out that this problem has existed, in theory
at least, since the beginning of Bitcoin (compressed pubkeys were supported in
v0.1.0). P2PKH addresses are the pre-P2SH ones that start with 1.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 5892 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 11299 bytes --]

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Yuval Kogman]

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).

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 7669 bytes --]

> 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.


Please no apologies - Message matters more than the messenger in

open-source. Yes, on the adversary model I would like to note there is a

potential negative externality in the context of time-sensitive contract,
e.g

for a DLC with short-term maturity you can delay confirmation of the funding

transaction in function of the event outcome progression (e.g a basketball
quarters),

and if the outcome turns in your defavor, you just double-spend a funding
input.


> 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.


We could have miniscript embedded in the backend of a Lightning

implementation, to reject any malleable witness (maybe with some tolerance
bounds ?),

to restrain a counterparty downgrading a posteriori its feerate
contribution.

Full rbf effectively would prevent timevalue DoS inflicted to the
most-utxo-value

contributor in dual-funding, however in the present flow, I don't know if it

changes something, the witness downgrading counterparty benefits from

a feerate discount, not lack of confirmation.


> 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.


I think some combination of the two can makes sense, as if the feerate

is what you paid, the input value is your "economically subjective"
liquidity

risk, and as such you might pay a better signature submission place for

a feerate contribution increase. Quite sophisticated for the basic
dual-funding flow.


> 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).


Yep yep, all types of DoS are less concerning than "loss of funds"

severity pinning attacks, and doesn't sounds to affect currently

deployed protocols. Still concerned all those DoS once accumulated

might be a "practical" show-stopper, like we have with channel jamming.



Le ven. 10 févr. 2023 à 19:35, Yuval Kogman <nothingmuch@woobling.org> a
écrit :

> 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).
>

[-- Attachment #2: Type: text/html, Size: 21674 bytes --]