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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YLvYx-0008W0-FW
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:20:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.181 as permitted sender)
client-ip=74.125.82.181; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f181.google.com;
Received: from mail-we0-f181.google.com ([74.125.82.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLvYw-0006uF-15
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:20:19 +0000
Received: by mail-we0-f181.google.com with SMTP id w62so10749221wes.12
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 07:20:12 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.90.37 with SMTP id bt5mr7090674wib.29.1423754411941;
Thu, 12 Feb 2015 07:20:11 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:20:11 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:20:11 -0800 (PST)
In-Reply-To: <CANEZrP0z3KG-d+91YDe-jj2d3WWPOrVqCStzLoHpNP=RgXpnyA@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAAt2M1-eogn58zC_eAs4qD4-1GaY4wtuXLoSJ-UEZGKgdXGFyg@mail.gmail.com>
<CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
<CAAt2M19UinurnQQVJWbR_UcSmCBsdFyksnhTfL4ESDMfny+UQQ@mail.gmail.com>
<CANEZrP3+zpMsccnR1e48iwMyQFtP2yNZwseRvCmHrhZFQymycA@mail.gmail.com>
<CAAt2M1_dot=3vU6DbvOMc1F9LN7_JWd=oMr=KiBhNy0WEpTWUw@mail.gmail.com>
<CANEZrP0z3KG-d+91YDe-jj2d3WWPOrVqCStzLoHpNP=RgXpnyA@mail.gmail.com>
Date: Thu, 12 Feb 2015 16:20:11 +0100
Message-ID: <CAAt2M1-_voDLEtaC+pbB4Aj5WHOKye3jvkxHCnLa-6V=jsZDPw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d043d6779f8a570050ee5a784
X-Spam-Score: -0.6 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YLvYw-0006uF-15
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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, 12 Feb 2015 15:20:19 -0000
--f46d043d6779f8a570050ee5a784
Content-Type: text/plain; charset=UTF-8
Den 12 feb 2015 15:53 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> > So you're just arguing that a notary is different to a miner, without
spelling out exactly why.
>
> I'm afraid I still don't understand why you think notaries would build
long term businesses but miners wouldn't, in this model.
>
> I think you are saying because notaries have identity, brand awareness
and because they have big up front bonds, that means they will be
trustworthy.
Miners aren't contractors, they don't have to care about repeat business.
Individual miners don't have enough impact to have a negative impact on
their own capital investment. Zero-conf transactions also aren't that tied
to the Bitcoin valuation.
Multisignature notaries need to convince people to select them. They want
to know that even with collateral, their funds won't be temporarily locked
up and unspendable for days at a time.
What services would miners provide here, do you think?
> Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. Then you can
start advertising to get customers!
Obviously you need to have collateral to provide collateral. Can't make
cryptographic verifiable guarantees if you don't have the resources to back
them.
> The reason mining is such a nice model is it doesn't have these sorts of
requirements.
And also can't make these assurances. Any minority miner can be overrun.
>> As notaries can be small operations ..... [snip] ...... (almost every
large organization in the world have some unallocated funds somewhere).
>
> Which is it? Are notaries small operations or large operations?
The operation itself is small. A few people maintaining a few servers.
The collateral needed depends on how many and how large simultaneous
transactions they want to provide assurances for, so they can chose to be a
small player for one niche market or large and global if they have the
funds for it.
> I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.
Methods for decentralized consensus that aren't PoW also aren't Bitcoin.
> Please don't try and apply this logic in the real world :( Rephrased:
>
> "That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour."
Actually that IS often a bad idea. But fortunately the risk and threat is
low, and mitigation is well understood.
> I'm really not a fan of Peter's approach, which is "hey let's try and
cause as many problems as possible to try and prove a point, without having
created any solutions". Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.
Security analysis requires having the mindset of an attacker. Sometimes
that reveals suboptimal choices. Then you want them changed to more stable
choices such that once the incentives change, the risk already is gone.
Minimization of damage, simply put.
>> Your also ssume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.
>
> Why? You think ability to make payments in a few seconds is some
irrelevant curiousity?
No. But you can't be certain it is secure without having a solid reliable
mechanism to provide such a guarantee.
You want zero-conf to stay safe without involvement of servers? Then
please, try to find a way to secure it. Right now you're assuming it can
remain safe based on circumstances which can change and assumptions about
market participant's valuations that likely aren't true.
> Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?
It would. They'd tank. But you're assuming too much about the basis for
valuation.
--f46d043d6779f8a570050ee5a784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 12 feb 2015 15:53 skrev "Mike Hearn" <<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>>:<br>
>><br>
>> > So you're just arguing that a notary is different to a mi=
ner, without spelling out exactly why.<br>
><br>
> I'm afraid I still don't understand why you think notaries wou=
ld build long term businesses but miners wouldn't, in this model.<br>
><br>
> I think you are saying because notaries have identity, brand awareness=
and because they have big up front bonds, that means they will be trustwor=
thy.</p>
<p dir=3D"ltr">Miners aren't contractors, they don't have to care a=
bout repeat business. Individual miners don't have enough impact to hav=
e a negative impact on their own capital investment. Zero-conf transactions=
also aren't that tied to the Bitcoin valuation. </p>
<p dir=3D"ltr">Multisignature notaries need to convince people to select th=
em. They want to know that even with collateral, their funds won't be t=
emporarily locked up and unspendable for days at a time. </p>
<p dir=3D"ltr">What services would miners provide here, do you think? </p>
<p dir=3D"ltr">> Well, sure. It's the same model governments use and=
is why being a money transmitter in the USA is so difficult: you need to p=
ut up large sums of money as collateral and have your fingerprints taken 48=
times. Then=C2=A0you can start advertising to get customers!</p>
<p dir=3D"ltr">Obviously you need to have collateral to provide collateral.=
Can't make cryptographic verifiable guarantees if you don't have t=
he resources to back them. </p>
<p dir=3D"ltr">> The reason mining is such a nice model is it doesn'=
t have these sorts of requirements.</p>
<p dir=3D"ltr">And also can't make these assurances. Any minority miner=
can be overrun. </p>
<p dir=3D"ltr">>> As notaries can be small operations ..... [snip] ..=
.... (almost every large organization in the world have some unallocated fu=
nds somewhere).<br>
><br>
> Which is it? Are notaries small operations or large operations?=C2=A0<=
/p>
<p dir=3D"ltr">The operation itself is small. A few people maintaining a fe=
w servers.</p>
<p dir=3D"ltr">The collateral needed depends on how many and how large simu=
ltaneous transactions they want to provide assurances for, so they can chos=
e to be a small player for one niche market or large and global if they hav=
e the funds for it. </p>
<p dir=3D"ltr">> I think exploring new consensus models with semi-truste=
d notaries is interesting, but it's not Bitcoin.</p>
<p dir=3D"ltr">Methods for decentralized consensus that aren't PoW also=
aren't Bitcoin. </p>
<p dir=3D"ltr">> Please don't try and apply this logic in the real w=
orld :( Rephrased:<br>
><br>
> "That's a nice house. I noticed it's made of wood. I'=
m going to start fires until it burns down, because there is no guarantee y=
our house won't burn down in future and it's important you understa=
nd that wooden houses aren't safe. Really I'm just doing you a favo=
ur."</p>
<p dir=3D"ltr">Actually that IS often a bad idea. But fortunately the risk =
and threat is low, and mitigation is well understood. </p>
<p dir=3D"ltr">> I'm really not a fan of Peter's approach, which=
is "hey let's try and cause as many problems as possible to try a=
nd prove a point, without having created any solutions". Replace-by-fe=
e-scorched-earth doesn't work and isn't a solution. Miners can easi=
ly cut payment fraudsters in on the stolen money, and as they'd need to=
distribute custom double-spending wallets to make the scheme work it'd=
be very easy to do.</p>
<p dir=3D"ltr">Security analysis requires having the mindset of an attacker=
. Sometimes that reveals suboptimal choices. Then you want them changed to =
more stable choices such that once the incentives change, the risk already =
is gone. Minimization of damage, simply put. </p>
<p dir=3D"ltr">>> Your also ssume people will expect the Bitcoin netw=
ork to keep zero-conf safe forever and that Bitcoin valuation is tied to th=
at. Given the options available and current state of things, I'm assumi=
ng that's wrong.<br>
><br>
> Why? You think ability to make payments in a few seconds is some irrel=
evant curiousity?</p>
<p dir=3D"ltr">No. But you can't be certain it is secure without having=
a solid reliable mechanism to provide such a guarantee. </p>
<p dir=3D"ltr">You want zero-conf to stay safe without involvement of serve=
rs? Then please, try to find a way to secure it. Right now you're assum=
ing it can remain safe based on circumstances which can change and assumpti=
ons about market participant's valuations that likely aren't true. =
</p>
<p dir=3D"ltr">> Let's put it this way. If BitPay's business mod=
el evaporates tomorrow, along with all the merchants they support, do you t=
hink that'd have any effect on Bitcoin's value? If not, why not?</p=
>
<p dir=3D"ltr">It would. They'd tank. But you're assuming too much =
about the basis for valuation. </p>
--f46d043d6779f8a570050ee5a784--
|
