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 mini
[bitcoin-dev] Bitcoin Contracting Primitives WG 4rd Meeting, Tuesday 21 Feb. 18:00 UTC
Hi list, I'm proposing Tuesday 21st February at 18:00, i.e 2 weeks from now for the 4th Bitcoin contracting primitives WG meeting (the third Tuesday of February month, as done previously). As mentioned during the previous session, there is an issue if anyone would like to propose an agenda topic in advance in an open fashion: https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/34 I would like to propose 2 topics for this upcoming meeting. Firstly, ANYPREVOUT / "Eltoo", there has been a work in progress during the last year for eltoo lightning channels [0]. I think there are still few high-level open questions around fee-bumping and watchtowers, how the proposal would benefit other off-chain constructions, how the proposal works compared to other update mechanisms and a bunch of other things. Secondly, if there is sufficient interest, setting up an open meatspace event during S2 2023 or S1 2024. Meatspace events can be a great thing to accelerate the development pace of contracting protocols. From my experience in-person whiteboard sessions are highly valuable to sync on complex subjects and it has been already evoked in the context of this community process. Ideally, the event would piggyback on some existing bitcoin conference. And I would see this as complementary to the other bitcoin engineering meetings we've already scheduled, just open contracting primitives R&D to a large set of people beyond the usual crowd contributing already to Bitcoin Core [1]. If we have time remaining, we could listen to everyone blockers in their contracting primitives/covenant research. Communication venue is #bitcoin-contracting-primitives-wg on Libera Chat IRC. Logs of the previous session are available here [2]. If you have any questions or feedback, I'm staying responsive. Cheers, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003788.html [1] In term of janitorial role decentralization, I think it would be valuable to have the event organization carried on by someone else reliable other than myself. Contributed to CoreDev Zurich 2021 organisation, so I can share the operational practices. [2] https://github.com/ariard/bitcoin-contracting-primitives-wg/blob/main/meetings/meetings-17-01.md ___ 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: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] Ordinal Inscription Size Limits
Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit : > my favorite one is the javascript exploit for people that like to > render untrusted blockchain data in their browser Taking this example to show that from my standpoint it's not a good idea to store "big things" in the blockchain, but it's a good idea to store proofs of something ( then this is the rationale for this change request https://github.com/bitcoin/bitcoin/issues/27043), we all know that there are plenty of useless things already stored in the blockchain, now if people want to pay to store big things, then let them do it But how can you validate what is stored? Simple answer: you can't, I take in my NFT proposal the example of js code loading, it's impossible to be sure of the code loaded (and it is supposed to evolve, then which version is correct in the blockchain can be mysterious) without using a third party, that's what I am doing here: https://peersm.com/wallet, the third party is my github repo, the code self validates that it is the correct one and the user must check the hash, of course the code could lie then you should better embed the check in a bookmarklet, the page can't lie, and of course I could be a thief then others should check the code and seed the hash somewhere, even if clearly explained that the code must be used off line it's not difficult to invent different things to steal the keys Same principle applies with my NFT proposal (which can be real things, so impossible to store in the blockchain): a third party allowing a timestamp is used to prove that you are the seeder of the NFT (first owner), minting can't be trusted and then becomes useless with the third party, so you spare some bitcoin transactions Using a third party does not mean that the blockchain is of no use, again the blockchain will validate the life of the NFT and it remains decentralized like lightning ___ 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
