1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1YxNBS-00008M-6f
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 22:18:50 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.196])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YxNBR-0007hj-2I
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 22:18:50 +0000
Received: from mail-qg0-f48.google.com ([209.85.192.48]) by mrelay.perfora.net
(mreueus001) with ESMTPSA (Nemesis) id 0MJE2W-1Z08L31ASY-002njC for
<bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 00:18:43 +0200
Received: by qgg60 with SMTP id 60so19090979qgg.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 15:18:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.97.136 with SMTP id m8mr36538300qge.32.1432678722764;
Tue, 26 May 2015 15:18:42 -0700 (PDT)
Received: by 10.96.112.164 with HTTP; Tue, 26 May 2015 15:18:42 -0700 (PDT)
In-Reply-To: <CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
References: <20150526051305.GA23502@savin.petertodd.org>
<CAJN5wHXRMfZigtgJ4JTKqRMkoQgkZ-d8sZ5rkpspqySwFEQEKg@mail.gmail.com>
<CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
<CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
Date: Tue, 26 May 2015 23:18:42 +0100
Message-ID: <CALqxMTHq1E3XPggF_-CmWb15rz6VU0HEmbxLutrZ8NCLyQ77sQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:9YP45PLwrG6EPuturEDZl+lhTzxcvDiNxQmnV6690agVXwh4t5g
hnupNZIdzSpfw/aGuG+zaNw3uFouJjLktMqc5SG58KaNAuxLgscExwOFgFWwxv1P7rEDrll
YdwJNiXlwU9Z7b8F/poGU1rOfu9t/ysmXcM5j2ZtKph3BfEuQSW97tsGhZ12ItYNM5Dvzd7
50wLex2vBl+91cfXUlVKQ==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.196 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1YxNBR-0007hj-2I
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 22:18:50 -0000
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
>
|
