From: Adam Back <adam@cypherspace•org>
To: Danny Thorpe <danny.thorpe@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
Date: Tue, 26 May 2015 23:18:42 +0100 [thread overview]
Message-ID: <CALqxMTHq1E3XPggF_-CmWb15rz6VU0HEmbxLutrZ8NCLyQ77sQ@mail.gmail.com> (raw)
In-Reply-To: <CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra change address is unused.
(If you had bundled extra transactions into the replacement, spending
from the additional inputs, then you'll need to resubmit those as a
separate transaction).
(You have to keep in mind re-orgs so for example the original tx could
be put into a block, and then that block could get reorged by another
block that grows into a longer chain with the replacement tx in it (or
vice versa)).
Adam
On 26 May 2015 at 23:09, Danny Thorpe <danny.thorpe@gmail•com> wrote:
> Thanks for the clarification.
>
> So, since RBF applies only to pending transactions in the mempool awaiting
> incorporation into a block, there is a window of opportunity in which the
> pending tx is incorporated into a block at the same time that the spender is
> constructing and publishing a replacement for that pending tx.
>
> The replacement transaction would be rejected by the peer network as a
> double spend because it conflicts with the now confirmed original tx, and
> the spender will have to go back and create a new stand-alone transaction to
> accomplish what they hoped to do with an RBF replacement.
>
> So an implementation that wishes to take advantage of RBF will still need to
> have a "plan B" implementation path to handle the corner case of a
> replacement tx being rejected as a double spend.
>
> Is this correct?
>
> I'm just trying to get my head around the implementation cost vs benefit of
> RBF in the context of my applications.
>
> Thanks,
> -Danny
>
> On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <pieter.wuille@gmail•com>
> wrote:
>>
>> It's just a mempool policy rule.
>>
>> Allowing the contents of blocks to change (other than by mining a
>> competing chain) would be pretty much the largest possible change to
>> Bitcoin's design....
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2015-05-26 22:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 5:13 Peter Todd
2015-05-26 17:54 ` Tom Harding
2015-05-26 19:10 ` Gregory Maxwell
2015-05-26 23:00 ` Tom Harding
2015-05-26 23:11 ` Gregory Maxwell
2015-05-26 23:42 ` Tom Harding
2015-05-26 21:20 ` Danny Thorpe
2015-05-26 21:27 ` Pieter Wuille
2015-05-26 22:09 ` Danny Thorpe
2015-05-26 22:18 ` Adam Back [this message]
2015-05-27 7:30 ` Peter Todd
2015-06-10 9:10 ` [Bitcoin-development] First-Seen-Safe Replace-by-Fee patch against Bitcoin Core v0.10.2 Peter Todd
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=CALqxMTHq1E3XPggF_-CmWb15rz6VU0HEmbxLutrZ8NCLyQ77sQ@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=danny.thorpe@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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