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: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB48C899
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 14:59:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3D4B6107
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 14:59:30 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 9557A38A0058;
Sat, 8 Apr 2017 14:59:14 +0000 (UTC)
X-Hashcash: 1:25:170408:bitcoin-dev@lists.linuxfoundation.org::z9i5B/bd2ORkYaNs:dAUD
X-Hashcash: 1:25:170408:jaejoon@gmail.com::wg=JnIWQ/O3Bf/sh:bgr8Z
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Jimmy Song <jaejoon@gmail.com>
Date: Sat, 8 Apr 2017 14:59:12 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
In-Reply-To: <CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201704081459.13185.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
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] 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: Sat, 08 Apr 2017 14:59:31 -0000
I think it might be important that the mandatory commitment expire as in=20
Greg's proposal - when we do eventually hardfork, it will be simpler to do =
in=20
a safe manner if such a commitment in the fake "old block" is not required.
I don't like your proposal because it allows ASICBoost. ASICBoost effective=
ly=20
makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry=
to=20
new mining chip manufacturers, and gives a larger advantage to the miners a=
ble=20
to make use of it. Instead, IMO we should fix the vulnerability exploited b=
y=20
ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change th=
e=20
PoW to an algorithm that is more ASIC-friendly.
That being said, I don't think I would oppose the proposal if it gained=20
notably better support than Segwit currently has (as yet another compromise=
),=20
and the above concerns were addressed (eg, Bitfury and Canaan state they ca=
n=20
compete using ASICBoost and the patents are licensed freely to everyone).
Luke
On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> I've gotten feedback from Adam Back that you actually don't need all 32
> bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
> the 32-bit version field, bits 16 to 23 are reserved for miners, the
> witness commitment stays as defined in BIP-141 except that it's now
> required. BIP9 then is modified so that bits 16 to 23 are now no longer
> usable.
>=20
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon@gmail.com> wrote:
> > Hey everyone, This is an idea that I had about Segwit and Gregory's
> > proposal from yesterday that I wanted to run by everyone on this list.
> > I'm not at all sure what this would mean for non-upgraded nodes on the
> > network and would like feedback on that. This is not a formal BIP as
> > it's a modification to a previously submitted one, but I'm happy to
> > formalize it if it would help.
> > ----------------------------------------
> > MotivationOne of the interesting aspects of Gregory Maxwell=E2=80=99s p=
roposal is
> > that it only precludes the covert version of ASICBoost. He specifically
> > left the overt version alone.
> >=20
> > Overt ASICBoost requires grinding on the version bits of the Block head=
er
> > instead of the Merkle Root. This is likely more efficient than the Merk=
le
> > Root grinding (aka covert ASICBoost) and requires way less resources
> > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> >=20
> > If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (Segwit) =
and add a
> > slight modification, this should, in theory, make ASICBoost a lot more
> > useful to miners and appeal to their financial interests.
> > The Modification
> >=20
> > Currently, the version bits (currently 4 bytes, or 32 bits) in the head=
er
> > are used for BIP9 signaling. We change the version bits to a nonce-space
> > so the miners can use it for overt ASICBoost. The 32-bits are now moved
> > over to the Coinbase transaction as part of the witness commitment. The
> > witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> > being used as the version bits in the block header previously. The
> > witness commitment becomes required as per Gregory Maxwell=E2=80=99s pr=
oposal.
> > Reasoning
> >=20
> > First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> > much more costly and overt ASICBoost is now encouraged.
> >=20
> > Second, we can make this change relatively quickly. Most of the Segwit
> > testing stays valid and this change can be deployed relatively quickly.
> >=20
> > Note on SPV clients
> >=20
> > Currently Segwit stores the witness commitment in the Coinbase tx, so
> > lightweight clients will need to get the Coinbase tx + Merkle proof to
> > validate segwit transactions anyway. Putting block version information =
in
> > the Coinbase tx will not impose an extra burden on upgraded light
> > clients.
|
