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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UaPdI-0005rz-B0
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 12:07:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.45 as permitted sender)
client-ip=74.125.83.45; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f45.google.com;
Received: from mail-ee0-f45.google.com ([74.125.83.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UaPdH-00062u-38
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 12:07:36 +0000
Received: by mail-ee0-f45.google.com with SMTP id b45so119013eek.32
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 May 2013 05:07:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash;
bh=dI6j2NjtUTbGgxQnCnLa2SijlOY6kmdNKP8EA3x5/pw=;
b=m3eqQXnhWM8dzk28cJCzVQ2RaZakCPPU0oRyHxGGQxMjGJL2GakIrFlGJkFV52CQ1q
bLXFXE9wk0N7pvx1s0x6GfScTBr9O57S02Rfitriyshaa1mY6lx1fI75jP2CArO5jhCQ
qAZG9PgZRH7GPq8RalILRjtkO8BzXmLFDMQVDLT2qqZ27J3xdpDAFFjAQn991la6PGWk
pxCuueZNP0p2sU8YeVIUMQeHqgmg2w6htimjuKh/WR7Pi9ww6u1qjd1KttKyvBIhHzJQ
s9IPZoAoRc5rpNyBujWEDT1i7G2eUfjkpKH8pGh2X62K9lCci1655Of6cxvqt0eyM90B
hgaQ==
X-Received: by 10.14.99.198 with SMTP id x46mr28311786eef.38.1368101248727;
Thu, 09 May 2013 05:07:28 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id t9sm3774369eeo.11.2013.05.09.05.07.26
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 09 May 2013 05:07:27 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 5ACD52E0619; Thu, 9 May 2013 14:07:25 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Thu, 9 May 2013 14:07:23 +0200
Date: Thu, 9 May 2013 14:07:23 +0200
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20130509120722.GA16188@netbook.cypherspace.org>
References: <CAPaL=UVY4q6+BTtDy3Hy6OVhCB2oTSr2w+nMxyegW5Bpp=+c2A@mail.gmail.com>
<20130509111913.GA15870@netbook.cypherspace.org>
<20130509114605.GA28133@savin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130509114605.GA28133@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130509:pete@petertodd.org::NrZ5VdL9pHxFUvqg:0000000000000000000
0000000000000000000000003RRq
X-Hashcash: 1:20:130509:john.dillon892@googlemail.com::/1Bb4mflmsBqbbdt:00000000
00000000000000000000000032TM
X-Hashcash: 1:20:130509:bitcoin-development@lists.sourceforge.net::DqCcIEfPJugT/
eQY:000000000000000000006xVY
X-Hashcash: 1:20:130509:adam@cypherspace.org::wR16duOGZV7aVq9L:00000000000000000
0000000000000000000000001ib4
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UaPdH-00062u-38
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:07:36 -0000
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.)
About current defacto no replacement: it is the best bitcoin currently has,
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.
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 far,
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 would also be better to try to get the fee right first time than to create
more traffic revising it due to experience. Though the ability to revise
the fee IFF the best effort fee doesnt work empirically after a couple of
blocks seems like a good feature. (But not with revised recipient/change
addresses.
Also if the bids are too flexibly different how do you stop both bids being
processed (eg one in a block, the next in the next block).
Adam
On Thu, May 09, 2013 at 07:46:05AM -0400, Peter Todd wrote:
>On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote:
>> In this thread discussing this idea
>>
>> https://bitcointalk.org/index.php?topic=179612.0
>>
>> 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.
>
>--
>'peter'[:-1]@petertodd.org
>000000000000014c26728a13e351b4dd7a32e99e28d43a960b5ac5f98696ae5b
|
