{"type":"rich","version":"1.0","author_name":"npub19r53ufymeycp9wzk3yzru55y5u46e4vva2lj7nak4zrn6yhrna7qsyj32s","author_url":"https://nostr.ae/npub19r53ufymeycp9wzk3yzru55y5u46e4vva2lj7nak4zrn6yhrna7qsyj32s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-09-18\n📝 Original message:Conceptually this is so simple and explicit it almost seems like an obvious\nprimitive.\n\nGlossing over some of the design/policy decisions...\n\nI wonder what the real-world privacy implications are due to the\ndependencies now being encoded on-chain rather than requiring some effort\nto watch the mempool?\n\nCory\n\nOn Fri, Sep 18, 2020, 20:52 Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Bitcoin Devs,\n\u003e\n\u003e\n\u003e I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for\n\u003e increasing fees on transactions in the mempool that should be more robust against attacks.\n\u003e\n\u003e A reference implementation demonstrating these rules is available\n\u003e [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx) for those who\n\u003e prefer to not read specs.\n\u003e\n\u003e Should the mailing list formatting be bungled, it is also available as a gist [here](https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf).\n\u003e\n\u003e Non-Destructive TXID Dependencies for Fee Sponsoring\n\u003e ====================================================\n\u003e\n\u003e This BIP proposes a general purpose mechanism for expressing non-destructive (i.e., not requiring\n\u003e the spending of a coin) dependencies on specific transactions being in the same block that can be\n\u003e used to sponsor fees of remote transactions.\n\u003e\n\u003e Motivation\n\u003e ==========\n\u003e\n\u003e The mempool has a variety of protections and guards in place to ensure that miners are economic and\n\u003e to protect the network from denial of service.\n\u003e\n\u003e The rough surface of these policies has some unintended consequences for second layer protocol\n\u003e developers. Applications are either vulnerable to attacks (such as transaction pinning) or must go\n\u003e through great amounts of careful protocol engineering to guard against known mempool attacks.\n\u003e\n\u003e This is insufficient because if new attacks are found, there is limited ability to deploy fixes for\n\u003e them against deployed contract instances (such as open lightning channels). What is required is a\n\u003e fully abstracted primitive that requires no special structure from an underlying transaction in\n\u003e order to increase fees to confirm the transactions.\n\u003e\n\u003e Consensus Specification\n\u003e =======================\n\u003e\n\u003e If a transaction's last output's scripPubKey is of the form OP_VER followed by n*32 bytes, where\n\u003e n\u003e1, it is interpreted as a vector of TXIDs (Sponsor Vector). The Sponsor Vector TXIDs  must also be\n\u003e in the block the transaction is validated in, with no restriction on order or on specifying a TXID\n\u003e more than once. This can be accomplished simply with the following patch:\n\u003e\n\u003e\n\u003e ```diff\n\u003e +\n\u003e +    // Extract all required fee dependencies\n\u003e +    std::unordered_set\u003cuint256, SaltedTxidHasher\u003e dependencies;\n\u003e +\n\u003e +    const bool dependencies_enabled = VersionBitsState(pindex-\u003epprev, chainparams.GetConsensus(), Consensus::DeploymentPos::DEPLOYMENT_TXID_DEPENDENCY, versionbitscache) == ThresholdState::ACTIVE;\n\u003e +    if (dependencies_enabled) {\n\u003e +        for (const auto\u0026 tx : block.vtx) {\n\u003e +            // dependency output is if the last output of a txn is OP_VER followed by a sequence of 32*n\n\u003e +            // bytes\n\u003e +            // vout.back() must exist because it is checked in CheckBlock\n\u003e +            const CScript\u0026 dependencies_script = tx-\u003evout.back().scriptPubKey;\n\u003e +            // empty scripts are valid, so be sure we have at least one byte\n\u003e +            if (dependencies_script.size() \u0026\u0026 dependencies_script[0] == OP_VER) {\n\u003e +                const size_t size = dependencies_script.size() - 1;\n\u003e +                if (size % 32 == 0 \u0026\u0026 size \u003e 0) {\n\u003e +                    for (auto start = dependencies_script.begin() +1, stop = start + 32; start \u003c dependencies_script.end(); start = stop, stop += 32) {\n\u003e +                        uint256 txid;\n\u003e +                        std::copy(start, stop, txid.begin());\n\u003e +                        dependencies.emplace(txid);\n\u003e +                    }\n\u003e +                }\n\u003e +                // No rules applied otherwise, open for future upgrades\n\u003e +            }\n\u003e +        }\n\u003e +        if (dependencies.size() \u003e block.vtx.size()) {\n\u003e +            return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, \"bad-dependencies-too-many-target-txid\");\n\u003e +        }\n\u003e +    }\n\u003e +\n\u003e      for (unsigned int i = 0; i \u003c block.vtx.size(); i++)\n\u003e      {\n\u003e          const CTransaction \u0026tx = *(block.vtx[i]);\n\u003e +        if (!dependencies.empty()) {\n\u003e +            dependencies.erase(tx.GetHash());\n\u003e +        }\n\u003e\n\u003e          nInputs += tx.vin.size();\n\u003e\n\u003e @@ -2190,6 +2308,9 @@ bool CChainState::ConnectBlock(const CBlock\u0026 block, BlockValidationState\u0026 state,\n\u003e          }\n\u003e          UpdateCoins(tx, view, i == 0 ? undoDummy : blockundo.vtxundo.back(), pindex-\u003enHeight);\n\u003e      }\n\u003e +    if (!dependencies.empty()) {\n\u003e +        return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, \"bad-dependency-missing-target-txid\");\n\u003e +    }\n\u003e ```\n\u003e\n\u003e ### Design Motivation\n\u003e The final output of a transaction is an unambiguous location to attach metadata to a transaction\n\u003e such that the data is available for transaction validation. This data could be committed to anywhere,\n\u003e with added implementation complexity, or in the case of Taproot annexes, incompatibility with\n\u003e non-Taproot addresses (although this is not a concern for sponsoring a transaction that does not use\n\u003e Taproot).\n\u003e\n\u003e A bare scriptPubKey prefixed with OP_VER is defined to be invalid in any context, and is trivially\n\u003e provably unspendable and therefore pruneable.\n\u003e\n\u003e If there is another convenient place to put the TXID vector, that's fine too.\n\u003e\n\u003e As the output type is non-standard, unupgraded nodes will by default not include Transactions\n\u003e containing them in the mempool, limiting risk of an upgrade via this mechanism.\n\u003e\n\u003e Policy Specification\n\u003e ====================\n\u003e\n\u003e The mechanism proposed above is a general specification for inter-transaction dependencies.\n\u003e\n\u003e In this BIP, we only care to ensure a subset of behavior sufficient to replace CPFP and RBF for fee\n\u003e bumping.\n\u003e\n\u003e Thus we restrict the mempool policy such that:\n\u003e\n\u003e 1. No Transaction with a Sponsor Vector may have any child spends; and\n\u003e 1. No Transaction with a Sponsor Vector may have any unconfirmed parents; and\n\u003e 1. The Sponsor Vector must have exactly 1 entry; and\n\u003e 1. The Sponsor Vector's entry must be present in the mempool; and\n\u003e 1. Every Transaction may have exactly 1 sponsor in the mempool; except\n\u003e 1. Transactions with a Sponsor Vector may not be sponsored.\n\u003e\n\u003e\n\u003e The mempool treats ancestors and descendants limits as follows:\n\u003e\n\u003e 1. Sponsors are counted as children transactions for descendants; but\n\u003e 1. Sponsoring transactions are exempted from any limits saturated at the time of submission.\n\u003e\n\u003e This ensures that within a given package, every child transaction may have a sponsor, but that the\n\u003e mempool prefers to not accept new true children while there are parents that can be cleared.\n\u003e\n\u003e To prevent garbage sponsors, we also require that:\n\u003e\n\u003e 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate\n\u003e\n\u003e We allow one Sponsor to replace another subject to normal replacement policies, they are treated as\n\u003e conflicts.\n\u003e\n\u003e\n\u003e ### Design Motivation\n\u003e\n\u003e There are a few other ways to use OP_VER sponsors that are not included. For instance, one could\n\u003e make child chains that are only valid if their parent is in the same block (this is incompatible\n\u003e with CTV, exercise left to reader). These use cases are in a sense incidental to the motivation\n\u003e of this mechanism, and add a lot of implementation complexity.\n\u003e\n\u003e What is wanted is a minimal mechanism that allows arbitrary unconnected third parties to attach\n\u003e fees to an arbitrary transaction. The set of rules given tightly bounds how much extra work the\n\u003e mempool might have to do to account for the new sponsors in the worst case, while providing a \"it\n\u003e always works\" API for end users that is not subject to traditional issues around pinning.\n\u003e\n\u003e Eventually, rational miners may wish to permit multiple sponsor targets, or multiple sponsoring\n\u003e transactions, but they are not required for the mechanism to work. This is a benefit of the\n\u003e minimality of the consensus rule, it is compatible with future policy should it be implemented.\n\u003e\n\u003e\n\u003e #### Attack Analysis of new Policy\n\u003e\n\u003e In the worst case the new policy can lead to a 1/2 reduction in the number of children allowed\n\u003e (e.g., if there are 13 children submitted, then 12 sponsors, the 25 child limit will saturate\n\u003e before) and a 2x increase in the maximum children (e.g., if there are 25 children submitted, and\n\u003e then each are sponsored). Importantly, even in the latter attack scenario, the DoS surface is not\n\u003e great because the sponsor transactions have no children nor parents.\n\u003e\n\u003e #### Package Relay/Orphan Pool\n\u003e\n\u003e Future policy work might be able to insert sponsors into a special sponsor pool with an eviction\n\u003e policy that would enable sponsors to be queried and tracked for transactions that have too low fee\n\u003e to enter the mempool in the first place. This is treated as a separate concern, as any strides on\n\u003e package relay generally should be able to support sponsors trivially.\n\u003e\n\u003e Reference Implementation\n\u003e ========================\n\u003e A reference implementation demonstrating these rules is available\n\u003e [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx). This is a best\n\u003e effort implementation, but has not been carefully audited for correctness and likely diverges from\n\u003e this document in ways that should either be reflected in this document or amended in the code.\n\u003e\n\u003e\n\u003e Best,\n\u003e\n\u003e Jeremy\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\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/20200918/c7e52557/attachment-0001.html\u003e"}