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
|
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 <mh.in.england@gmail.com>) id 1X3LYu-0002u3-Ht
for bitcoin-development@lists.sourceforge.net;
Sat, 05 Jul 2014 08:43:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X3LYt-0007vm-JO
for bitcoin-development@lists.sourceforge.net;
Sat, 05 Jul 2014 08:43:12 +0000
Received: by mail-oa0-f53.google.com with SMTP id l6so2578130oag.40
for <bitcoin-development@lists.sourceforge.net>;
Sat, 05 Jul 2014 01:43:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.97.230 with SMTP id ed6mr580930oeb.81.1404549786070; Sat,
05 Jul 2014 01:43:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Sat, 5 Jul 2014 01:43:05 -0700 (PDT)
In-Reply-To: <53B714A8.1080603@codehalo.com>
References: <10566815.3CllqoMfON@momentum> <53B6DB38.7010709@jerviss.org>
<CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com>
<53B714A8.1080603@codehalo.com>
Date: Sat, 5 Jul 2014 10:43:05 +0200
X-Google-Sender-Auth: dX0gggW6nTk1b3OygPr4dBgaTsM
Message-ID: <CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Randi Joseph <randi@codehalo.com>
Content-Type: multipart/alternative; boundary=089e0115f46e11759e04fd6e3b4f
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1X3LYt-0007vm-JO
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: Sat, 05 Jul 2014 08:43:12 -0000
--089e0115f46e11759e04fd6e3b4f
Content-Type: text/plain; charset=UTF-8
>
> 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.
--089e0115f46e11759e04fd6e3b4f
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">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 "r=
unner up" because hashing is progress free. It's unintuitive and o=
ften trips people up. There's no concept that everyone is 95% of the wa=
y to finding a solution and then someone pips you to the post. It's mor=
e 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 f=
or shares which don't quite meet the difficulty target but almost do. S=
o the question is how can we implement pools which have this reward structu=
re (which obviously works well) without miners simultaneously giving up the=
ir right to block creation either due to technical problems or sheer lazyne=
ss.</div>
</div></div></div>
--089e0115f46e11759e04fd6e3b4f--
|
