{"type":"rich","version":"1.0","author_name":"npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0r","author_url":"https://nostr.ae/npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-24\n📝 Original message:\u003eI'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\n\u003eB'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\n\u003eAm I missing something?\n\nKind 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\nThe 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\nbip125 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\n\nBut \"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\nThe 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\nHowever, 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\n\n\n[1] Need to be very careful with that, if you're ever merging a merged transaction.\n\n\n\u003e\n\u003e\n\u003eOn Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003eOn Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e\u003e \u003e On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev\n\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e \u003e Interesting. I didn't think about this before, but it seems like bip125 is\n\u003e\u003e \u003e \u003e rather incentive incompatible right now? If we're assuming a competitive\n\u003e\u003e \u003e \u003e mempool, it really doesn't seem generally rational to accept a replacement\n\u003e\u003e \u003e \u003e transaction of a lower fee rate.\n\u003e\u003e \u003e\n\u003e\u003e \u003e BIP125 replacement requires that the fee rate increases.  The text of\n\u003e\u003e \u003e the BIP document is written in a confusing way that doesn't make this\n\u003e\u003e \u003e clear.\n\u003e\u003e\n\u003e\u003eIn fact I considered only requiring an increase in fee rate, based on the\n\u003e\u003e theory that if absolute fee went down, the transaction must be smaller and thus\n\u003e\u003e miners could overall earn more from the additional transactions they could fit\n\u003e\u003e into their block. But to do that properly requires considering whether or not\n\u003e\u003e that's actually true in the particular state the mempool as a whole happens to\n\u003e\u003e be in, so I ditched that idea early on for the much simpler criteria of both a\n\u003e\u003e feerate and absolute fee increase.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003ehttps://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\n\u003e\u003e_______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003e\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e"}