{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-09-18\n📝 Original message:Hi Bitcoin Devs,\n\n\nI'd like to share with you a draft proposal for a mechanism to replace\nCPFP and RBF for\nincreasing fees on transactions in the mempool that should be more\nrobust against attacks.\n\nA reference implementation demonstrating these rules is available\n[here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx)\nfor those who\nprefer to not read specs.\n\nShould the mailing list formatting be bungled, it is also available as\na gist [here](https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf).\n\nNon-Destructive TXID Dependencies for Fee Sponsoring\n====================================================\n\nThis BIP proposes a general purpose mechanism for expressing\nnon-destructive (i.e., not requiring\nthe spending of a coin) dependencies on specific transactions being in\nthe same block that can be\nused to sponsor fees of remote transactions.\n\nMotivation\n==========\n\nThe mempool has a variety of protections and guards in place to ensure\nthat miners are economic and\nto protect the network from denial of service.\n\nThe rough surface of these policies has some unintended consequences\nfor second layer protocol\ndevelopers. Applications are either vulnerable to attacks (such as\ntransaction pinning) or must go\nthrough great amounts of careful protocol engineering to guard against\nknown mempool attacks.\n\nThis is insufficient because if new attacks are found, there is\nlimited ability to deploy fixes for\nthem against deployed contract instances (such as open lightning\nchannels). What is required is a\nfully abstracted primitive that requires no special structure from an\nunderlying transaction in\norder to increase fees to confirm the transactions.\n\nConsensus Specification\n=======================\n\nIf a transaction's last output's scripPubKey is of the form OP_VER\nfollowed by n*32 bytes, where\nn\u003e1, it is interpreted as a vector of TXIDs (Sponsor Vector). The\nSponsor Vector TXIDs  must also be\nin the block the transaction is validated in, with no restriction on\norder or on specifying a TXID\nmore than once. This can be accomplished simply with the following patch:\n\n\n```diff\n+\n+    // Extract all required fee dependencies\n+    std::unordered_set\u003cuint256, SaltedTxidHasher\u003e dependencies;\n+\n+    const bool dependencies_enabled = VersionBitsState(pindex-\u003epprev,\nchainparams.GetConsensus(),\nConsensus::DeploymentPos::DEPLOYMENT_TXID_DEPENDENCY,\nversionbitscache) == ThresholdState::ACTIVE;\n+    if (dependencies_enabled) {\n+        for (const auto\u0026 tx : block.vtx) {\n+            // dependency output is if the last output of a txn is\nOP_VER followed by a sequence of 32*n\n+            // bytes\n+            // vout.back() must exist because it is checked in CheckBlock\n+            const CScript\u0026 dependencies_script = tx-\u003evout.back().scriptPubKey;\n+            // empty scripts are valid, so be sure we have at least one byte\n+            if (dependencies_script.size() \u0026\u0026 dependencies_script[0]\n== OP_VER) {\n+                const size_t size = dependencies_script.size() - 1;\n+                if (size % 32 == 0 \u0026\u0026 size \u003e 0) {\n+                    for (auto start = dependencies_script.begin() +1,\nstop = start + 32; start \u003c dependencies_script.end(); start = stop,\nstop += 32) {\n+                        uint256 txid;\n+                        std::copy(start, stop, txid.begin());\n+                        dependencies.emplace(txid);\n+                    }\n+                }\n+                // No rules applied otherwise, open for future upgrades\n+            }\n+        }\n+        if (dependencies.size() \u003e block.vtx.size()) {\n+            return\nstate.Invalid(BlockValidationResult::BLOCK_CONSENSUS,\n\"bad-dependencies-too-many-target-txid\");\n+        }\n+    }\n+\n     for (unsigned int i = 0; i \u003c block.vtx.size(); i++)\n     {\n         const CTransaction \u0026tx = *(block.vtx[i]);\n+        if (!dependencies.empty()) {\n+            dependencies.erase(tx.GetHash());\n+        }\n\n         nInputs += tx.vin.size();\n\n@@ -2190,6 +2308,9 @@ bool CChainState::ConnectBlock(const CBlock\u0026\nblock, BlockValidationState\u0026 state,\n         }\n         UpdateCoins(tx, view, i == 0 ? undoDummy :\nblockundo.vtxundo.back(), pindex-\u003enHeight);\n     }\n+    if (!dependencies.empty()) {\n+        return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS,\n\"bad-dependency-missing-target-txid\");\n+    }\n```\n\n### Design Motivation\nThe final output of a transaction is an unambiguous location to attach\nmetadata to a transaction\nsuch that the data is available for transaction validation. This data\ncould be committed to anywhere,\nwith added implementation complexity, or in the case of Taproot\nannexes, incompatibility with\nnon-Taproot addresses (although this is not a concern for sponsoring a\ntransaction that does not use\nTaproot).\n\nA bare scriptPubKey prefixed with OP_VER is defined to be invalid in\nany context, and is trivially\nprovably unspendable and therefore pruneable.\n\nIf there is another convenient place to put the TXID vector, that's fine too.\n\nAs the output type is non-standard, unupgraded nodes will by default\nnot include Transactions\ncontaining them in the mempool, limiting risk of an upgrade via this mechanism.\n\nPolicy Specification\n====================\n\nThe mechanism proposed above is a general specification for\ninter-transaction dependencies.\n\nIn this BIP, we only care to ensure a subset of behavior sufficient to\nreplace CPFP and RBF for fee\nbumping.\n\nThus we restrict the mempool policy such that:\n\n1. No Transaction with a Sponsor Vector may have any child spends; and\n1. No Transaction with a Sponsor Vector may have any unconfirmed parents; and\n1. The Sponsor Vector must have exactly 1 entry; and\n1. The Sponsor Vector's entry must be present in the mempool; and\n1. Every Transaction may have exactly 1 sponsor in the mempool; except\n1. Transactions with a Sponsor Vector may not be sponsored.\n\n\nThe mempool treats ancestors and descendants limits as follows:\n\n1. Sponsors are counted as children transactions for descendants; but\n1. Sponsoring transactions are exempted from any limits saturated at\nthe time of submission.\n\nThis ensures that within a given package, every child transaction may\nhave a sponsor, but that the\nmempool prefers to not accept new true children while there are\nparents that can be cleared.\n\nTo prevent garbage sponsors, we also require that:\n\n1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate\n\nWe allow one Sponsor to replace another subject to normal replacement\npolicies, they are treated as\nconflicts.\n\n\n### Design Motivation\n\nThere are a few other ways to use OP_VER sponsors that are not\nincluded. For instance, one could\nmake child chains that are only valid if their parent is in the same\nblock (this is incompatible\nwith CTV, exercise left to reader). These use cases are in a sense\nincidental to the motivation\nof this mechanism, and add a lot of implementation complexity.\n\nWhat is wanted is a minimal mechanism that allows arbitrary\nunconnected third parties to attach\nfees to an arbitrary transaction. The set of rules given tightly\nbounds how much extra work the\nmempool might have to do to account for the new sponsors in the worst\ncase, while providing a \"it\nalways works\" API for end users that is not subject to traditional\nissues around pinning.\n\nEventually, rational miners may wish to permit multiple sponsor\ntargets, or multiple sponsoring\ntransactions, but they are not required for the mechanism to work.\nThis is a benefit of the\nminimality of the consensus rule, it is compatible with future policy\nshould it be implemented.\n\n\n#### Attack Analysis of new Policy\n\nIn the worst case the new policy can lead to a 1/2 reduction in the\nnumber of children allowed\n(e.g., if there are 13 children submitted, then 12 sponsors, the 25\nchild limit will saturate\nbefore) and a 2x increase in the maximum children (e.g., if there are\n25 children submitted, and\nthen each are sponsored). Importantly, even in the latter attack\nscenario, the DoS surface is not\ngreat because the sponsor transactions have no children nor parents.\n\n#### Package Relay/Orphan Pool\n\nFuture policy work might be able to insert sponsors into a special\nsponsor pool with an eviction\npolicy that would enable sponsors to be queried and tracked for\ntransactions that have too low fee\nto enter the mempool in the first place. This is treated as a separate\nconcern, as any strides on\npackage relay generally should be able to support sponsors trivially.\n\nReference Implementation\n========================\nA reference implementation demonstrating these rules is available\n[here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx).\nThis is a best\neffort implementation, but has not been carefully audited for\ncorrectness and likely diverges from\nthis document in ways that should either be reflected in this document\nor amended in the code.\n\n\nBest,\n\nJeremy\n\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200918/5e8e4a42/attachment.html\u003e"}