summaryrefslogtreecommitdiff
path: root/bd/5d42d6991bf2413ecc17f2db3a44cf244a7e15
blob: 8f980f8ac1e2c2bb816c22381391a56c36de5586 (plain)
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
Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6476FA48
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 12:13:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
	[209.85.128.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BBA58AD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 12:13:27 +0000 (UTC)
Received: by mail-wr0-f170.google.com with SMTP id w11so54957825wrc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Apr 2017 05:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=vNWvL19ljAPn0xkEF38G5xlFM9bbIuhd+VdwyP8Vpiw=;
	b=QYSsed88nR2h8RXQ4s+i3LA2CD24pugxm4IwZZIdFbeF/mpOIzpdFx3hlxTJVYpHQg
	jblKbXnZbp2pBbGFTsm9GhSXODT6bW2jmKad9VV7IQdCGh/ARsCHUQuk1vb34uJJ5NVy
	Vvq4hAoUQkr4Mzu01xTx72E4PvHbxmOoZf0MU3VzC/+n+X0AnKuXJrFpSOFmIM4mzT64
	0N94Nnt5BEDyqIwQj73eE8toUQ+c6IKiyIsaw0f8jH20YEOKXdWw1Quj4TcF6PkNaHRX
	wqjtlu4VnvOgRRBBcYbRJeQw6vavRw7qVoWzHncNDW4cmklFg2BPW1J+XHoggad4SHUg
	8TWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=vNWvL19ljAPn0xkEF38G5xlFM9bbIuhd+VdwyP8Vpiw=;
	b=A6KBuwKFGrxBeI0XK/sNsQSow8aZMIy5FU+0pygKM8tVRtm7xryvn7aWaZsUyx0+51
	6yMhNYiULGfRmFN9qqeRnZ3incfa9RNjPQ5XmviSo9YIp5JHuAneTDnufK/862DgvHbg
	bp7/k+oG6fQKm+cXaTwi+y6xdQPHr6+O68acCp1CMg1pQ20g2QSqztGd2s2sy++QpHFj
	Ygrz15N9SNbD2gIuQiLKslDVODaMgKoKYoeB30Ud+1MKjbeixX4Gew0pWGojyr7aVhi2
	g34W7L8Zo1pjg/zTSGprjIJo00aKZ2p2B1cIXHgOBEdB6tRcHNnJdv0ETE9QrHLPGZeZ
	YFcg==
X-Gm-Message-State: AFeK/H3KXw/jfF0pFiwHuJ6FcJwXXNY/AOsqxFIY7+6C+1VDxr8SWllu/cgUdkPvVBWZ46/S32b8ShqkYEIVSg==
X-Received: by 10.28.97.2 with SMTP id v2mr22464986wmb.88.1491480804788; Thu,
	06 Apr 2017 05:13:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.9 with HTTP; Thu, 6 Apr 2017 05:13:23 -0700 (PDT)
In-Reply-To: <hGMlexjBJD3vlKg-_mmzAc6Qrth3zfL0hd5hfKllNHkgr4FQzXnuawXizgCFu-5d_cBs6zxwI4LxNNr-nMaZYl1gFzU8XU3sW2TwRQF1PdU=@protonmail.com>
References: <MWHPR18MB13594C8DE78A393E089660AECD0D0@MWHPR18MB1359.namprd18.prod.outlook.com>
	<hGMlexjBJD3vlKg-_mmzAc6Qrth3zfL0hd5hfKllNHkgr4FQzXnuawXizgCFu-5d_cBs6zxwI4LxNNr-nMaZYl1gFzU8XU3sW2TwRQF1PdU=@protonmail.com>
From: David Vorick <david.vorick@gmail.com>
Date: Thu, 6 Apr 2017 08:13:23 -0400
Message-ID: <CAFVRnyrQPRj_aLtovxoAqHmDJb5Jh7nm1YvCx7p5QWBFBfXrRA@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114a4c868f145f054c7e6f29
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
 Bitcoin POW function
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 12:13:28 -0000

--001a114a4c868f145f054c7e6f29
Content-Type: text/plain; charset=UTF-8

>
> Another thing that could be done is increase the number of times SHA256 is
> performed... but now we are really talking about altering the PoW
> algorithm.  Correct me if I'm wrong: The more number of times its
> performed, the less any patent-able pre or post calculation
> skipping/caching have an effect on efficiency.
>

The more complex that the PoW algorithm is, the more likely it is that
someone finds a unique and special method for optimizing it that they are
able to patent. And the more difficult it is to create specialized hardware
to run that algorithm, meaning that there will be fewer players who are
able to do so profitably (higher fixed costs).

If you want to talk about changing the PoW algorithm, you really want to be
looking to simplify it so that it's more obvious (not that you can ever be
completely sure) that there are no hidden or unexpected optimizations that
someone could patent.

We can even do a lot better than SHA. Cryptographic hash functions need to
be collision resistant, and collision resistance is the property that
usually breaks. Preimage resistance and partial preimage resistance (and
second preimage resistance) is generally easier to protect - to the best of
our knowledge, md5 would actually still be a secure PoW function today.

It's bitterly ironic to me that so much research and effort has been put
into making asic-resistant PoW algorithms when in the long run
asic-resistance only leads to problems like these - single parties who have
found significant optimizations and not shared them, completely destroying
any chance of a level playing field and giving themselves a centralized
monopoly - a result that is supremely unhealthy for the rest of the
community.

--001a114a4c868f145f054c7e6f29
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"><div>Another thing that could be done is increas=
e the number of times SHA256 is performed... but now we are really talking =
about altering the PoW algorithm.=C2=A0 Correct me if I&#39;m wrong: The mo=
re number of times its performed, the less any patent-able pre or post calc=
ulation skipping/caching have an effect on efficiency.</div></blockquote><d=
iv><br></div><div>The more complex that the PoW algorithm is, the more like=
ly it is that someone finds a unique and special method for optimizing it t=
hat they are able to patent. And the more difficult it is to create special=
ized hardware to run that algorithm, meaning that there will be fewer playe=
rs who are able to do so profitably (higher fixed costs).<br><br></div><div=
>If you want to talk about changing the PoW algorithm, you really want to b=
e looking to simplify it so that it&#39;s more obvious (not that you can ev=
er be completely sure) that there are no hidden or unexpected optimizations=
 that someone could patent.<br><br></div><div>We can even do a lot better t=
han SHA. Cryptographic hash functions need to be collision resistant, and c=
ollision resistance is the property that usually breaks. Preimage resistanc=
e and partial preimage resistance (and second preimage resistance) is gener=
ally easier to protect - to the best of our knowledge, md5 would actually s=
till be a secure PoW function today.<br><br></div><div>It&#39;s bitterly ir=
onic to me that so much research and effort has been put into making asic-r=
esistant PoW algorithms when in the long run asic-resistance only leads to =
problems like these - single parties who have found significant optimizatio=
ns and not shared them, completely destroying any chance of a level playing=
 field and giving themselves a centralized monopoly - a result that is supr=
emely unhealthy for the rest of the community.<br></div></div></div></div>

--001a114a4c868f145f054c7e6f29--