{"type":"rich","version":"1.0","title":"James O'Beirne [ARCHIVE] wrote","author_name":"James O'Beirne [ARCHIVE] (npub1dp…ymz3t)","author_url":"https://yabu.me/npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3t","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-10\n📝 Original message:There's been much talk about fee-bumping lately, and for good reason -\ndynamic fee management is going to be a central part of bitcoin use as\nthe mempool fills up (lord willing) and right now fee-bumping is\nfraught with difficulty and pinning peril.\n\nGloria's recent post on the topic[0] was very lucid and highlights a\nlot of the current issues, as well as some proposals to improve the\nsituation.\n\nAs others have noted, the post was great. But throughout the course\nof reading it and the ensuing discussion, I became troubled by the\nincreasing complexity of both the status quo and some of the\nproposed remedies.\n\nLayering on special cases, more carve-outs, and X and Y percentage\nthresholds is going to make reasoning about the mempool harder than it\nalready is. Special consideration for \"what should be in the next\nblock\" and/or the caching of block templates seems like an imposing\ndependency, dragging in a bunch of state and infrastructure to a\nquestion that should be solely limited to mempool feerate aggregates\nand the feerate of the particular txn package a wallet is concerned\nwith.\n\nThis is bad enough for protocol designers and Core developers, but\nmaking the situation any more intractable for \"end-users\" and wallet\ndevelopers feels wrong.\n\nI thought it might be useful to step back and reframe. Here are a few\naims that are motivated chiefly by the quality of end-user experience,\nconstrained to obey incentive compatibility (i.e. miner reward, DoS\navoidance). Forgive the abstract dalliance for a moment; I'll talk\nthrough concretes afterwards.\n\n\n# Purely additive feerate bumps should never be impossible\n\nAny user should always be able to add to the incentive to mine any\ntransaction in a purely additive way. The countervailing force here\nends up being spam prevention (a la min-relay-fee) to prevent someone\nfrom consuming bandwidth and mempool space with a long series of\ninfinitesimal fee-bumps.\n\nA fee bump, naturally, should be given the same per-byte consideration\nas a normal Bitcoin transaction in terms of relay and block space,\nalthough it would be nice to come up with a more succinct\nrepresentation. This leads to another design principle:\n\n\n# The bandwidth and chain space consumed by a fee-bump should be minimal\n\nInstead of prompting a rebroadcast of the original transaction for\nreplacement, which contains a lot of data not new to the network, it\nmakes more sense to broadcast the \"diff\" which is the additive\ncontribution towards some txn's feerate.\n\nThis dovetails with the idea that...\n\n\n# Special transaction structure should not be required to bump fees\n\nIn an ideal design, special structural foresight would not be needed\nin order for a txn's feerate to be improved after broadcast.\n\nAnchor outputs specified solely for CPFP, which amount to many bytes of\nwasted chainspace, are a hack. It's probably uncontroversial at this\npoint to say that even RBF itself is kind of a hack - a special\nsequence number should not be necessary for post-broadcast contribution\ntoward feerate. Not to mention RBF's seemingly wasteful consumption of\nbandwidth due to the rebroadcast of data the network has already seen.\n\nIn a sane design, no structural foresight - and certainly no wasted\nbytes in the form of unused anchor outputs - should be needed in order\nto add to a miner's reward for confirming a given transaction.\n\nPlanning for fee-bumps explicitly in transaction structure also often\nwinds up locking in which keys are required to bump fees, at odds\nwith the idea that...\n\n\n# Feerate bumps should be able to come from anywhere\n\nOne of the practical downsides of CPFP that I haven't seen discussed in\nthis conversation is that it requires the transaction to pre-specify the\nkeys needed to sign for fee bumps. This is problematic if you're, for\nexample, using a vault structure that makes use of pre-signed\ntransactions.\n\nWhat if the key you specified n the anchor outputs for a bunch of\npre-signed txns is compromised? What if you'd like to be able to\ndynamically select the wallet that bumps fees? CPFP does you no favors\nhere.\n\nThere is of course a tension between allowing fee bumps to come from\nanywhere and the threat of pinning-like attacks. So we should venture\nto remove pinning as a possibility, in line with the first design\nprinciple I discuss.\n\n\n---\n\nComing down to earth, the \"tabula rasa\" thought experiment above has led\nme to favor an approach like the transaction sponsors design that Jeremy\nproposed in a prior discussion back in 2020[1].\n\nTransaction sponsors allow feerates to be bumped after a transaction's\nbroadcast, regardless of the structure of the original transaction.\nNo rebroadcast (wasted bandwidth) is required for the original txn data.\nNo wasted chainspace on only-maybe-used prophylactic anchor outputs.\n\nThe interface for end-users is very straightforward: if you want to bump\nfees, specify a transaction that contributes incrementally to package\nfeerate for some txid. Simple.\n\nIn the original discussion, there were a few main objections that I noted:\n\n1. In Jeremy's original proposal, only one sponsor txn per txid is\n   allowed by policy. A malicious actor could execute a pinning-like\n   attack by specifying an only-slightly-helpful feerate sponsor that\n   then precludes other larger bumps.\n\nI think there are some ways around this shortcoming. For example: what\nif, by policy, sponsor txns had additional constraints that\n\n  - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,\n  - the txn must be specified RBFable,\n  - a replacement for the sponsor txn must raise the sponsor feerate,\n    including ancestors (maybe this is inherent in \"is RBFable,\" but\n    I don't want to conflate absolute feerates into this).\n\nThat way, there is still at most a single sponsor txn per txid in the\nmempool, but anyone can \"mix in\" inputs which bump the effective\nfeerate of the sponsor.\n\nThis may not be the exact solution we want, but I think it demonstrates\nthat the sponsors design has some flexibility and merits some thinking.\n\nThe second objection about sponsors was\n\n2. (from Suhas) sponsors break the classic invariant: \"once a valid\n   transaction is created, it should not become invalid later on unless\n   the inputs are double-spent.\"\n\nThis doesn't seem like a huge concern to me if you consider the txid\nbeing sponsored as a sort of spiritual input to the sponsor. While the\ntheoretical objection against broadening where one has to look in a txn\nto determine its dependencies is understandable, I don't see what the\npractical cost here is.\n\nReorg complexity seems comparable if not identical, especially if we\nbroaden sponsor rules to allow blocks to contain sponsor txns that are\nboth for txids in the same block _or_ already included in the chain.\n\nThis theoretical concession seems preferable to heaping more rules onto\nan already labyrinthine mempool policy that is difficult for both\nimplementers and users to reason about practically and conceptually.\n\nA third objection that wasn't posed, IIRC, but almost certainly would\nbe:\n\n3. Transaction sponsors requires a soft-fork.\n\nSoft-forks are no fun, but I'll tell you what also isn't fun: being on\nthe hook to model (and sometimes implement) a dizzying potpourri of\nmempool policies and special-cases. Expecting wallet implementers to\nabide by a maze of rules faithfully in order to ensure txn broadcast and\nfee management invites bugs for perpetuity and network behavior that is\ndifficult to reason about a priori. Use of CPFP in the long-term also\nrisks needless chain waste.\n\nIf a soft-fork is the cost of cleaning up this essential process,\nconsideration should be given to paying it as a one-time cost. This\ntopic merits a separate post, but consider that in the 5 years leading\nup to the 2017 SegWit drama, we averaged about a soft-fork a year.\nUncontroversial, \"safe\" changes to the consensus protocol shouldn't be\nout of the question when significant practical benefit is plain to see.\n\n---\n\nI hope this message has added some framing to the discussion on fees,\nas well prompting other participants to go back and give the\ntransaction sponsor proposal a serious look. The sponsors interface is\nabout the simplest I can imagine for wallets, and it seems easy to\nreason about for implementers on Core and elsewhere.\n\nI'm not out to propose soft-forks lightly, but the current complexity\nin fee management feels untenable, and as evidenced by all the\ndiscussion lately, fees are an increasingly crucial part of the system.\n\n\n\n[0]:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html\n[1]:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/b6bf7054/attachment.html\u003e"}