rich1.0npub15s37yxwtrf7cd83sujzneprwsjtvhjjxcygutpqk5f966093utms6htj94https://nostr.ae/npub15s37yxwtrf7cd83sujzneprwsjtvhjjxcygutpqk5f966093utms6htj94njumphttps://nostr.ae📅 Original date posted:2018-01-24 📝 Original message:So, OP, in your scenario, you have 1 transaction in the mempool, A, then you want to spend the change before confirmation, so you broadcast a new transaction, B, which replaces A. > Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe. 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? On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev < bitcoin-dev at 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 at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/398e0de6/attachment.html>