summaryrefslogtreecommitdiff
path: root/ed/0f786b27313d7a75fa4ee717f35ce197cc2933
blob: 89276299fee39f6b635b78a119e5a9ebe1c5bc8b (plain)
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
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <natanael.l@gmail.com>) id 1YLusH-0005sv-OS
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Feb 2015 14:36:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.42 as permitted sender)
	client-ip=74.125.82.42; envelope-from=natanael.l@gmail.com;
	helo=mail-wg0-f42.google.com; 
Received: from mail-wg0-f42.google.com ([74.125.82.42])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YLusF-000246-US
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Feb 2015 14:36:13 +0000
Received: by mail-wg0-f42.google.com with SMTP id x13so10526354wgg.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 12 Feb 2015 06:36:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.172.35 with SMTP id az3mr8415813wjc.43.1423751765863;
	Thu, 12 Feb 2015 06:36:05 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 06:36:05 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 06:36:05 -0800 (PST)
In-Reply-To: <CANEZrP3+zpMsccnR1e48iwMyQFtP2yNZwseRvCmHrhZFQymycA@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>
Date: Thu, 12 Feb 2015 15:36:05 +0100
Message-ID: <CAAt2M1_dot=3vU6DbvOMc1F9LN7_JWd=oMr=KiBhNy0WEpTWUw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0122e8b640b2b1050ee50afa
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: 1YLusF-000246-US
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 14:36:13 -0000

--089e0122e8b640b2b1050ee50afa
Content-Type: text/plain; charset=UTF-8

Den 12 feb 2015 14:44 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
>
> There have been lots of e-cash schemes proposed in the academic
literature that work like this, or variants of it. Schemes where
participants are anonymous until they double spend are popular.
>
> Let's re-write your proposal but substituting the word notary for miner:
>
>> To profit, the miner would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
>
> That's the exact argument we're having. The assertion is that a
"rational" notary would kill his own business to increase his profits in
the next few hours. So you're just arguing that a notary is different to a
miner, without spelling out exactly why.
>
> Does the notary have to make a big up front investment? If so, why is
that different to mining investment?

Miners are transient. You don't depend on any given subset of them.
Centralized e-currency give you no choice but to trust one set of notaries.

The notary don't have any large maintenance costs. The initial investment
is small, they don't need more than a few servers and maybe a HSM and some
office. In the non-collateral version, they're a centralized entity. Note
that in the fully centralized model, if the notary goes bad you're screwed.
Your tokens are useless or maybe gone.

Essentially you can't know if you're up for the long con or not.

Anybody can set up a miner with capital investments. No individual miner
has a large impact on the system as a whole.

In Bitcoin, you aren't dependent on any one multisignature notary. One
going gown only represents a small loss and done temporarily locked funds.
Anybody can set up a multisignature notary, but people won't trust you
unless you show you're trustable - you need to market yourself to get to
the point where a malicious doublespend can be profitable.

You can't really replicate the collateralized multisignature notary model
in centralized systems. Because having the e-currency bank be the notary
means they have the same powers a 51% miner would have - they can block the
transaction claiming the collateral, they can censor any other transactions
at will, and all your funds depend on them and the market's trust in them.

> Is the notary non-anonymous and afraid of being charged with payment
fraud? If so, note that big miners do lots of non-anonymous things too,
like renting warehouses and importing specialised equipment.

As notaries can be small operations, they can perform the doublespend as
they escape across the border.

> Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?

With collateralized multisignature notaries, my assumption is that
organizations that are related to Bitcoin transactions that has sufficient
sums of unallocated funds would use them for collateral in a scheme like
this (almost every large organization in the world have some unallocated
funds somewhere).

As sellers have almost no risk of losing money to them, any notary backed
by somebody they know and trust would be good enough

As buyers also have no risk, they'd use them when they want to make quick
payments.

-----

