Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
> 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 a écrit : > On Wed, 8 Feb 2023 at 02:56, Antoine Riard > 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
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 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, < > michaelfolk...@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 +, Andrew Poelstra via > bitcoin-dev > >>> wrote: > >>> > > >>> > > >>> > > >>> > [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. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev 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, >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 +, Andrew Poelstra via bitcoin-dev >>> wrote: >>> > >>> > >>> > >>> > [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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
On Wed, 8 Feb 2023 at 02:56, Antoine Riard 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). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
The fix for the bug is to sign the entire tapbranch instead of the tapleaf. On Wed., Feb. 8, 2023, 04:35 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]. > > 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 +, Andrew Poelstra via bitcoin-dev >> wrote: >> > >> > >> > >> > [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 >> > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
On Wed, Feb 08, 2023 at 09:34:57AM +, 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 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 > wrote: > >> Some people highlighted some minor problems with my last email: >> >> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev >> wrote: >>> >>> >>> >>> [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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 +, Andrew Poelstra via bitcoin-dev > wrote: > > > > > > > > [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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
On Tue, Feb 07, 2023 at 01:46:22PM +, 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Some people highlighted some minor problems with my last email: On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev wrote: > > > > [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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
> 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 ` CHECKSIG IF SHA256 EQUALVERIFY ENDIF`, Mallory can initially demonstrate that she can spend with `FALSE `, then later switch to spending with ` TRUE `. (or I guess even `DROP 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
## 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
