{"type":"rich","version":"1.0","author_name":"npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","author_url":"https://nostr.ae/npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-28\n📝 Original message:I can see how merging after the fact could be more practical than appending existing transactions.\n\nI 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.\n\nThe 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?\n\nThis 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)?\n\nPeter Todd wrote:\n\u003e You'd also be able to push others' txs out of the mempool.\nCan you elaborate on this issue?\n\nAnd wrote:\n\u003e payment service for instance where a large number of deposits are aggregated into a smaller number of payments\n\nSo this would involve wallets (of users who deposit coins) cooperating with an exchange API to consolidate in-mempool transactions?\n\nAnd wrote:\n\n\u003e In fact I considered only requiring an increase in fee rate, based on the\ntheory that if absolute fee went down, the transaction must be smaller and thus\nminers could overall earn more from the additional transactions they could fit\ninto their block. But to do that properly requires considering whether or not\nthat's actually true in the particular state the mempool as a whole happens to\nbe in, so I ditched that idea early on for the much simpler criteria of both a\nfeerate and absolute fee increase.\n\nWhy 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 \u003e min_fee(A,B). At least in first approximation.\n\nSjors\n\n\u003e Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e \n\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e Am I missing something?\n\u003e \n\u003e 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.\n\u003e \n\u003e 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).\n\u003e \n\u003e 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.\n\u003e \n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e \n\u003e \n\u003e [1] Need to be very careful with that, if you're ever merging a merged transaction.\n\u003e \n\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev\n\u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e Interesting. I didn't think about this before, but it seems like bip125 is\n\u003e\u003e\u003e\u003e\u003e rather incentive incompatible right now? If we're assuming a competitive\n\u003e\u003e\u003e\u003e\u003e mempool, it really doesn't seem generally rational to accept a replacement\n\u003e\u003e\u003e\u003e\u003e transaction of a lower fee rate.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e BIP125 replacement requires that the fee rate increases.  The text of\n\u003e\u003e\u003e\u003e the BIP document is written in a confusing way that doesn't make this\n\u003e\u003e\u003e\u003e clear.\n\u003e\u003e\u003e \n\u003e\u003e\u003e In fact I considered only requiring an increase in fee rate, based on the\n\u003e\u003e\u003e theory that if absolute fee went down, the transaction must be smaller and thus\n\u003e\u003e\u003e miners could overall earn more from the additional transactions they could fit\n\u003e\u003e\u003e into their block. But to do that properly requires considering whether or not\n\u003e\u003e\u003e that's actually true in the particular state the mempool as a whole happens to\n\u003e\u003e\u003e be in, so I ditched that idea early on for the much simpler criteria of both a\n\u003e\u003e\u003e feerate and absolute fee increase.\n\u003e\u003e\u003e \n\u003e\u003e\u003e --\n\u003e\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\u003e"}