{"type":"rich","version":"1.0","author_name":"npub15s37yxwtrf7cd83sujzneprwsjtvhjjxcygutpqk5f966093utms6htj94","author_url":"https://nostr.ae/npub15s37yxwtrf7cd83sujzneprwsjtvhjjxcygutpqk5f966093utms6htj94","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-24\n📝 Original message:So, OP, in your scenario, you have 1 transaction in the mempool, A, then\nyou want to spend the change before confirmation, so you broadcast a new\ntransaction, B, which replaces A.\n\n\u003e Because the size of the merged transaction is smaller than the original\ntransactions, unless there is a considerable feerate bump, this rule isn't\npossible to observe.\n\nI'm confused, the mempool only sees 1 transaction at a time, first A, then\nlater B. \" the original transactions\", plural, should not exist in the\nmempool.\n\nB's fee and rate needs to be larger than A's, but B will be greater than or\nequal to A anyway. So, just increasing the fee rate will cause a larger fee\nanyway.\n\nAm I missing something?\n\n\nOn Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev\n\u003e wrote:\n\u003e \u003e On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e Interesting. I didn't think about this before, but it seems like\n\u003e bip125 is\n\u003e \u003e \u003e rather incentive incompatible right now? If we're assuming a\n\u003e competitive\n\u003e \u003e \u003e mempool, it really doesn't seem generally rational to accept a\n\u003e replacement\n\u003e \u003e \u003e transaction of a lower fee rate.\n\u003e \u003e\n\u003e \u003e BIP125 replacement requires that the fee rate increases.  The text of\n\u003e \u003e the BIP document is written in a confusing way that doesn't make this\n\u003e \u003e clear.\n\u003e\n\u003e In fact I considered only requiring an increase in fee rate, based on the\n\u003e theory that if absolute fee went down, the transaction must be smaller and\n\u003e thus\n\u003e miners could overall earn more from the additional transactions they could\n\u003e fit\n\u003e into their block. But to do that properly requires considering whether or\n\u003e not\n\u003e that's actually true in the particular state the mempool as a whole\n\u003e happens to\n\u003e be in, so I ditched that idea early on for the much simpler criteria of\n\u003e both a\n\u003e feerate and absolute fee increase.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/398e0de6/attachment.html\u003e"}