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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdHmG-0007sF-1P
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 10:53:00 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdHmD-0001Jz-MS for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 10:52:59 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4AqokY025420;
Mon, 4 Nov 2013 10:52:50 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4Aqi0W017725
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 10:52:46 GMT
Date: Mon, 4 Nov 2013 05:52:43 -0500
From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20131104105243.GA28805@savin>
References: <20131024143043.GA12658@savin>
<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
<20131024144358.GA17142@savin>
<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
<20131024145447.GA19949@savin>
<CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
<op.w5h2rwhcyldrnw@laptop-air>
<CABsx9T0nc-TO1_=n47UnYHiWKSNvci9Xyhni9PQa=DRo1B7FDg@mail.gmail.com>
<CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline
In-Reply-To: <CAPaL=UVnfVkU_mbQKE2gg7RXBv+B13A1eHU4VpiHkBdmfea80g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3ddf57d0-453f-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmUbWlReVV97XWQ7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcBhw R0ceNRlzcAJEfTBx Y0NqXj5YCBAscEEp
QlNQEG5QeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDChdeIik/
Hgl2Mz0vMDFYMCFY RB04ZWAfW0EAGTgy AgsLEzhnAV1NXSgr
KxUtJ1sRGlpZcl8/ KV8oUl9dPRgITwNT EgAl
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
X-Headers-End: 1VdHmD-0001Jz-MS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-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: Mon, 04 Nov 2013 10:53:00 -0000
--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 28, 2013 at 07:17:50AM +0000, John Dillon wrote:
> This discussion seems to be a lot of hot air over a simple observation th=
at
> estimates are imperfect and always will be. I do not understand you vehem=
ent
> opposition the notion that a backup is a good thing except in the context=
that
> replacement to change fees is halfway to profit-seeking replacement by fe=
e.
>=20
>=20
> Peter Todd:
>=20
> You did a fair bit of leg work for replace-by-fee. Seems to me that
> replace-for-fee will help prep infrastructure to eventual replace-by-fee =
usage,
> while avoiding some of the politics around zero-conf transactions.
Here's the easy part done:
https://github.com/petertodd/bitcoin/tree/replace-for-fee
The rules are pretty simple: a replacement can only happen if every
output in the old transaction has a corresponding output in the new with
the same scriptPubKey, and of equal or greater value. All old tx outputs
must also be unspent. For implementation reasons, the order of the
outputs must also be the same, and the code will never replace two
transactions with one.
If someone wanted to mine with the above code, I'd say go right ahead.
(modulo general testing concerns)
Client-side though it shows a flaw with the Bitcoin wallet code that I
should have realized months ago: essentially a transaction in your
wallet with double-spent inputs forever blocks those inputs from being
spent. This doesn't happen too often because you're wallet will
currently never create double-spends, and will never respend unconfirmed
coins from someone else, but any CoinJoin implementation violates that
assumption and an attacker could easily cause a lot of havok.
I'll have to think about the issue further, but essentially the wallet
needs to recognize when a transaction's inputs no longer exist, and mark
the remaining inputs as unspent. Actually deleting those transactions
=66rom your wallet is secondary to that more important concern.
--=20
'peter'[:-1]@petertodd.org
000000002fdfe6bbcffea72c934475cd4fcfe78d8d06910016d707c9b4a9e827
--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJSd3x7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwOWY0OTEzMzg1ZjY5OTYwZWU5YmUwMjMyNTkwZDBmMDljZmJlNjEzM2Rm
NDVlNjMwNjg3ZjAxNGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv5lAgAkg/5E3Frl5Db3tNz/eWyq1lv
Zc5qMId1k604DbMRerHD9TqgSdQ+Vaz2Rj+HVyBasfXh2iG23tv7HeN2OTndfpcS
GVA6nfPWUewX8qIZmdCJxS+6S5NxwMGxJPdzY+HTxquq/VkaygvLJLFSQCPFyLzl
oaSCSpypM/KlHoFHpflJmQB0dx/tRdbcgTIxE5YdV/Zz7ei46bJkeccQJtyth3hC
gCxqiKrzHR024oNUUj3SzWYhcuzm05Hzyzb3Ah7RRd/NCxs+tmr5zO0eFqJ9V4S8
XshzUHb3rvi7OpXcRHdm8tYVkzjhh5V8DerQ5Mw/fq1KQnZfKN82k6JQxeiAew==
=jqWt
-----END PGP SIGNATURE-----
--NzB8fVQJ5HfG6fxh--
|
