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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A946F256
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 22:59:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03E09A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 22:59:55 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 757C85FFC3;
Tue, 10 May 2016 22:59:54 +0000 (UTC)
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Tier Nolan <tier.nolan@gmail.com>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAE-z3OWvLqONwaN+608jBn9=q1yUvU4ggGrMpA8rE6qmjDQHtg@mail.gmail.com>
<CAKzdR-ou2FYjjxmRBLARhvfhHO-46weiMc2Q2f+GZf1E_JUEAg@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <573267E8.9050209@mattcorallo.com>
Date: Tue, 10 May 2016 22:59:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAKzdR-ou2FYjjxmRBLARhvfhHO-46weiMc2Q2f+GZf1E_JUEAg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Making AsicBoost irrelevant
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: Tue, 10 May 2016 22:59:56 -0000
Replies inline.
On 05/10/16 21:43, Sergio Demian Lerner via bitcoin-dev wrote:
-snip-
> But some ASIC companies already have cores that are better (on power,
> cost, rate, temperature, etc.) than competing companies ASICs. Why do
> you think a 10% improvement from AsicBoost is different from many of
> other improvements they already have (secretly) added? Maybe we (?)
> should only allow ASICs that have a 100% open source designs?
One is patented and requires paying a license fee to a group, or more
likely, ends up with it being impossible to import hardware from other
jurisdictions into the US/western world. The other requires more
investment in R&D, and over the long run, there is no guaranteed
advantage to such groups.
> If we change the protocol then the message to the ecosystem is that ASIC
> optimizations should be kept secret.
To some extent, this is the case, but there is a strong difference
between a guaranteed advantage enforced by the legal system and one that
is true due to intellectual superiority. In the long run, I am confident
the second will not remain the case. For example, AsicBoost was
independently discovered by at least two companies/individuals within a
year or two.
> It is fair to change the protocol
> because we don't like that certain ASIC manufacturer has better chips,
> if the chips are sold in the market and anyone can buy them? And what
> about using approximate adders (30% improvement), or dual rail
> asynchronous adders (also more than 10% improvement) ? How do we repair
> those?
As far as I'm aware neither of these are patented. Is this not the case?
> Disclaimer: I have stake in AsicBoost, but I'm not sure about this.
>
>
> On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> The various chunks in the double SHA256 are
>
> Chunk 1: 64 bytes
> version
> previous_block_digest
> merkle_root[31:4]
>
> Chunk 2: 64 bytes
> merkle_root[3:0]
> nonce
> timestamp
> target
>
> Chunk 3: 64 bytes
> digest from first sha pass
>
> Their improvement requires that all data in Chunk 2 is identical
> except for the nonce. With 4 bytes, the birthday paradox means
> collisions can be found reasonable easily.
>
> If hard forks are allowed, then moving more of the merkle root into
> the 2nd chunk would make things harder. The timestamp and target
> could be moved into chunk 1. This increases the merkle root to 12
> bytes in the 2nd chunk. Finding collisions would be made much more
> difficult.
>
> If ASIC limitations mean that the nonce must stay where it is, this
> would mean that the merkle root would be split into two pieces.
>
> On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> As part of the hard-fork proposed in the HK agreement(1) we'd
> like to make the
> patented AsicBoost optimisation useless, and hopefully make
> further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV
> compatible, but if it
> requires changes from SPV clients that's ok too. Also the fix
> this should be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> <http://petertodd.org>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
