{"type":"rich","version":"1.0","author_name":"npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","author_url":"https://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-02\n📝 Original message:My idea, which I hated and didn't propose, was to mark utxos specifically\nfor this exact purpose, but this is extremely ugly from a wallet/consensus\nperspective. nVersion is cleaner(well, except the below issue), at the cost\nof forcibly marking all utxos in a transaction the same way.\n\n\u003e On the validation-side, there is one engineering issue, as I think there\nis no access to the spent nversion fields by the mempool logic.\n\nI don't think Core tracks this value in the utxo set either, because\ncurrently there's no use-case for it today? Am I mistaken?\n\n/**\n * A UTXO entry.\n *\n * Serialized format:\n * - VARINT((coinbase ? 1 : 0) | (height \u003c\u003c 1))\n * - the non-spent CTxOut (via TxOutCompression)\n */\n\nGreg\n\n\nOn Wed, Nov 2, 2022 at 6:27 AM Antoine Riard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi list,\n\u003e\n\u003e Reading Suhas's post on mempool policy consistency rules, and the grounded\n\u003e suggestion that as protocol developers we should work on special policy\n\u003e rules to support each reasonable use case on the network rather to arbiter\n\u003e between class of use-cases in the design of an\n\u003e unified set of rules, reminded me there is another solution to solve\n\u003e multi-party funding pinning rather than wide deployment of fullrbf. This\n\u003e was communicated to me a while back, and it was originally dismissed\n\u003e because of the privacy trade-offs (and potential slight fees overhead\n\u003e cost). However, if widely adopted, they might sound acceptable to\n\u003e contracting protocol developers and operators.\n\u003e\n\u003e ## The Problem: Pinning Contracting Protocols Funding Flows with Opt-out\n\u003e Double-Spend\n\u003e\n\u003e As originally laid out [0], multi-party collaborative flows\n\u003e (coinjoin/dual-funding/swaps/splicing/etc), where every participant\n\u003e contributes at least one input, are suffering from a low-cost and\n\u003e high-success DoS vector with asymmetric damages. E.g with lightning\n\u003e interactive transaction construction protocols limits of 252 inputs, 1\n\u003e single input can bleed the timevalue of the remaining 251 inputs, or engage\n\u003e in a MEV attack where the fee-bumping entity is lured to inflate feerate\n\u003e beyond the current blockspace demand. The attack can be hidden and a\n\u003e posteriori assigning blame consistently stays an open question in the lack\n\u003e of a consensus mechanism between participants on the network mempools\n\u003e states.\n\u003e\n\u003e The issue lies in the fact that participants joining inputs together don't\n\u003e have control, or even view, of the replacement signaling of any potential\n\u003e double-spend of the other participants inputs. Indeed the opt-in fullrbf\n\u003e signaling is enforced based on the nSequence field, and this one is fully\n\u003e malleable by the UTXO spender. There is no current mechanism to require\n\u003e replacement signaling provable to a third-party only on the knowledge of\n\u003e the UTXO spents.\n\u003e\n\u003e # The Solution: Opt-in Full-Replace-by-Fee Spent-nVersion Signaling\n\u003e\n\u003e A new policy is specified in a new way a transaction can signal that it is\n\u003e replaceable.\n\u003e\n\u003e 1. A confirmed transaction is considered to have opted in to allowing\n\u003e replacement of any of its spends (or their descendants), if the last bit of\n\u003e the nVersion field is set.\n\u003e\n\u003e Rational: The future replacement status of any UTXO spend can be\n\u003e determined by inspecting the nVersion, therefore protecting the\n\u003e collaborative participants of a multi-party flows that the target\n\u003e transaction should propagate to the miners, if the fee/feerate offered are\n\u003e the best ones without opt-out based pinning. It can be required the UTXOs\n\u003e to have few confirmations in case of shallow reorgs to increase DoS\n\u003e protection.\n\u003e\n\u003e ## Solution trade-offs\n\u003e\n\u003e On the validation-side, there is one engineering issue, as I think there\n\u003e is no access to the spent nversion fields by the mempool logic. This would\n\u003e presume we add some new cache of all the confirmed UTXOs, so ~50M * 4bytes,\n\u003e 300 MB of additional state for policy-enforcing full-nodes. I don't know if\n\u003e there is another strong drawback, even the reorg logic the replaceable\n\u003e spends shouldn't be evicted if the confirmed ancestor is back to the\n\u003e mempool, as mempool validity shouldn't be reevaluated before a replacement\n\u003e candidate shows up. A fee penalty could be requested for nVersion-signaling\n\u003e transactions to compensate for the additional state stored by full-node\n\u003e operators (even if obviously they're not the ones earning the fees).\n\u003e\n\u003e For the contracting protocols wallets, as you don't know in advance which\n\u003e coins are going to be used for a collaborative flow, you're better off to\n\u003e mark all your coins nVersion fields opting fullrbf. Otherwise, you will\n\u003e have to go through an on-chain fee cost to change the replacement status of\n\u003e the spends of your coins. However, this policy bookmarking comes as a\n\u003e protocol fingerprint leak for an observer of the transaction logs. If all\n\u003e the second-layers used by default, this is constituting a single anonymity\n\u003e set, though it might still be the privacy gains we're harvesting from\n\u003e Taproot output usage in the optimistic case (e.g in Lightning no commitment\n\u003e + HTLC transactions broadcast).\n\u003e\n\u003e For the zeroconf operators, assuming they have access to the UTXO set,\n\u003e they can inspect the receiving transactions ancestors nVersion fields, and\n\u003e sort those transactions in the wider set of the replaceable ones, as\n\u003e they're currently doing for BIP125 opt-in ones.\n\u003e\n\u003e Long-term, the annoying privacy issue and the assumption that any wallet\n\u003e will be a Lightning one could lead to the majority of wallets signaling RBF\n\u003e for their spends. Therefore making those wallets incompatible with zeroconf\n\u003e services, slowly economically outlawing them. From my perspective, though\n\u003e it might be a simplification, it sounds an alternative full rbf way\n\u003e forward, where rather than having miners deciding on the policy\n\u003e enforcement, we let the users decide with their coins. However, this new\n\u003e policy enforcement efficiency is still dependent on the existence of relay\n\u003e paths and support at the endpoints that matter, the miner mempools. So in\n\u003e fine we might have to realize incentive alignment with hashrate is what\n\u003e matters in terms of transaction-relay rules ?\n\u003e\n\u003e Credit to Greg Maxwell for this idea.\n\u003e\n\u003e Cheers,\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\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/70b6a272/attachment.html\u003e"}