I can see how merging after the fact could be more practical than appending existing transactions.
I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter. The minimum per WU increase could be far higher than the minimum relay fee. The few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 could be made more strict. I don’t know what number, if any, would address concerns about relay spam? This wouldn’t be backward compatible. Does that matter as long as there’s enough nodes that follow the new rules? Is there a punishment for relaying transactions that violate rule 3? Could a recipient using the older rules be mislead (in a way that’s worse than the fact that RBF allows the sender to replace the transaction with anything they want anyway)? Peter Todd wrote: > You'd also be able to push others' txs out of the mempool. Can you elaborate on this issue? And wrote: > payment service for instance where a large number of deposits are aggregated > into a smaller number of payments So this would involve wallets (of users who deposit coins) cooperating with an exchange API to consolidate in-mempool transactions? And wrote: > In fact I considered only requiring an increase in fee rate, based on the theory that if absolute fee went down, the transaction must be smaller and thus miners could overall earn more from the additional transactions they could fit into their block. But to do that properly requires considering whether or not that's actually true in the particular state the mempool as a whole happens to be in, so I ditched that idea early on for the much simpler criteria of both a feerate and absolute fee increase. Why would you need to consider the whole mempool? Let’s say a miner is considering to replace transaction A and B with transaction C, where C pays a higher fee per byte than both A and B. This creates space for ~ one additional transaction in the block. It seems to me the miner only needs to check that the lowest fee per weight transaction > min_fee(A,B). At least in first approximation. Sjors > Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > >> I'm confused, the mempool only sees 1 transaction at a time, first A, then >> later B. "the original transactions", plural, should not exist in the >> mempool. >> >> B's fee and rate needs to be larger than A's, but B will be greater than or >> equal to A anyway. So, just increasing the fee rate will cause a larger fee >> anyway. >> >> Am I missing something? > > Kind of. The first case is that you do the "smarter" type of merging, where > you get an original transaction and then say add an additional output(s) to > it. > > The issue with this, is from a practical perspective is _very_ complex. > Because you really need to do a lot of tracking to see which of the two > transactions actually confirm. And if you are promising fast payments, you > can be stuck in a weird limbo state where you're waiting for the original one > to "safely" confirm before it's safe to make a re-payment (even a > non-malicious will likely contain the replacement). > > bip125 already supports this use-case, but I will suggest that the logic to > deploy this is sufficiently complex that no one is going to attempt any time > in the near future. > > > But "retroactive transaction merging" is actually pretty approachable problem > for a service to implement. You just get N valid transactions you've made, > merge them into one. Strip extraneous inputs[1], and combine and alter the > change amount. > > The reason this is so appealing to implement, is there is very little > complexity. If the "retroactive transaction merge" fails, or doesn't get > confirmed, it actually has no impact. If it does get confirmed, that's just > pure cost-savings. > > However, the rules of bip125 currently make it (unnecessarily?) unappealing, > because I can never lower the absolute amount of fees I pay. Hence I think > it'd be pretty sweet if they could be relaxed to support this if it can be > done in a pretty risk free way. > > > > [1] Need to be very careful with that, if you're ever merging a merged > transaction. > > >> >> >> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev >>> wrote: >>>> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>> Interesting. I didn't think about this before, but it seems like bip125 is >>>>> rather incentive incompatible right now? If we're assuming a competitive >>>>> mempool, it really doesn't seem generally rational to accept a replacement >>>>> transaction of a lower fee rate. >>>> >>>> BIP125 replacement requires that the fee rate increases. The text of >>>> the BIP document is written in a confusing way that doesn't make this >>>> clear. >>> >>> In fact I considered only requiring an increase in fee rate, based on the >>> theory that if absolute fee went down, the transaction must be smaller and >>> thus >>> miners could overall earn more from the additional transactions they could >>> fit >>> into their block. But to do that properly requires considering whether or >>> not >>> that's actually true in the particular state the mempool as a whole happens >>> to >>> be in, so I ditched that idea early on for the much simpler criteria of >>> both a >>> feerate and absolute fee increase. >>> >>> -- >>> https://petertodd.org 'peter'[:-1]@petertodd.org >>> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
