{"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 list,\n\nReading Suhas's post on mempool policy consistency rules, and the grounded\nsuggestion that as protocol developers we should work on special policy\nrules to support each reasonable use case on the network rather to arbiter\nbetween class of use-cases in the design of an\nunified set of rules, reminded me there is another solution to solve\nmulti-party funding pinning rather than wide deployment of fullrbf. This\nwas communicated to me a while back, and it was originally dismissed\nbecause of the privacy trade-offs (and potential slight fees overhead\ncost). However, if widely adopted, they might sound acceptable to\ncontracting protocol developers and operators.\n\n## The Problem: Pinning Contracting Protocols Funding Flows with Opt-out\nDouble-Spend\n\nAs originally laid out [0], multi-party collaborative flows\n(coinjoin/dual-funding/swaps/splicing/etc), where every participant\ncontributes at least one input, are suffering from a low-cost and\nhigh-success DoS vector with asymmetric damages. E.g with lightning\ninteractive transaction construction protocols limits of 252 inputs, 1\nsingle input can bleed the timevalue of the remaining 251 inputs, or engage\nin a MEV attack where the fee-bumping entity is lured to inflate feerate\nbeyond the current blockspace demand. The attack can be hidden and a\nposteriori assigning blame consistently stays an open question in the lack\nof a consensus mechanism between participants on the network mempools\nstates.\n\nThe issue lies in the fact that participants joining inputs together don't\nhave control, or even view, of the replacement signaling of any potential\ndouble-spend of the other participants inputs. Indeed the opt-in fullrbf\nsignaling is enforced based on the nSequence field, and this one is fully\nmalleable by the UTXO spender. There is no current mechanism to require\nreplacement signaling provable to a third-party only on the knowledge of\nthe UTXO spents.\n\n# The Solution: Opt-in Full-Replace-by-Fee Spent-nVersion Signaling\n\nA new policy is specified in a new way a transaction can signal that it is\nreplaceable.\n\n1. A confirmed transaction is considered to have opted in to allowing\nreplacement of any of its spends (or their descendants), if the last bit of\nthe nVersion field is set.\n\nRational: The future replacement status of any UTXO spend can be determined\nby inspecting the nVersion, therefore protecting the collaborative\nparticipants of a multi-party flows that the target transaction should\npropagate to the miners, if the fee/feerate offered are the best ones\nwithout opt-out based pinning. It can be required the UTXOs to have few\nconfirmations in case of shallow reorgs to increase DoS protection.\n\n## Solution trade-offs\n\nOn the validation-side, there is one engineering issue, as I think there is\nno access to the spent nversion fields by the mempool logic. This would\npresume we add some new cache of all the confirmed UTXOs, so ~50M * 4bytes,\n300 MB of additional state for policy-enforcing full-nodes. I don't know if\nthere is another strong drawback, even the reorg logic the replaceable\nspends shouldn't be evicted if the confirmed ancestor is back to the\nmempool, as mempool validity shouldn't be reevaluated before a replacement\ncandidate shows up. A fee penalty could be requested for nVersion-signaling\ntransactions to compensate for the additional state stored by full-node\noperators (even if obviously they're not the ones earning the fees).\n\nFor the contracting protocols wallets, as you don't know in advance which\ncoins are going to be used for a collaborative flow, you're better off to\nmark all your coins nVersion fields opting fullrbf. Otherwise, you will\nhave to go through an on-chain fee cost to change the replacement status of\nthe spends of your coins. However, this policy bookmarking comes as a\nprotocol fingerprint leak for an observer of the transaction logs. If all\nthe second-layers used by default, this is constituting a single anonymity\nset, though it might still be the privacy gains we're harvesting from\nTaproot output usage in the optimistic case (e.g in Lightning no commitment\n+ HTLC transactions broadcast).\n\nFor the zeroconf operators, assuming they have access to the UTXO set, they\ncan inspect the receiving transactions ancestors nVersion fields, and sort\nthose transactions in the wider set of the replaceable ones, as they're\ncurrently doing for BIP125 opt-in ones.\n\nLong-term, the annoying privacy issue and the assumption that any wallet\nwill be a Lightning one could lead to the majority of wallets signaling RBF\nfor their spends. Therefore making those wallets incompatible with zeroconf\nservices, slowly economically outlawing them. From my perspective, though\nit might be a simplification, it sounds an alternative full rbf way\nforward, where rather than having miners deciding on the policy\nenforcement, we let the users decide with their coins. However, this new\npolicy enforcement efficiency is still dependent on the existence of relay\npaths and support at the endpoints that matter, the miner mempools. So in\nfine we might have to realize incentive alignment with hashrate is what\nmatters in terms of transaction-relay rules ?\n\nCredit to Greg Maxwell for this idea.\n\nCheers,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221101/7190a0df/attachment-0001.html\u003e"}