You seem to be making a lot of arguments from the status quo. I don't care
what people have been doing, preserving every habit isn't a sacred goal. I
care about stable incentives and long term predictability regarding what
behavior is safe. Behavior that becomes unsafe if incentives change is bad
and shouldn't be relied on.

Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a
guarantee for what will end up in the blocks without servers involved is to
reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you
like!  What you consider an attack is irrelevant. You assume a certain
behavior is desired without first making sure it is reliable.

Depending on that which isn't guaranteed is baaaad, and breaking other
people's assumptions is by itself NOT an attack if there never was a
guarantee or even as little as an implicit understanding it is safe.

Your also assume 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.

Besides, zero-conf will never be secure if you don't add external
contextual information as a requirement when validating blocks. Otherwise
defecting miners will frequently doublespend against you. And adding such
information is messy and probably not secure in itself, as it opens up for
gaming the system through network level attacks.

And your remarks against game theory seems unwarranted.

The game theorists that are wrong are typically wrong for one of the
following reasons;

* Their model is wrong. The system, the actors and/or the options available
are misunderstood.
* The actors don't understand the avaliable incentives and go for trial and
error (the most optimal choices for attack and defense are found at random
or not at all, and not always adopted until it has stood the test of time).
* That option is on the to-do list, just wait.
* There's easier and/or more profitable attacks (a variant of #1 if the
game theorist said it is certain to happen).

You should NOT EVER rely on security-through-opportunity-cost for the
attacker or assume you can always keep doing what you always did. Once the
bigger targets are gone, you're next.

--089e0122e8b640b2b1050ee50afa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Den 12 feb 2015 14:44 skrev &quot;Mike Hearn&quot; &lt;<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt; You can prove a doublespend instantly by showing two conflicting t=
ransactions both signed by thar party. This pair can be distributed as a pr=
oof of malice globally in seconds via a push messaging mechanism.<br>
&gt;<br>
&gt; There have been lots of e-cash schemes proposed in the academic litera=
ture that work like this, or variants of it. Schemes where participants are=
 anonymous until they double spend are popular.<br>
&gt;<br>
&gt; Let&#39;s re-write your proposal but substituting the word notary for =
miner:<br>
&gt;<br>
&gt;&gt; To profit, the miner would have to be sure the payout from agreein=
g on collusion (or to perform the doublespend themselves) would pay out bet=
ter than acting honestly for a given amount of time info the future. This m=
eans transactions for small sums are secure.<br>
&gt;<br>
&gt; That&#39;s the exact argument we&#39;re having. The assertion is that =
a &quot;rational&quot; notary would kill his own business to increase his p=
rofits in the next few hours. So you&#39;re just arguing that a notary is d=
ifferent to a miner, without spelling out exactly why.<br>
&gt;<br>
&gt; Does the notary have to make a big up front investment? If so, why is =
that different to mining investment?</p>
<p dir=3D"ltr">Miners are transient. You don&#39;t depend on any given subs=
et of them. Centralized e-currency give you no choice but to trust one set =
of notaries. </p>
<p dir=3D"ltr">The notary don&#39;t have any large maintenance costs. The i=
nitial investment is small, they don&#39;t need more than a few servers and=
 maybe a HSM and some office. In the non-collateral version, they&#39;re a =
centralized entity. Note that in the fully centralized model, if the notary=
 goes bad you&#39;re screwed. Your tokens are useless or maybe gone.</p>
<p dir=3D"ltr">Essentially you can&#39;t know if you&#39;re up for the long=
 con or not. </p>
<p dir=3D"ltr">Anybody can set up a miner with capital investments. No indi=
vidual miner has a large impact on the system as a whole. </p>
<p dir=3D"ltr">In Bitcoin, you aren&#39;t dependent on any one multisignatu=
re notary. One going gown only represents a small loss and done temporarily=
 locked funds. Anybody can set up a multisignature notary, but people won&#=
39;t trust you unless you show you&#39;re trustable - you need to market yo=
urself to get to the point where a malicious doublespend can be profitable.=
 </p>
