Alan Evans [ARCHIVE] on Nostr: đ Original date posted:2018-01-24 đ Original message:So, OP, in your scenario, ...
đ
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>;
đ 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>;