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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UaPpg-00069x-0d
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 12:20:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UaPpe-0005Te-Tm for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 12:20:23 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r49CKAkA012595; Thu, 9 May 2013 13:20:10 +0100 (BST)
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 r49CK5Fx089457
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 9 May 2013 13:20:08 +0100 (BST)
Date: Thu, 9 May 2013 08:20:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20130509122005.GA6645@savin>
References: <CAPaL=UVY4q6+BTtDy3Hy6OVhCB2oTSr2w+nMxyegW5Bpp=+c2A@mail.gmail.com>
<20130509111913.GA15870@netbook.cypherspace.org>
<20130509114605.GA28133@savin>
<20130509120722.GA16188@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <20130509120722.GA16188@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: ca4bdee6-b8a2-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgsUFVQNAgsB AmUbWldeUl17WWo7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqBRVy fRtoGhl6fgFDfzBx Y0ZrXD4IDUAoIRMo
RFMGHTwEeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iGHY9 QREeHDwrVVcIXyE6
JBFjIE9ZEkscekQ3 KV8sXF8eLxYOCwpY fQlMG2dfIEZJTjQi DAdTV0oTeAAA
X-Authentic-SMTP: 61633532353630.1019: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
X-Headers-End: 1UaPpe-0005Te-Tm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] An initial replace-by-fee implementation
is now available
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: Thu, 09 May 2013 12:20:24 -0000
--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, May 09, 2013 at 02:07:23PM +0200, Adam Back wrote:
> I have to say I do not think you want to have it be random as to who gets
> paid (by having conflicting double spends floating around with different
> payee & change addresses all from the same sending address.)
Indeed. That's the point of the blockchain, to take all those potential
inconsistencies and vote on a true transaction history to achieve
consensus.
> About current defacto no replacement: it is the best bitcoin currently ha=
s,
> and it has value, with it you need to do a net-split to attack eg
> 1-confirmation, and this proposal weakens it. Net-splits are possible but
> not trivial. This proposal moves them into spec - ie free.
Right now we don't have double-spend proof propagation, so the
"net-split" attack is actually totally trivial: just broadcast two
different, mutually incompatible, transactions at the same time. About
half the time the recipient will get the payment, the other half of the
time the payment they thought they were going to get is invalidated.
It's very, very rare for sites to have protection against that;
blockchain.info's shared-send mixer is one of the few exceptions. But
the have access to a whole network monitoring service with connections
to nodes all over the planet.
> About privacy: I think you are going to inherently disclose which is the
> change address, because you will decrease the change when you increase the
> fee. There is no coin management in the client, and as far as I saw so f=
ar,
> no privacy management of which coins to reduce coin cross linking. Who's=
to
> say the client has 100s of times as many coins as the payment.
>
> If people dont want to reveal which is change and which payment, they need
> to put a big enough fee up front based on a margin over prevailing fee
> statistics.
It's not ideal, but it still protects against after-the-fact blockchain
analysis.
Statistics is hard - you can't get it right all the time. Besides, what
happens when everyone adds a safety margin? Some people can afford to
wait, so for them starting at a low bid and raises it makes a lot of
sense.
> Also if the bids are too flexibly different how do you stop both bids bei=
ng
> processed (eg one in a block, the next in the next block).
Think about that problem a bit harder. :)
--=20
'peter'[:-1]@petertodd.org
00000000000000220dc3b283e651068535f8e934096cfef35342bc688d8ee578
--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRi5R0AAoJECSBQD2l8JH7/4gIAID/ZYCL+Ec4Z5u02cRJhFX3
4ETNF06m35OvvVqA75dN7tmosxWe+eQhAWNMY/EYhlXzK3JC32TY/DGoNIHJ7bVu
EYSyqdoVjYHllVjDZcQAHofe4nVpFuyuOKtAzierGECpY4U11uf1kcsYxnc9vHxf
MxtlIICpGKpAQeQu2J29YYfgT/rhdp0WEBxrfo4dXFmUHRZ8BGwUlQSNCGtiWwm7
fdfiZSqXb+ZKwxNGu36TWKazc+re8GhwE8G+vPtT+2vLccf7USNjzdMZg7GBShp+
Zq+SyMYTMoNMU1mqf2m/UstvF5Zd3xgpZXPdxhh1mnc4j6tFuXDXgSD/JcV8muA=
=EO6X
-----END PGP SIGNATURE-----
--zhXaljGHf11kAtnf--
|
