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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eugen@leitl.org>) id 1X31bA-0006Sc-Ov
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Jul 2014 11:24:12 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of leitl.org
designates 164.177.174.8 as permitted sender)
client-ip=164.177.174.8; envelope-from=eugen@leitl.org;
helo=leitl.org;
Received: from v8.ativel.com ([164.177.174.8] helo=leitl.org)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1X31b9-00072Q-1P
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Jul 2014 11:24:12 +0000
Received: by leitl.org (Postfix, from userid 1000)
id 20595540F7F; Fri, 4 Jul 2014 13:08:34 +0200 (CEST)
Date: Fri, 4 Jul 2014 13:08:34 +0200
From: Eugen Leitl <eugen@leitl.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20140704110833.GM26986@leitl.org>
References: <10566815.3CllqoMfON@momentum>
<53B687BB.9010103@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53B687BB.9010103@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.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 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1X31b9-00072Q-1P
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: Fri, 04 Jul 2014 11:24:12 -0000
On Fri, Jul 04, 2014 at 06:53:47AM -0400, Alan Reiner wrote:
> Something similar could be applied to your idea. We use the hash of a
> prevBlockHash||nonce as the starting point for 1,000,000 lookup
> operations. The output of the previous lookup is used to determine
> which block and tx (perhaps which chunk of 32 bytes within that tx) is
> used for the next lookup operation. This means that in order to do the
> hashing, you need the entire blockchain available to you, even though
> you'll only be using a small fraction of it for each "hash". This might
> achieve what you're describing without actually requiring the full 20 GB
> of reading on ever hash.
Anything involving lots of unpredictable memory accesses to a large
chunk of fast memory is unASICable. That data vector could be derived
by the same means as an one time pad, and loaded and locked into
memory after boot. If you make it large enough it won't profit from
embedded RAM bandwidth/speedup. The only way to speed up would be clustering,
which doesn't offer economies of scale.
|
