{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-02\n📝 Original message:Hi Suhas,\n\n\u003eFrom my understanding, the main crux of the reasoning exposed in your post\nwould be to solidify the transaction-relay paradigm we have been following\nduring the last years, e.g introducing the carve-out rule specifically for\nlightning commitment transactions, or more recently version=3 transactions.\nI think this paradigm could be described summarly as \"to each use-case\nbelongs a set of transaction-relay policy rules\". Some of this set of rules\ncould aim to non-replacement guarantees to the consumers of transactions\nsignaling under this regime (e.g zeroconf). Another set of rules could\nprovide a high-guarantee that a transaction would always get to a miner, no\nmatter what the state of node's mempools on the network (e.g \"maximal rbf\"\nfor contracting protocols).\n\nFirst, coming out of my mind, we would have to consider isolation between\neach set of policy rules, ensuring the signaling mechanism cannot be abused\nby an attacker to create a new pinning vector. E.g, a hypothetical concern\ncould be BIP125 rules interfering with version=3 policy to block the\nreplacement of better ancestor feerate packages. Further, for each set of\npolicy rules arises the question of internal consistency, again an attacker\ncould abuse them to pin transactions\npropagation. I think an earlier version of version=3 was suffering from\nthis concern of not scoping potential \"junk\" ancestors. None of those\nissues are unsolvable, however we should be well-aware of the\nnon-negligeable design complexity encumbered by transaction-relay protocol\ndevelopers to achieve the correct goal. There is not only a need to ensure\ncareful policy rules security analysis, but further to communicate well\ntheir usage to second-layers and wallets developers (a task far from easy\nwith all the confusions contained by current BIP125).\n\nNow, in the evaluation process of a set of policy rules soundness are\nproposed a few reasoning heuristics: namely that it shouldn't interfere\nsensibly with a anti-DoS mempool acceptance algorithm, or shouldn't\ninterfere with other protocols on the network, or counter the interests of\nminers or node operators. I hold the belief the latest question could be\nthe one raising the most concerns. Browsing in the history of Bitcoin Core,\nI think one of the design goals aimed for has always been to level the\nplaying field between miners, e.g BIP152 improving block transfer latency\nto reduce orphan rate. Following this principle, we might wonder if our\ntransaction-relay network should guarantee some equal access to transaction\ninformation to all the miners.\n\nIn the present case of a non-replacement policy regime, we could see the\nfollowing situation to arise, on one side miners deploying private\ntransaction-relay communication channels or API to capture higher fees\nincome from non-standard transactions. On the other-side, transaction\nissuers or consumers bypass the standard transaction-relay policy rules.\nBypass could be motivated by either a zeroconf service double-spend, or\nfaster confirmation of a collaborative transaction. E.g, to reuse the\nexample of unconfirmed transaction chaining, where the sender commit to\nnon-replacement by opting out from the RBF flag, this commitment could be\nreevaluated in the light of changing network mempools congestion, or\nliquidity preferences (e.g the quick need to open LN routing channels). The\nsender could leverage such hypothetical private transaction-relay\ncommunication channels to revoke its non-replacement commitment. Therefore\ndiscrepancies between a set of policy rules design and miners incentives\nsounds to lead to informational asymmetries, harmful for the long-term\ndecentralization of the mining ecosystem. Of course, miner incomes\nasymmetries due to edge in transaction flows access might not be weighted\nas serious today, in a world where transaction fees contribute to most of\nthe block reward, this is far more worrying!\n\nOf course, one position could be to estimate that miner centralization is\nbeyond the scope of responsibility of the Bitcoin Core project. Or at least\nas a result of lightweighted risks.\n\nSuch discrepancy between a set of policy rules design and miners incentives\ncould also lead to hidden security risks for second-layers. As we see more\nsecurity assumptions made on policy rules extension, e.g version=3, a\nlightning channel counterparty could have a competing interest to forge a\nraw package suiting better incentives, and as such nullify the security\nadvantage expected. This could be seen as a loose concern, however the last\ntime we have seen an actor deliberately providing non-standard transactions\nto a miner to break second-layers was yesterday [0]!. From observing other\ncryptocurrencies spaces, such \"MEV-style\" attacks could be more and more\nconcerning [1]. I don't think we should assume miners to behave as \"network\ngentlemen\", in a world where mining can be anonymous, permissionless and\ncensorship-resistant (e.g Stratum V2 giving back template construction to\nminers operators rather than pools).\n\nAccording to me, one of the harder problem we're seeing with this fullrbf\ndiscussion is the lack of a consistent, grounded and well-understood miner\nincentive model, where not only block template construction but also\ntransaction collection and replacement strategies are analyzed, and against\nwhich we could simulate the efficiency of a policy. Assuming we would have\nsuch a model, rather than qualify a policy rule as incentive-compatible in\na binary fashion, we could evaluate them on a scale, and agree on when\nthey're satisfying enough in face of technical complexity, validation\nresources, margin of adversarial exploitation, or whatever other relevant\ncriteria.\n\nAnswering a few other points raised in this post, what appears to me\nobscure is the qualification that fullrbf doesn't solve the DoS issues for\ncontracting protocols (e..g coinjoin/dual-funded lightning). If I can\nunderstand, it's on the ground that the imperfections of BIP125 underscore\nonly the direct conflict feerate. It should be remembered that allowing\nreplacement without considering the opting flag would be already an\nimprovement against the DoS attack, as the attack would have to offer a\nmore compelling feerate to maintain the pin. Improvements of BIP125 can\nhappen on the top, but solving the opt-out double-spend issue sounds to me\na prerequisite.\n\nBeyond that, I think few questions are laid out on the conceptual soundness\nof v3 transaction policy w.r.t concerns raised about fullrbf today. In my\nopinion, I'm sadly with most of them, especially that miners might earn\nmore revenue if we allowed multiple descendant v3 transactions and the\nunenforceable promise for the recipient of such package to not add more\nhigh-value children, I've echoed those concerns earlier in the review of\nnVersion=3 proposal [2]. We might have to swallow the bullet for now, and\nbe okay as lightning developers and operators that there is only a social\ninertia of the miners and lack of reliable communication channels towards\nthem by an adversarial counterparty to offer security [3]. Additionally, I\nthink it would be acceptable to have an option to disable v3 transaction\npolicy, an operator could be willing to reduce the CPU/memory DoS surface\nof its node from partaking to any package relay. Even if it comes at the\nloss of a better view of blockspace demand and downgrades its\nfee-estimation, I think we should give the maximum flexibility to operators\nin choosing their risk model.\n\nTo put it in a nutshell, if we would like to pursue further in the paradigm\nthat \"to each use-case belongs its set of policy rules\" (as long as they\ndon't introduce any harm for the network stakeholders), I believe we would\nbe more grounded with a better quantitative understanding of so-called\n\"miners incentives\". I'm still wondering if it's realistic to deploy policy\nrules that are not sustainable in face of long-term mining dynamics.\n\nBest,\nAntoine\n\n\n[0] https://github.com/lightningnetwork/lnd/issues/7096\n\n[1] On risks of introducing miner harvesting attacks, especially when you\nconsider implications on lightning-style constructions\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html\nand\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html\n\n[2]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020939.html\n\n\"If you're a miner and you receive a non-V3, second descendant of an\nunconfirmed V3 transaction, if the offered fee is in the top mempool\nbacklog, I think you would have an interest to accept such a transaction.\n\nSo I'm not sure if those two rules are compatible with miners incentives...\"\n\n[3] This wonders if we should look forward in the future to lock in the\nCPFP weight of a Lightning commitment with some new consensus semantic, or\nleveraging any covenant magic, cf.\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html\nand\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020991.html\n\nLe lun. 31 oct. 2022 à 11:02, Suhas Daftuar via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e AJ,\n\u003e\n\u003e Thanks for the thoughtful post. I think your observations about how we\n\u003e view mempool policy in the Bitcoin Core project, and how that seems to be\n\u003e changing in the discussions around `-mempoolfullrbf`, are on-point and\n\u003e provide a helpful baseline for considering future policy changes.\n\u003e\n\u003e For a long time I viewed fullrbf as an eventuality and I considered myself\n\u003e to be philosophically supportive of the idea.  However, after giving this\n\u003e issue some thought in the past few weeks, I am reversing my thinking on\n\u003e this.  Concretely, I will argue that we should continue to maintain a relay\n\u003e policy where replacements are rejected for transactions that don't opt-in\n\u003e to RBF (as described in BIP 125), and moreover, that we should remove the\n\u003e `-mempoolfullrbf` flag from Bitcoin Core’s latest release candidate and not\n\u003e plan to release software with that flag, unless (or until) circumstances\n\u003e change on the network, which I'll discuss below.\n\u003e\n\u003e This is, of course, a nuanced topic, and among the considerations is a\n\u003e philosophy of how to think about the relay policy and configuration options\n\u003e that we make available in Bitcoin Core (a consideration that is perhaps\n\u003e unique to that project, but I think relevant for this mailing list).\n\u003e\n\u003e I'll start with some technical issues regarding the benefits of enabling\n\u003e fullrbf on the network.  In the current BIP 125 regime, every time a\n\u003e transaction is created, a choice is made whether to subject the transaction\n\u003e to BIP 125’s RBF rules or not (based on the sequence values of the\n\u003e inputs).  So given that users can already opt-in to RBF, the benefit of a\n\u003e “fullrbf” network policy would be if, somehow, RBF users were still denied\n\u003e the benefits of RBF due to the existence of other transactions that don’t\n\u003e opt-in.\n\u003e\n\u003e Along those lines, Antoine Riard brought up[1] a DoS vector that is\n\u003e available to someone who wants to interfere with multi-party funded\n\u003e transactions, and suggested that fullrbf would eliminate the problem.\n\u003e After exploring that question again in this thread (thanks to Greg Sanders\n\u003e for clarifying this to me), I understand that the issue is around ensuring\n\u003e that a multiparty (coinjoin-type) protocol is able to make eventual\n\u003e progress, by having a candidate multiparty transaction either eventually\n\u003e confirm or become conflicted with something that has been confirmed, in\n\u003e which case the double-spend information could be used to start a new\n\u003e coinjoin round with fewer participants.  The concern Antoine and Greg have\n\u003e brought up is that non-rbf transactions can persist in the mempool\n\u003e ~indefinitely (at a low feerate and not subject to replacement) and\n\u003e interfere with progress being made in a coinjoin protocol.\n\u003e\n\u003e However, it seems to me that similar problems exist for such a protocol\n\u003e even in a fullrbf world, as we understand that term today.  I mentioned the\n\u003e ability for rbf “pinning” to interfere with relay of the multiparty\n\u003e transaction (even if the conflicting transaction signals for RBF – a set of\n\u003e large but low feerate conflicting transactions can persist in the mempool\n\u003e and make it difficult for the coinjoin transaction from confirming, at\n\u003e least without attaching a very large fee); and as Greg mentioned in a\n\u003e followup, the BIP 125 rule to only permit 100 transactions to be removed\n\u003e from the mempool at a time during a replacement can also be used to pin a\n\u003e coinjoin protocol in the same way as a non-rbf transaction today.  It seems\n\u003e to me that what these multiparty protocols actually need is some sort of\n\u003e \"maximal rbf\" network policy: a way to guarantee that a transaction which\n\u003e should be desirable for a miner to mine would always get to a miner and\n\u003e considered for inclusion in a block, no matter what the state of node’s\n\u003e mempools on the network.\n\u003e\n\u003e While that sounds like a reasonable thing to want on its face (and worth\n\u003e working on), it's not how opt-in RBF works today, nor is it how transaction\n\u003e relay has ever conceptually worked.  We have not, thus far, been able to\n\u003e come up with a total ordering on transaction desirability.  Moreover, due\n\u003e to all the DoS issues that exist with transaction relay, there are plenty\n\u003e of seemingly legitimate ways to construct transactions that would not relay\n\u003e well on the network.  Relay has only ever been a best-efforts concept,\n\u003e where we carve out a small subset of the entire transaction universe for\n\u003e which we try to optimize propagation.  The idea behind this approach is\n\u003e that if every use case we can come up with has some way to achieve its\n\u003e goals using transactions that should (eventually) be able to relay, then\n\u003e users wouldn’t have much demand for transactions that would deviate from\n\u003e the supported policies, and we therefore shouldn’t need to worry too much\n\u003e about incentive compatibility concerns when it comes to transaction types\n\u003e that wouldn’t relay at all, even if they are high feerate.  (And when those\n\u003e situations arise where the standard transactions do not accommodate some\n\u003e needed use case, developers typically work to define a policy that is\n\u003e compatible with our anti-DoS goals to support such use cases, such as with\n\u003e the recent proposal for version=3 transactions [2].)\n\u003e\n\u003e BIP 125's RBF rules themselves were an effort to carve out just a subset\n\u003e of situations where a transaction should evict conflicting ones -- it was\n\u003e not a design that anyone thought would ensure that all replacements which\n\u003e \"should\" be mined would always propagate.  And I don't believe that we know\n\u003e how to design policy rules that would achieve the goals of this kind of\n\u003e multiparty protocol in a DoS resistant way, today.  Along those lines, I\n\u003e would point out that even the BIP 125 design itself is not entirely\n\u003e incentive compatible, in that it is possible to construct a replacement\n\u003e transaction that would evict transactions which would be preferable to be\n\u003e included in a block! [3]  (This has been known for years, but fixing this\n\u003e has proven difficult, and the only way to fix it that I’m aware of would be\n\u003e to make BIP 125 RBF even more restrictive than it is today. I do think this\n\u003e is something that needs to be worked on.)\n\u003e\n\u003e Given the limitations of RBF as we have it today, it appears to be\n\u003e incorrect that a fullrbf network policy would solve the problems Antoine\n\u003e raised.  And so absent any other examples, it does not seem to me that\n\u003e fullrbf solves any problems for RBF users, who are already free to choose\n\u003e to subject their transactions to BIP 125’s RBF policy.  From this\n\u003e perspective, \"enabling fullrbf\" is really just taking away user choice to\n\u003e opt a transaction into a non-replacement policy regime.\n\u003e\n\u003e I think we should ask, then, whether it is reasonable on its face that\n\u003e users might want to opt-in to a non-replacement policy?  Or in other words,\n\u003e is it reasonable for a user to mark a transaction as non-replaceable and\n\u003e have that indication be enforced by the network? Note that these are two\n\u003e different questions: you could imagine a world where fullrbf is a dominant\n\u003e policy, but users still use the BIP 125 signaling method to indicate, in an\n\u003e unenforced way, their intention to not replace a transaction.  This might\n\u003e give useful information to the network or the recipient for how to interact\n\u003e with such a transaction.\n\u003e\n\u003e And I think that it's entirely possible that users would continue to use\n\u003e the BIP 125 signaling to indicate that they do not intend to replace a\n\u003e transaction.  For better or worse, this might be because zeroconf services\n\u003e continue to differentiate their behavior based on such a signal (possibly\n\u003e in conjunction with other factors), or it could be because there are other\n\u003e behaviors that could be utilized more effectively if the transaction\n\u003e originator has made such a signal, such as the recipient chaining an\n\u003e unconfirmed transaction as a way to bump the fee (CPFP) [4].\n\u003e\n\u003e If it were to be the case that users continued to use BIP 125-style\n\u003e signaling to indicate that they do not plan to replace a transaction, would\n\u003e that be harmful to the network?  This is not something we can stop in our\n\u003e policy rules (short of censoring such transactions, an obviously bad\n\u003e idea).  I think network actors can always do things that we might think are\n\u003e harmful for the network, but that doesn’t mean that there are no legitimate\n\u003e use cases for the tools that such actors might be using.  Just because\n\u003e someone might use some policy to adopt a zeroconf model, doesn’t mean that\n\u003e others aren’t using the same policy to achieve benign ends (such as better\n\u003e CPFP behavior).\n\u003e\n\u003e Moreover, while users might attempt to exploit services that offer\n\u003e zeroconf or other differentiated behavior to non-replacement signaling\n\u003e transactions, they also might not -- I think predicting user behavior in\n\u003e this way (and specifically predicting the complexities of what a business\n\u003e might do and whether users might try to subvert it) is beyond the scope of\n\u003e what we can do as protocol developers.  Instead, I think we can try to\n\u003e answer a different question: if a group of users were to want the ability\n\u003e to opt-in to a non-replacement policy regime, is that a technically sound\n\u003e option for us to have on the network and enforce in software?\n\u003e Specifically, does that interfere with having a sensible anti-DoS mempool\n\u003e acceptance algorithm, or interfere with other protocols on the network, or\n\u003e necessarily run counter to the interests of miners or node operators?\n\u003e\n\u003e And I think the answer to that question, in looking at the difference\n\u003e between opt-in RBF and fullrbf, is no: offering the ability to opt-in to a\n\u003e non-replacement regime for transactions doesn't introduce any fundamental\n\u003e issues with software or network policy or other protocols.  In a world\n\u003e where we only had fullrbf, I could imagine at some point down the road\n\u003e proposing a non-replacement signal myself, because the complexities around\n\u003e transaction chains (and pinning) are more complex for the RBF case than for\n\u003e the non-RBF case (and BIP 125 is not always incentive compatible to begin\n\u003e with!).  Conceptually, this is no different to me than the version=3\n\u003e transaction policy proposal that has been advancing, if we think of it as a\n\u003e special set of restrictions on transactions designed to accommodate a\n\u003e particular use case.\n\u003e\n\u003e Philosophically, I think we should be looking to add non-interfering use\n\u003e cases to what the network supports.\n\u003e\n\u003e To those who argue for making fullrbf a default policy on the network (or\n\u003e even just offering a flag for users to enable fullrbf), I pose this\n\u003e hypothetical: suppose we deploy the v3 transaction policy proposal (which I\n\u003e hope will happen in the near future).  That policy would restrict the ways\n\u003e that outputs of a v3 transaction can be spent while the transaction is\n\u003e unconfirmed, including by limiting the number and size of descendants that\n\u003e such a transaction can have, and limiting the types of unconfirmed\n\u003e ancestors that can be included.  Suppose in a few years someone proposes\n\u003e that we add a \"-disable_v3_transaction_enforcement\" flag to our software,\n\u003e to let users decide to turn off those policy restrictions and treat v3\n\u003e transactions the same as v2, for all the same reasons that could be argued\n\u003e today with fullrbf: miners might earn more revenue if we allowed multiple\n\u003e descendant v3 transactions; it's illogical for the recipient of a v3\n\u003e transaction to believe what is a fundamentally unenforceable promise of a\n\u003e sender to not issue more high value children that descend from an\n\u003e unconfirmed transaction; it's inappropriate for Bitcoin Core to dictate\n\u003e policy on the network and we should honor user choice to turn off that flag\n\u003e if that’s what users want; if users are relying on v3’s policy restrictions\n\u003e for security then that is an unstable model and we should assume it will\n\u003e get broken[5].\n\u003e\n\u003e It’s obvious to me that adding a flag to disable v3 policy would be\n\u003e subversive to making the lightning use case for v3 transactions work.  And\n\u003e so my response to such a hypothetical proposal would be to argue that no,\n\u003e we should not enable users to disable this policy, because as long as that\n\u003e policy is just optional and working for those who want it, it shouldn’t\n\u003e harm anyone that we offer a tighter set of rules for a particular use\n\u003e case.  Adding a way to bypass those rules is just trying to break someone\n\u003e else’s use case, not trying to add a new one.  We should not wield\n\u003e \"incentive compatibility\" as a bludgeon for breaking things that appear to\n\u003e be working and not causing others harm.\n\u003e\n\u003e I think this is exactly what is happening with fullrbf.\n\u003e\n\u003e In comparing v3 transaction policy with opting out of transaction\n\u003e replacement, there is of course one significant difference that I have\n\u003e ignored thus far: I think the real difference is an opinion about whether\n\u003e non-replacement transactions that are being used today are, overall, bad\n\u003e for Bitcoin, and whether lightning’s use of v3 transactions in the future\n\u003e would be bad for Bitcoin. If you think that zeroconf is unequivocally bad,\n\u003e and that no one will be able to plausibly construct a case that lightning\n\u003e is bad, then that qualitative judgment might sway you to not worrying about\n\u003e the philosophical issues I've raised above, because these situations can be\n\u003e distinguished.\n\u003e\n\u003e However I am not personally willing to say that I think, overall,\n\u003e non-rbf-signaling transactions in use on the network today are bad for\n\u003e Bitcoin (or that fullrbf is definitely good – BIP 125’s rbf rules are\n\u003e something we’ve been trying to improve upon for years, with little\n\u003e success).  Nor am I convinced that someone couldn’t put together a cogent\n\u003e argument for lightning being bad for Bitcoin, because of its reliance on\n\u003e relay policies that are difficult to design and impossible to guarantee as\n\u003e part of its security model.  So I choose instead to merely make a judgment\n\u003e that seems more factually verifiable, which is that non-replacement is a\n\u003e policy widely in use on the network today, and we largely don't have reason\n\u003e to think (as far as I know!) that the network is seeing a lot of\n\u003e transactions that would violate that policy.\n\u003e\n\u003e If it did turn out that users were commonly signaling non-replacement, but\n\u003e then signing and trying to relay doublespends, then I think that would be a\n\u003e very good reason for Bitcoin Core to adopt fullrbf to reflect the reality\n\u003e of what is happening.  In the meantime, I think it makes more sense to say\n\u003e that because we have BIP 125, there seems to be no need for users to signal\n\u003e one way and behave another, and therefore there is no need to offer\n\u003e software that might break a policy that is working well for some users.\n\u003e Other software projects might choose differently, and it is after all a\n\u003e permissionless network, so if this is in fact an unstable equilibrium that\n\u003e will not last, then presumably someday it will be apparent it is not\n\u003e working and we’ll abandon it.  But I think the philosophy of transaction\n\u003e relay policy in Bitcoin Core should be to support disparate use cases in\n\u003e order to try to make everything work better, rather than break things\n\u003e prematurely because we guess others will break them eventually anyway.\n\u003e\n\u003e For those that have read this long email and still favor a fullrbf network\n\u003e policy (or even just the ability for users to be able to turn on fullrbf\n\u003e for themselves), I’d ask for thoughts on the following questions, which\n\u003e have guided my thinking on this:\n\u003e\n\u003e Does fullrbf offer any benefits other than breaking zeroconf business\n\u003e practices?  If so, what are they?\n\u003e\n\u003e Is it reasonable to enforce BIP 125's rbf rules on all transactions, if\n\u003e those rules themselves are not always incentive compatible?\n\u003e\n\u003e If someone were to propose a command line option that breaks v3\n\u003e transaction relay in the future, is there a logical basis for opposing that\n\u003e which is consistent with moving towards fullrbf now?\n\u003e\n\u003e Cheers,\n\u003e Suhas\n\u003e\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html\n\u003e\n\u003e [3] This is because under the BIP 125 rules, the feerate of the\n\u003e replacement transaction is not compared to the individual feerates of all\n\u003e transactions being evicted – we just compare feerates with the transactions\n\u003e that are directly in conflict (and not their descendants). So it’s possible\n\u003e for a transaction that would evict 2 or more transactions to have a higher\n\u003e feerate than the direct conflicts, and higher total fee than the set being\n\u003e evicted, but have a lower feerate (eg if it is larger) than that of some\n\u003e subset of the set of transactions being evicted.\n\u003e\n\u003e [4]  Chaining unconfirmed transactions when the sender might RBF the\n\u003e parent is far riskier than if the sender indicates they don't plan to do so\n\u003e (chaining onto an RBF transaction creates pinning issues for the sender,\n\u003e and risks having the child wiped out if the parent is replaced), so I think\n\u003e this is a concrete reason why signaling that a transaction won’t be\n\u003e replaced could be useful.\n\u003e\n\u003e [5] This is a subtle point. I don’t think v3 transactions create an\n\u003e unreasonable security assumption for the use case it is being designed for.\n\u003e However, I don’t think anyone could rule out the possibility that someone\n\u003e could adopt a usage pattern for v3 transactions that subverts the intent of\n\u003e this policy.  For example, if users started using v3 transactions for all\n\u003e their payments, then the limitations on the number of descendants could\n\u003e directly interfere with CPFP by a recipient, and someone could argue that\n\u003e we should break the policy in order to allow for this hypothetical\n\u003e behavior. I think this is a similar form of argument as saying that\n\u003e zeroconf practices + BIP 125 create an incentive to double-spend non-rbf\n\u003e signaling transactions.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/d2ff3925/attachment-0001.html\u003e"}