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