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
|
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD6A194B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Apr 2017 14:34:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40F3A14F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Apr 2017 14:34:51 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id l7so97226300ioe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Apr 2017 07:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ZZDn48k2buJA+gaGU377/jJ8l0rjP5cedDHWawqH9xw=;
b=yCyzmeQk/o1br5HqXh/3qR4wKi4UFIA5AEojXRsX5XGFZaO0qGi+Zlr6gqN1EJ6ihc
WFE6vhCtnauhDNP/ScHCPdlgvCo27/KsuTXmUrlwirna+HPkshHZagta+Gj8i/8iyKR3
PpV7B3g85RK2QcKsvd6q+VJeG79WCHHnckq2PhW6H1H6+ByO+qayd32NkLMNXVDwNSu8
496cpuhWJdP8Jj2xRxyU/xo5aAF7N2c4hkjuIr9znqmE2XjTA0yTvDFTaecwMkyuI35K
Nsl2qqHSOHybLWxINb3uJb0deR/zsMbbLXKeRx3A0tRCKjmtBxZBj8dK6JRFlQNybZeT
SWoA==
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:cc;
bh=ZZDn48k2buJA+gaGU377/jJ8l0rjP5cedDHWawqH9xw=;
b=WBxchaYQdwS4n/hG+M2Tf6Usp0nHpNCpkOnkLa5ZznayD5b/cNJYTz2lFlmmUjyyiC
/226llhUa/h0gXmfhViZeu7VM7Zy1jXkOSh3AUvGULsErvRVgxLd7q2y6OCVTH3bjCxu
zFPVvuR2TLFrTNF2ADpIQadNrWUDIspfXrKKx+ZxGlDRCZH4lcZLGV9a662m4CwKxV1w
Qcrk/wmnMxk12Ndv6+VMAS26Z84UFngCokuxVoC7G9hK8L+OB5jmOGAUxhHXoM2qtb0o
MyhQToKpIyDKRJEa67ZtMUolXGaIoNsLoN23vaTpO+NaJTRKqnGjTUwL8bJINXfnMEG1
z42w==
X-Gm-Message-State: AN3rC/6yUZY1UH/O4oxhjEj8RqJL0pvL1r0DhnLyeyaCqTs162e52kOa
mJupR7qCp/xjogwEDuJzPYKFFNEZehzE
X-Received: by 10.36.0.145 with SMTP id 139mr9114249ita.98.1491834888396; Mon,
10 Apr 2017 07:34:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.202.193 with HTTP; Mon, 10 Apr 2017 07:34:47 -0700 (PDT)
In-Reply-To: <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
<CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Mon, 10 Apr 2017 07:34:47 -0700
Message-ID: <CA+KqGko1cWoe=31udzVSg8cdb2Do7CW4Gq_7WODsMOC=3Y1kTg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary=001a11c142109d92d3054cd0e031
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
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: Mon, 10 Apr 2017 14:34:51 -0000
--001a11c142109d92d3054cd0e031
Content-Type: text/plain; charset=UTF-8
On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term. I've heard the
> term "level playing field" bandied about quite a bit. And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware. Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
>
Whatever your hashing function the bottleneck for mining will be power.
Equihash and Cuckoo are serious attempts at making custom hardware have no
benefit over commodity hardware, but that's more about getting rid of
custom hardware manufacturers than it is about mining decentralization,
although arguably if successful it might let botnets back in, which would
improve decentralization. While those have been surprisingly successful at
resisting hardware so far, they might eventually fall as well, and if they
do they'll have even worse properties of centralizing around a mining
hardware manufacturer than sha256 does.
It would be much safer to go the other way, to a PoW function whose best
hardware implementation is particularly straightforward and well
understood. In that case it would be best to go with sha3. Sha3 also has
the benefit of using the sponge construction, which makes it particularly
resistant to asciboost-type attacks. It was picked out specifically because
its design from a security standpoint was particularly
confidence-inspiring, and in this case it actually makes a difference.
Arguably you could also go with blake2b, whose 1024 bit block size
completely obviates the asicboost concern entirely by cramming everything
into a single block. That also might have an even simpler design in
hardware than sha3, but a real expert would need to opine on that one.
--001a11c142109d92d3054cd0e031
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">On S=
un, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><br>Clearly a level-playing field=
is critical to keeping centralization from being a "defining feature&=
quot; of Bitcoin over the long term. =C2=A0 I've heard the term "l=
evel playing field" bandied about quite a bit. =C2=A0 And it seems to =
me that the risk of state actor control and botnet attacks is less than sta=
te-actor manipulation of specialized manufacturing of "SHA-256 forever=
" hardware. =C2=A0 Indeed, the reliance on a fairly simple hash seems =
less and less likely a "feature" and more of a baggage.<div><br><=
/div></div></blockquote><div><br></div><div>Whatever your hashing function =
the bottleneck for mining will be power. Equihash and Cuckoo are serious at=
tempts at making custom hardware have no benefit over commodity hardware, b=
ut that's more about getting rid of custom hardware manufacturers than =
it is about mining decentralization, although arguably if successful it mig=
ht let botnets back in, which would improve decentralization. While those h=
ave been surprisingly successful at resisting hardware so far, they might e=
ventually fall as well, and if they do they'll have even worse properti=
es of centralizing around a mining hardware manufacturer than sha256 does.<=
/div><div><br></div><div>It would be much safer to go the other way, to a P=
oW function whose best hardware implementation is particularly straightforw=
ard and well understood. In that case it would be best to go with sha3. Sha=
3 also has the benefit of using the sponge construction, which makes it par=
ticularly resistant to asciboost-type attacks. It was picked out specifical=
ly because its design from a security standpoint was particularly confidenc=
e-inspiring, and in this case it actually makes a difference. Arguably you =
could also go with blake2b, whose 1024 bit block size completely obviates t=
he asicboost concern entirely by cramming everything into a single block. T=
hat also might have an even simpler design in hardware than sha3, but a rea=
l expert would need to opine on that one.</div></div></div></div>
--001a11c142109d92d3054cd0e031--
|
