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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <randi@codehalo.com>) id 1X3wvI-0000rt-LW
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Jul 2014 00:36:48 +0000
X-ACL-Warn:
Received: from smtp132.ord.emailsrvr.com ([173.203.6.132])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1X3wvG-0005pE-NN
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Jul 2014 00:36:48 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp13.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id
EC0DC1800F0; Sun, 6 Jul 2014 20:20:39 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp13.relay.ord1a.emailsrvr.com (Authenticated sender:
randi-AT-codehalo.com) with ESMTPSA id 9A9631800E8;
Sun, 6 Jul 2014 20:20:39 -0400 (EDT)
Message-ID: <53B9E7D6.2050703@codehalo.com>
Date: Sun, 06 Jul 2014 20:20:38 -0400
From: Randi Joseph <randi@codehalo.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <10566815.3CllqoMfON@momentum> <53B6DB38.7010709@jerviss.org> <CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com> <53B714A8.1080603@codehalo.com>
<CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
In-Reply-To: <CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010107020505020608000400"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1X3wvG-0005pE-NN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ASIC-proof mining
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: Mon, 07 Jul 2014 00:36:48 -0000
This is a multi-part message in MIME format.
--------------010107020505020608000400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Thanks Mike.
Indeed, I am aware of current approach, which is why I was suggesting
this as an alternative.
I haven't thought about it enough, and perhaps it was too radical a
rethinking - just wanted to see what the smarter minds thought.
Thanks again.
-Randi
On 7/5/14, 4:43 AM, Mike Hearn wrote:
>
> Is it possible instead to allocate a portion of the reward to " a # of
> runner up(s)" even though the runner-up(s) block will be orphaned?
>
>
> There's really no concept of a "runner up" because hashing is progress
> free. It's unintuitive and often trips people up. There's no concept
> that everyone is 95% of the way to finding a solution and then someone
> pips you to the post. It's more like playing the lottery over and over
> again. Doesn't matter how many times you did it before, the next time
> your chances are the same.
>
> A better concept is of rewarding "near miss" solutions which is what
> we already do of course, via pools, which pay you for shares which
> don't quite meet the difficulty target but almost do. So the question
> is how can we implement pools which have this reward structure (which
> obviously works well) without miners simultaneously giving up their
> right to block creation either due to technical problems or sheer
> lazyness.
--------------010107020505020608000400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thanks Mike.<br>
<br>
Indeed, I am aware of current approach, which is why I was
suggesting this as an alternative. <br>
I haven't thought about it enough, and perhaps it was too radical
a rethinking - just wanted to see what the smarter minds thought.<br>
<br>
Thanks again.<br>
<br>
-Randi<br>
<br>
On 7/5/14, 4:43 AM, Mike Hearn wrote:<br>
</div>
<blockquote
cite="mid:CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote">Is it possible instead to
allocate a portion of the reward to " a # of<br>
runner up(s)" even though the runner-up(s) block will be
orphaned?<br>
</blockquote>
<div><br>
</div>
<div>There's really no concept of a "runner up" because
hashing is progress free. It's unintuitive and often trips
people up. There's no concept that everyone is 95% of the
way to finding a solution and then someone pips you to the
post. It's more like playing the lottery over and over
again. Doesn't matter how many times you did it before,
the next time your chances are the same.</div>
<div><br>
</div>
<div>A better concept is of rewarding "near miss" solutions
which is what we already do of course, via pools, which
pay you for shares which don't quite meet the difficulty
target but almost do. So the question is how can we
implement pools which have this reward structure (which
obviously works well) without miners simultaneously giving
up their right to block creation either due to technical
problems or sheer lazyness.</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------010107020505020608000400--
|
