rich1.0darosior [ARCHIVE] (npub1pj…x22xp)https://yabu.me/npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpnjumphttps://yabu.me📅 Original date posted:2022-02-10 📝 Original message:(I have not yet read the recent posts on RBF but i wanted to react on the "additive feerate".) > # Purely additive feerate bumps should never be impossible It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 100000sats by a 100sats/vb transaction paying only 10000sats. Apart from that i very much agree with the approach of taking a step back and reframing, with CPFP being inadapted long term (wasteful, not useful for delegating fee bumping (i'm surprised i didn't mention it publicly but it makes it unsuitable for Revault for instance), and the current carve-out rule makes it only suitable for 2-party protocols), and the `diff` approach. All that again with the caveat that i need to update myself on the recent proposals. -------- Original Message -------- On Feb 10, 2022, 20:40, James O'Beirne via bitcoin-dev wrote: > There's been much talk about fee-bumping lately, and for good reason - > dynamic fee management is going to be a central part of bitcoin use as > the mempool fills up (lord willing) and right now fee-bumping is > fraught with difficulty and pinning peril. > > Gloria's recent post on the topic[0] was very lucid and highlights a > lot of the current issues, as well as some proposals to improve the > situation. > > As others have noted, the post was great. But throughout the course > of reading it and the ensuing discussion, I became troubled by the > increasing complexity of both the status quo and some of the > proposed remedies. > > Layering on special cases, more carve-outs, and X and Y percentage > thresholds is going to make reasoning about the mempool harder than it > already is. Special consideration for "what should be in the next > block" and/or the caching of block templates seems like an imposing > dependency, dragging in a bunch of state and infrastructure to a > question that should be solely limited to mempool feerate aggregates > and the feerate of the particular txn package a wallet is concerned > with. > > This is bad enough for protocol designers and Core developers, but > making the situation any more intractable for "end-users" and wallet > developers feels wrong. > > I thought it might be useful to step back and reframe. Here are a few > aims that are motivated chiefly by the quality of end-user experience, > constrained to obey incentive compatibility (i.e. miner reward, DoS > avoidance). Forgive the abstract dalliance for a moment; I'll talk > through concretes afterwards. > > # Purely additive feerate bumps should never be impossible > > Any user should always be able to add to the incentive to mine any > transaction in a purely additive way. The countervailing force here > ends up being spam prevention (a la min-relay-fee) to prevent someone > from consuming bandwidth and mempool space with a long series of > infinitesimal fee-bumps. > > A fee bump, naturally, should be given the same per-byte consideration > as a normal Bitcoin transaction in terms of relay and block space, > although it would be nice to come up with a more succinct > representation. This leads to another design principle: > > # The bandwidth and chain space consumed by a fee-bump should be minimal > > Instead of prompting a rebroadcast of the original transaction for > replacement, which contains a lot of data not new to the network, it > makes more sense to broadcast the "diff" which is the additive > contribution towards some txn's feerate. > > This dovetails with the idea that... > > # Special transaction structure should not be required to bump fees > > In an ideal design, special structural foresight would not be needed > in order for a txn's feerate to be improved after broadcast. > > Anchor outputs specified solely for CPFP, which amount to many bytes of > wasted chainspace, are a hack. It's probably uncontroversial at this > point to say that even RBF itself is kind of a hack - a special > sequence number should not be necessary for post-broadcast contribution > toward feerate. Not to mention RBF's seemingly wasteful consumption of > bandwidth due to the rebroadcast of data the network has already seen. > > In a sane design, no structural foresight - and certainly no wasted > bytes in the form of unused anchor outputs - should be needed in order > to add to a miner's reward for confirming a given transaction. > > Planning for fee-bumps explicitly in transaction structure also often > winds up locking in which keys are required to bump fees, at odds > with the idea that... > > # Feerate bumps should be able to come from anywhere > > One of the practical downsides of CPFP that I haven't seen discussed in > this conversation is that it requires the transaction to pre-specify the > keys needed to sign for fee bumps. This is problematic if you're, for > example, using a vault structure that makes use of pre-signed > transactions. > > What if the key you specified n the anchor outputs for a bunch of > pre-signed txns is compromised? What if you'd like to be able to > dynamically select the wallet that bumps fees? CPFP does you no favors > here. > > There is of course a tension between allowing fee bumps to come from > anywhere and the threat of pinning-like attacks. So we should venture > to remove pinning as a possibility, in line with the first design > principle I discuss. > > --- > > Coming down to earth, the "tabula rasa" thought experiment above has led > me to favor an approach like the transaction sponsors design that Jeremy > proposed in a prior discussion back in 2020[1]. > > Transaction sponsors allow feerates to be bumped after a transaction's > broadcast, regardless of the structure of the original transaction. > No rebroadcast (wasted bandwidth) is required for the original txn data. > No wasted chainspace on only-maybe-used prophylactic anchor outputs. > > The interface for end-users is very straightforward: if you want to bump > fees, specify a transaction that contributes incrementally to package > feerate for some txid. Simple. > > In the original discussion, there were a few main objections that I noted: > > 1. In Jeremy's original proposal, only one sponsor txn per txid is > allowed by policy. A malicious actor could execute a pinning-like > attack by specifying an only-slightly-helpful feerate sponsor that > then precludes other larger bumps. > > I think there are some ways around this shortcoming. For example: what > if, by policy, sponsor txns had additional constraints that > > - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY, > - the txn must be specified RBFable, > - a replacement for the sponsor txn must raise the sponsor feerate, > including ancestors (maybe this is inherent in "is RBFable," but > I don't want to conflate absolute feerates into this). > > That way, there is still at most a single sponsor txn per txid in the > mempool, but anyone can "mix in" inputs which bump the effective > feerate of the sponsor. > > This may not be the exact solution we want, but I think it demonstrates > that the sponsors design has some flexibility and merits some thinking. > > The second objection about sponsors was > > 2. (from Suhas) sponsors break the classic invariant: "once a valid > transaction is created, it should not become invalid later on unless > the inputs are double-spent." > > This doesn't seem like a huge concern to me if you consider the txid > being sponsored as a sort of spiritual input to the sponsor. While the > theoretical objection against broadening where one has to look in a txn > to determine its dependencies is understandable, I don't see what the > practical cost here is. > > Reorg complexity seems comparable if not identical, especially if we > broaden sponsor rules to allow blocks to contain sponsor txns that are > both for txids in the same block _or_ already included in the chain. > > This theoretical concession seems preferable to heaping more rules onto > an already labyrinthine mempool policy that is difficult for both > implementers and users to reason about practically and conceptually. > > A third objection that wasn't posed, IIRC, but almost certainly would > be: > > 3. Transaction sponsors requires a soft-fork. > > Soft-forks are no fun, but I'll tell you what also isn't fun: being on > the hook to model (and sometimes implement) a dizzying potpourri of > mempool policies and special-cases. Expecting wallet implementers to > abide by a maze of rules faithfully in order to ensure txn broadcast and > fee management invites bugs for perpetuity and network behavior that is > difficult to reason about a priori. Use of CPFP in the long-term also > risks needless chain waste. > > If a soft-fork is the cost of cleaning up this essential process, > consideration should be given to paying it as a one-time cost. This > topic merits a separate post, but consider that in the 5 years leading > up to the 2017 SegWit drama, we averaged about a soft-fork a year. > Uncontroversial, "safe" changes to the consensus protocol shouldn't be > out of the question when significant practical benefit is plain to see. > > --- > > I hope this message has added some framing to the discussion on fees, > as well prompting other participants to go back and give the > transaction sponsor proposal a serious look. The sponsors interface is > about the simplest I can imagine for wallets, and it seems easy to > reason about for implementers on Core and elsewhere. > > I'm not out to propose soft-forks lightly, but the current complexity > in fee management feels untenable, and as evidenced by all the > discussion lately, fees are an increasingly crucial part of the system. > > [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html > [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/b9a80bc9/attachment-0001.html>