<p dir=3D"ltr">You can&#39;t really replicate the collateralized multisigna=
ture notary model in centralized systems. Because having the e-currency ban=
k be the notary means they have the same powers a 51% miner would have - th=
ey can block the transaction claiming the collateral, they can censor any o=
ther transactions at will, and all your funds depend on them and the market=
&#39;s trust in them. </p>
<p dir=3D"ltr">&gt; Is the notary non-anonymous and afraid of being charged=
 with payment fraud? If so, note that big miners do lots of non-anonymous t=
hings too, like renting warehouses and importing specialised equipment.=C2=
=A0</p>
<p dir=3D"ltr">As notaries can be small operations, they can perform the do=
ublespend as they escape across the border. </p>
<p dir=3D"ltr">&gt; Is it because of the big up front collateral they&#39;r=
e meant to have lying around? If so, how do you ensure a fluid market for n=
otaries?</p>
<p dir=3D"ltr">With collateralized multisignature notaries, my assumption i=
s that organizations that are related to Bitcoin transactions that has suff=
icient sums of unallocated funds would use them for collateral in a scheme =
like this (almost every large organization in the world have some unallocat=
ed funds somewhere).</p>
<p dir=3D"ltr">As sellers have almost no risk of losing money to them, any =
notary backed by somebody they know and trust would be good enough </p>
<p dir=3D"ltr">As buyers also have no risk, they&#39;d use them when they w=
ant to make quick payments. </p>
<p dir=3D"ltr">-----</p>
<p dir=3D"ltr">You seem to be making a lot of arguments from the status quo=
. I don&#39;t care what people have been doing, preserving every habit isn&=
#39;t a sacred goal. I care about stable incentives and long term predictab=
ility regarding what behavior is safe. Behavior that becomes unsafe if ince=
ntives change is bad and shouldn&#39;t be relied on. </p>
<p dir=3D"ltr">Also, Bitcoin is the concensus mechanism. As mentioned, tryi=
ng to provide a guarantee for what will end up in the blocks without server=
s involved is to reinvent Bitcoin within Bitcoin. I can go Xzibit on you al=
l day long if you like!=C2=A0 What you consider an attack is irrelevant. Yo=
u assume a certain behavior is desired without first making sure it is reli=
able.</p>
<p dir=3D"ltr">Depending on that which isn&#39;t guaranteed is baaaad, and =
breaking other people&#39;s assumptions is by itself NOT an attack if there=
 never was a guarantee or even as little as an implicit understanding it is=
 safe. </p>
<p dir=3D"ltr">Your also assume people will expect the Bitcoin network to k=
eep zero-conf safe forever and that Bitcoin valuation is tied to that. Give=
n the options available and current state of things, I&#39;m assuming that&=
#39;s wrong.</p>
<p dir=3D"ltr">Besides, zero-conf will never be secure if you don&#39;t add=
 external contextual information as a requirement when validating blocks. O=
therwise defecting miners will frequently doublespend against you. And addi=
ng such information is messy and probably not secure in itself, as it opens=
 up for gaming the system through network level attacks. </p>
<p dir=3D"ltr">And your remarks against game theory seems unwarranted. </p>
<p dir=3D"ltr">The game theorists that are wrong are typically wrong for on=
e of the following reasons;</p>
<p dir=3D"ltr">* Their model is wrong. The system, the actors and/or the op=
tions available are misunderstood. <br>
* The actors don&#39;t understand the avaliable incentives and go for trial=
 and error (the most optimal choices for attack and defense are found at ra=
ndom or not at all, and not always adopted until it has stood the test of t=
ime). <br>
* That option is on the to-do list, just wait. <br>
* There&#39;s easier and/or more profitable attacks (a variant of #1 if the=
 game theorist said it is certain to happen). </p>
<p dir=3D"ltr">You should NOT EVER rely on security-through-opportunity-cos=
t for the attacker or assume you can always keep doing what you always did.=
 Once the bigger targets are gone, you&#39;re next. </p>

--089e0122e8b640b2b1050ee50afa--