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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YxVna-0002DQ-9e
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 07:30:46 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.154 as permitted sender)
client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
helo=outmail148154.authsmtp.co.uk;
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YxVnX-0006HG-KX for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 07:30:46 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7Ub2P085033
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 08:30:37 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7UWDc073975
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 08:30:35 +0100 (BST)
Date: Wed, 27 May 2015 03:30:32 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20150527073032.GA22286@savin.petertodd.org>
References: <20150526051305.GA23502@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr"
Content-Disposition: inline
In-Reply-To: <20150526051305.GA23502@savin.petertodd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 43fd65f4-0442-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQJ1
LRkAXVBSFQB4ARQL BR4UURw8cABYeX95 e0RnX25aWkVlcE56
XU8aUWlkYgIHHDMf V0NRcAYaeQdJdlFB aQYrUnZbZXgHYn5i
WlZqMm10N24OdmEN GltQfAobGBsHF2Eq fR1QVQYFHFEOQCQ1
ahArNFMYG14UP0Mu BBMPWEgDL1opBwBY WnpEDiIRHVQZQyMg AEZQTAswHTA1
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YxVnX-0006HG-KX
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: Wed, 27 May 2015 07:30:46 -0000
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote:
> Case 1: Increasing the fee on a single tx
> -----------------------------------------
>=20
> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
> with the minimal relay fee, 2.26uBTC. Increasing the fee while
> respecting FSS-RBF rules requires the addition of one more txin, with
> the change output value increased appropriately, resulting in
> transaction t2, size 374 bytes. If the change txout is sufficient for
> the fee increase, increasing the fee via CPFP requires a second
> 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
> input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
> of 566 bytes.
>=20
> Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
> cases where the original transaction didn't have a change
> output.
To clarify a point raised(1) on the pull-req itself:
The replacement transaction is allowed to not only add new txin's, but
also replace txins. Suppose t1 is a 2-in-2-out P2PKH using transaction,
374 bytes in size. With CPFP accomplished by a 1-in-1-out tx, 192 bytes,
you have 566 bytes total. With FSS RBF if you have an unspent output
greater in value than one of the outputs spent by t1, you can replace
that output in t1's vin txin set and rebroadcast the transaction, still
374 bytes in size. This gives you a 34% cost savings vs. CPFP.
> Case 2: Paying multiple recipients in succession
> ------------------------------------------------
>=20
> We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice.
> We now need to pay Bob. With plain RBF we'd just add a new outptu and
> reduce the value of the change address, a 90% savings. However with FSS
> RBF, decreasing the value is not allowed, so we have to add an input.
>=20
> If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can
> be created, 2*226=3D452 bytes in total. With FSS RBF we can replace t1
> with a 2-in-3-out tx paying both, increasing the value of the change
> output appropriately, resulting in 408 bytes transaction saving 10%
>=20
> Similar to the above example in the case where the change address of t1
> is insufficient to pay Bob the end result is one less transaction output
> in the wallet, defragmenting it. Spending these outputs later on would
> require two 148 byte inputs compared to one with RBF, resulting in an
> overall savings of 25%
Similarly in the multiple recipients case, if sufficiently large
outputs are available the additional funds can be obtained by swapping
one input for another.
For instance if Alice has three outputs, 1.0, 0.5, and 0.2 BTC, and
needs to pay Bob 1.1 BTC, she can create t1:
1.0 -> Bob 1.1
0.2 -> Alice 0.1
If she then needs to pay Charlie 0.2 BTC she can doublespend that with:
1.0 -> Bob 1.1
0.5 -> Charlie 0.2
-> Alice 0.2
Note that care does need to be taken to ensure that multiple rounds of
this always leave at least one input unchanged.
1) https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-105630255
--=20
'peter'[:-1]@petertodd.org
00000000000000000ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9
--PNTmBPCT7hxwcZjr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVZXKTXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZWMwYzNhOTBiYWE1MjI4OTE3MTA0NjQ2OWZlNGEyMWRj
NWEwZGFjNGNiNzU4YTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft4iwf9EMAb+JGciUEiaTMJYvl1SVVr
DeZhhF9xbNOgAjXAYjtDRpzuL5imnWl8wwHcDPJlYkFehEidOz6H40xD3FGsBTL9
9afhSJN4xsyISg3fdIxEKW+LvzkaCD2Goih2ZeLUhXi0Kk+PvMBGh/1u+DSEniBP
1YncM6QzmCJwruwuOfkBGDr7FAju330QMNarmNu2ZrK+qc8WrGhcj1ebYxM/gIYQ
+hIaXvnFtQS7MQ9OBtlQy1VpHSPikplmAvyHM6l3heyWgcXRIHMji3PQB8/BXy/k
EsJYbb5biVxbAEFqCY6Y87vPJnSodnmfiOMksOaN902x3wY+M0jrrefrkuZOgw==
=bOqh
-----END PGP SIGNATURE-----
--PNTmBPCT7hxwcZjr--
|
