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
|
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 240E7721
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 21:35:44 +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 7B94C137
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 21:35:43 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 860135FFBD;
Tue, 10 May 2016 21:35:41 +0000 (UTC)
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAE-z3OWvLqONwaN+608jBn9=q1yUvU4ggGrMpA8rE6qmjDQHtg@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <5732542B.20000@mattcorallo.com>
Date: Tue, 10 May 2016 21:35:39 +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: <CAE-z3OWvLqONwaN+608jBn9=q1yUvU4ggGrMpA8rE6qmjDQHtg@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 21:35:44 -0000
Yea, I think in any hardfork that we should be talking about, a part of
it should include 1) fix the version field so its a static constant, 2)
the merkle root becomes hash of the real block header 3) swap first 2
bytes of the merkle root with the timestamp's two high-order bits, 4)
swap the next 4 bytes of the merkle root with the difficulty field.
I believe this should be compatible with all existing ASICs, with the
exception, possibly, of some 21 Inc hardware. I believe this fixes
AsicBoost (without thinking about it tooo much, so please critique).
While this is somewhat nasty, the risks of AsicBoost and the precedent
that should be set necessitates a response, and it should be included in
any hardfork.
Matt
On 05/10/16 20:27, Tier Nolan via bitcoin-dev 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
