Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

From: Alan Evans <thealanevans@gmail•com>
To: Peter Todd <pete@petertodd•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
Date: Wed, 24 Jan 2018 09:43:29 -0400	[thread overview]
Message-ID: <CALPhJayjSopa6qPDAo=8-FVCz5+SjXneGMmoYF2Yi2p3FrCb0g@mail.gmail.com> (raw)
In-Reply-To: <20180124074453.GC12767@savin.petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

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@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
>
>

[-- Attachment #2: Type: text/html, Size: 3693 bytes --]