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
|
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 <SRS0=QJoVlpPy=UQ=jerviss.org=kjj@jerviss.org>)
id 1VeHgz-0006WK-EN for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 04:59:41 +0000
X-ACL-Warn:
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1VeHgw-0002Bq-0Q
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 04:59:41 +0000
Received: from [10.8.2.254] ([192.151.168.109])
(username: kjj authenticated by PLAIN symmetric_key_bits=0)
by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id rA74xUpb020393
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 6 Nov 2013 22:59:30 -0600
Message-ID: <527B1E30.9090800@jerviss.org>
Date: Wed, 06 Nov 2013 22:59:28 -0600
From: Kyle Jerviss <kjj@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
rv:25.0) Gecko/20100101 SeaMonkey/2.22
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <5279D49D.5050807@jerviss.org> <CAJHLa0N1-8LfFuWq=vS0r-t2Bt-qZ6yKuGjrnicUOj+K6Gpx5A@mail.gmail.com> <CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com> <20131107034404.GA5140@savin>
<527B13EC.7020708@jerviss.org> <20131107043310.GA30788@savin>
In-Reply-To: <20131107043310.GA30788@savin>
Content-Type: multipart/alternative;
boundary="------------040109010407010309060007"
Received-SPF: pass (inana.jerviss.org: 192.151.168.109 is authenticated by a
trusted mechanism)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VeHgw-0002Bq-0Q
Subject: Re: [Bitcoin-development] we can all relax now
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, 07 Nov 2013 04:59:41 -0000
This is a multi-part message in MIME format.
--------------040109010407010309060007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Each block that you solve has a reward. In practice, some blocks will
be orphaned, so the expected reward is slightly less than the nominal
reward. Each second that you delay publishing a block, the expected
reward drops somewhat.
On an infinite timeline, the total reward approaches the expected
reward. But reality is discrete, and zero tends to be a brick wall. If
you delay publishing a block, you will get either the nominal reward, or
zero, not some fraction in between. And if your personal random walk
involves an excursion through negative land, you may not stick around
long enough for it to come back.
Thus, a positive expected value is not sufficient for some strategy to
be a good one.
Peter Todd wrote:
> On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
>> You are ignoring the gambler's ruin. We do not operate on an
>> infinite timeline. If you find a big pool willing to try this,
>> please give me enough advance warning to get my popcorn ready.
> Gamblers ruin has nothing to do with it.
>
> At every point you want to evaluate the chance the other side will get
> ahead, vs. cashing in by just publishing the blocks you have. (or some
> of them) I didn't mention it in the analysis, but obviously you want to
> keep track of how much the blocks you haven't published are worth to
> you, and consider publishing some or all of your lead to the rest of the
> network if you stand to lose more than you gain.
>
> Right now it's a mostly theoretical attack because the inflation subsidy
> is enormous and fees don't matter, but once fees do start to matter
> things get a lot more complex. An extreme example is announce/commit
> sacrifices to mining fees: if I'm at block n+1, the rest of the network
> is at block n, and there's a 100BTC sacrifice at block n+2, I could
> easily be in a situation where I have zero incentive to publish my block
> to keep everyone else behind me, and just hope I find block n+2. If I
> do, great! I'll immediately publish to lock-in my winnings and start
> working on block n+3
>
>
> Anyway, my covert suggestion that pools contact me was more to hopefully
> strike fear into the people mining at a large pool and get them to
> switch to a small one. :) If everyone mined solo or on p2pool none of
> this stuff would matter much... but we can't force them too yet.
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------040109010407010309060007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Each block that you solve has a
reward. In practice, some blocks will be orphaned, so the
expected reward is slightly less than the nominal reward. Each
second that you delay publishing a block, the expected reward
drops somewhat.<br>
<br>
On an infinite timeline, the total reward approaches the expected
reward. But reality is discrete, and zero tends to be a brick
wall. If you delay publishing a block, you will get either the
nominal reward, or zero, not some fraction in between. And if
your personal random walk involves an excursion through negative
land, you may not stick around long enough for it to come back.<br>
<br>
Thus, a positive expected value is not sufficient for some
strategy to be a good one.<br>
<br>
Peter Todd wrote:<br>
</div>
<blockquote cite="mid:20131107043310.GA30788@savin" type="cite">
<pre wrap="">On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
</pre>
<blockquote type="cite">
<pre wrap="">You are ignoring the gambler's ruin. We do not operate on an
infinite timeline. If you find a big pool willing to try this,
please give me enough advance warning to get my popcorn ready.
</pre>
</blockquote>
<pre wrap="">
Gamblers ruin has nothing to do with it.
At every point you want to evaluate the chance the other side will get
ahead, vs. cashing in by just publishing the blocks you have. (or some
of them) I didn't mention it in the analysis, but obviously you want to
keep track of how much the blocks you haven't published are worth to
you, and consider publishing some or all of your lead to the rest of the
network if you stand to lose more than you gain.
Right now it's a mostly theoretical attack because the inflation subsidy
is enormous and fees don't matter, but once fees do start to matter
things get a lot more complex. An extreme example is announce/commit
sacrifices to mining fees: if I'm at block n+1, the rest of the network
is at block n, and there's a 100BTC sacrifice at block n+2, I could
easily be in a situation where I have zero incentive to publish my block
to keep everyone else behind me, and just hope I find block n+2. If I
do, great! I'll immediately publish to lock-in my winnings and start
working on block n+3
Anyway, my covert suggestion that pools contact me was more to hopefully
strike fear into the people mining at a large pool and get them to
switch to a small one. :) If everyone mined solo or on p2pool none of
this stuff would matter much... but we can't force them too yet.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040109010407010309060007--
|
