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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UaPIn-0005oL-EI
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 11:46:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.113 as permitted sender)
client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
helo=outmail148113.authsmtp.com;
Received: from outmail148113.authsmtp.com ([62.13.148.113])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UaPIm-0004ym-1S for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 11:46:25 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r49BkBW5045052; Thu, 9 May 2013 12:46:11 +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 r49Bk6Es016390
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 9 May 2013 12:46:09 +0100 (BST)
Date: Thu, 9 May 2013 07:46:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20130509114605.GA28133@savin>
References: <CAPaL=UVY4q6+BTtDy3Hy6OVhCB2oTSr2w+nMxyegW5Bpp=+c2A@mail.gmail.com>
<20130509111913.GA15870@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO"
Content-Disposition: inline
In-Reply-To: <20130509111913.GA15870@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 0acb9d2c-b89e-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgsUFVQNAgsB AmUbWlZeVFt7WWo7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqBRVz XRhrERlzcQZPeDBx YUdiWj5bDRcofBJ/
EVMGHWRTeGZhPWIC AURRJB5UcAFPdx9C bVB4BXJDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iGHY9 QREeHDwrVVcIXyE6
JBFjIE9ZEkscekQ3 KV8sXF8eLxYOCwpY fQlMG2dfIEZJTjQi DAdTV0oTeAAA
X-Authentic-SMTP: 61633532353630.1021: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: 1UaPIm-0004ym-1S
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 11:46:25 -0000
--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote:
> In this thread discussing this idea
>=20
> https://bitcointalk.org/index.php?topic=3D179612.0=20
>=20
> it is suggested that the approach risks making 0-confirm double-spends
> easier.
The patch makes the concept of a 0-confirm double-spend obsolete
basically. The model is rather than having some vague, insecure, easily
broken, de-facto no-replacement rule it replaces it with something very
easy to reason about: you are bidding for blockchain space, and you can
adjust your bid after the fact.
The reality is zero-conf double-spends aren't that big of a problem
because the vast majority of payments have other mechanisms they can use
instead of relying on the defacto behavior of dozens of major miners and
nodes.
Long story short, we're better off if we don't give people a false sense
of security.
> I dont see why this should be. Cant part of the validation of accepting a
> fee revision be that every aspct of the revision except the reward must be
> unchanged, otherwise the revision is considered invalid and discarded?
A node has no idea which transaction output is change and which one
isn't; if nodes could distinguish change from payment your privacy would
be badly violated.
By allowing simple replacement without further rules the fee adjustment
process can go on as long as required, without you running out of
additional transaction inputs and without causing the transaction to get
bigger and bigger each time.
It also allows more interesting use cases, like adding additional
outputs to a transaction after the fact as more payees become known, or
if two unrelated parties decide to combine their transactions to save on
blockchain space and preserve their privacy.
Eventually the P2P protocol can have delta compression support, so the
network bandwidth required to merge two transactions into one will be
minimal.
--=20
'peter'[:-1]@petertodd.org
000000000000014c26728a13e351b4dd7a32e99e28d43a960b5ac5f98696ae5b
--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRi4x9AAoJECSBQD2l8JH7BWEH/iyuqSinA8b+BnxXhKMqK2rD
KtU+jONQt0Z+P8b442hY+nWOkbs1DZaa/mZeDwT4kzuSRfNg0d9aTc1xUCccACuD
vCGtRyCx/68XMv/zq06TD2Hx6IF4hEmzUN7Vx3C/mbafCnuavB/UmGp6IlpeN9uD
7FVw1vORh/RfHhR0CvPy3cW0AjnjooQ4YyyrlcLJwVOokGjM9jObcETIE4/PjMDl
Ky/e37vTy3kJKRkqnqLeOLl8dj4emfkmI9sDIApJzh0dhtNrvh+3az2h/aqi37tW
dhYIQqfS4QSdIvOnxXggyVEou2UC00WAZR5wpvzvEmdkY8fvtc3MKo4w1JQK7vs=
=XzPs
-----END PGP SIGNATURE-----
--M9NhX3UHpAaciwkO--
|
