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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1YLtGW-000523-9s
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 12:53:08 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.176 as permitted sender)
client-ip=74.125.82.176; envelope-from=alex.mizrahi@gmail.com;
helo=mail-we0-f176.google.com;
Received: from mail-we0-f176.google.com ([74.125.82.176])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLtGV-00059H-56
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 12:53:08 +0000
Received: by mail-we0-f176.google.com with SMTP id x3so9850418wes.7
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 04:53:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.60.15 with SMTP id d15mr7757258wjr.72.1423745579595;
Thu, 12 Feb 2015 04:52:59 -0800 (PST)
Received: by 10.27.148.13 with HTTP; Thu, 12 Feb 2015 04:52:59 -0800 (PST)
In-Reply-To: <CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
Date: Thu, 12 Feb 2015 14:52:59 +0200
Message-ID: <CAE28kUQ87jWhq1p6RK1eKEuEP1ERxN_P2SS0=YsFEGAqRyMPLA@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7ba976c485bc81050ee399e9
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
(alex.mizrahi[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: 1YLtGV-00059H-56
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 12:53:08 -0000
--047d7ba976c485bc81050ee399e9
Content-Type: text/plain; charset=UTF-8
> Miners are *not* incentivised to earn the most money in the next block
> possible. They are incentivised to maximise their return on investment.
>
This would be right if you assume that all Bitcoin miners act as a single
entity. In that case it is true that that entity's goal is to maximize
overall ROI.
But each miner makes decisions on his own. Are you familiar with a concept
of Nash equilibrium, prisoner's dilemma, etc?
The fact that nobody is using this kind of a behavior right now doesn't
mean that we can rely on it.
For example, Peercoin was horribly broken in 6 months after its release
(e.g. people reported that they are able to generate 50 consecutive blocks
simply by bringing a cold wallet online) and yet nobody bothered to exploit
it, and it managed to acquire non-negligible "market cap".
So we have an empiric evidence that proof-of-stake miners are motivated to
keep network secure. So, maybe, we should switch to proof-of-stake, if it
was demonstrated that it is secure?
There are good reasons to not switch to proof-of-stake. Particularly, the
kind which is used in Peercoin is not game-theoretically sound. So even if
it works right now, it can fail in a big way once attackers will really get
around to it. An attack requires significant knowledge, effort and,
possibly, capital, so it might be only feasible on a certain scale.
So, well, anyway, suppose Peter Todd is the only person interested in
maintaining replace-by-fee patches right now, and you can talk him into
abandoning them.
OK, perhaps zero-confirmation payments will be de-facto secure for a couple
of years. And thus a lot of merchants will rely on zero-confirmation
payments protected by nothing but a belief in honest miners, as it is damn
convenient.
But, let's say, 5 years from now, some faction of miners who own
soon-to-be-obsolete equipment will decide to boost their profits with a
replace-by-fee pool and a corresponding wallet. They can market it as "1 of
10 hamburgers are free" if they have 10% of the total hashpower.
So would you take a responsibility for pushing the approach which isn't
game-theoretically sound?
--047d7ba976c485bc81050ee399e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra">Miners are <b>not</b>=C2=A0incentivised to earn the most money=
in the next block possible. They are incentivised to maximise their return=
on investment. </div></div></blockquote><div><br></div><div>This would be =
right if you assume that all Bitcoin miners act as a single entity. In that=
case it is true that that entity's goal is to maximize overall ROI.</d=
iv><div><br></div><div>But each miner makes decisions on his own. Are you f=
amiliar with a concept of Nash equilibrium, prisoner's dilemma, etc?</d=
iv><div><br></div><div>The fact that nobody is using this kind of a behavio=
r right now doesn't mean that we can rely on it.</div><div><br></div><d=
iv>For example, Peercoin was horribly broken in 6 months after its release =
(e.g. people reported that they are able to generate 50 consecutive blocks =
simply by bringing a cold wallet online) and yet nobody bothered to exploit=
it, and it managed to acquire non-negligible "market cap".</div>=
<div><br></div><div>So we have an empiric evidence that proof-of-stake mine=
rs are motivated to keep network secure. So, maybe, we should switch to pro=
of-of-stake, if it was demonstrated that it is secure?</div><div><br></div>=
<div>There are good reasons to not switch to proof-of-stake. Particularly, =
the kind which is used in Peercoin is not game-theoretically sound. So even=
if it works right now, it can fail in a big way once attackers will really=
get around to it. An attack requires significant knowledge, effort and, po=
ssibly, capital, so it might be only feasible on a certain scale.</div><div=
><br></div><div>So, well, anyway, suppose Peter Todd is the only person int=
erested in maintaining replace-by-fee patches right now, and you can talk h=
im into abandoning them.</div><div>OK, perhaps zero-confirmation payments w=
ill be de-facto secure for a couple of years. And thus a lot of merchants w=
ill rely on zero-confirmation payments protected by nothing but a belief in=
honest miners, as it is damn convenient.</div><div><br></div><div>But, let=
's say, 5 years from now, some faction of miners who own soon-to-be-obs=
olete equipment will decide to boost their profits with a replace-by-fee po=
ol and a corresponding wallet. They can market it as "1 of 10 hamburge=
rs are free" if they have 10% of the total hashpower.</div><div><br></=
div><div>So would you take a responsibility for pushing the approach which =
isn't game-theoretically sound?</div><div><br></div><div>=C2=A0</div></=
div></div></div>
--047d7ba976c485bc81050ee399e9--
|
