public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2018-01-24 13:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 17:40 [bitcoin-dev] Transaction Merging (bip125 relaxation) Rhavar
2018-01-22 18:16 ` Alan Evans
2018-01-22 18:18   ` Rhavar
2018-01-22 18:50     ` Moral Agent
2018-01-22 18:59       ` Rhavar
2018-01-22 20:00 ` Peter Todd
2018-01-22 20:09   ` Rhavar
2018-01-23 16:31   ` Rhavar
2018-01-23 21:56     ` Moral Agent
2018-01-23 22:19       ` Rhavar
2018-01-23 22:49         ` Gregory Maxwell
2018-01-24  7:44           ` Peter Todd
2018-01-24 13:43             ` Alan Evans [this message]
2018-01-24 16:05               ` Rhavar
2018-01-28 16:43                 ` Sjors Provoost
2018-01-28 17:29                   ` David A. Harding
2018-01-28 17:58                     ` Rhavar
2018-01-28 18:08                     ` Moral Agent
2018-01-23 21:31   ` Gregory Maxwell
2018-01-24  7:28     ` Peter Todd
2018-01-23 23:31 Adam Ficsor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALPhJayjSopa6qPDAo=8-FVCz5+SjXneGMmoYF2Yi2p3FrCb0g@mail.gmail.com' \
    --to=thealanevans@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox