summaryrefslogtreecommitdiff
path: root/4c/94b9f0e274289dbcc21196769192d39ceb5ade
blob: 874e3bfef3686716f571750c1d0645c716e08dab (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
Return-Path: <pavel.moravec@braiins.cz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5113740A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 08:33:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 439F2124
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 08:33:02 +0000 (UTC)
Received: by mail-wm0-f46.google.com with SMTP id w64so6931956wma.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 08 Apr 2017 01:33:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=braiins-cz.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-transfer-encoding;
	bh=3Og3EjjRLQToCx1O2AOXRinPIy3V8t3ktEoss7ALGrE=;
	b=Sm3KEmZ9SYOhsm5LB/iS9KFdmbQypUltWP2fcikGDrUqQHSsqAUnIx3HjUNxfVHmsa
	yvEgj31JiJZusGbqL2Spg06tRFor0UGWHIeJONPdroPCsce2fk7xL26tngw4a+Ynjcmo
	z1QPijNhoGiD/hBDja9VWXpbuyUpIIdD2JTubS4vTqCNvrrGS7uN8g24pbYIhf+1MjwS
	IOK2EvwDCTwdNDQ6qPsfPMLmYoUVVGIS33/FJnGQlNHHP0KMPWXfDn0vNXbc1t7fsfUv
	MgOZlPTkTF+wIGOFB9xhIAuSlBeupuNXlU6wFYlonJ6VxA4jct8J7bwbmd9X5YpKR8gb
	i5VA==
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:content-transfer-encoding;
	bh=3Og3EjjRLQToCx1O2AOXRinPIy3V8t3ktEoss7ALGrE=;
	b=hWAxYNKTiD+JshQNrVnqK9CQ7k+NwaKhIE9OmBHRVTHaDwDns477g3T2DnLWw8nWtX
	MCETlj112fZS3r8NORF181MRSzTQZrSdN27s+0a+S6fxpAY9hc87qU/IAUHHgblDVuaP
	Tmb4FJnZgiiagRnxRbNd9BLhaiktO0l56Ql6fd2Gc0CNIIJxvOCgEmNAudOZmPl0gaw6
	2CDUX2BmvpTiY/kJJO7ouOLF5vLQO6m7BQcz8zoeH7VFGHhcgSjT4F4DcEMupENQJuMc
	gl/dcbHAbWIhV9Hmftv0aBwtS/7eQ9CVt8m04l2oq424/G2NAM4aS9c8JJ+TZ3vXg8//
	RTCg==
X-Gm-Message-State: AN3rC/6jUtf+aXmoa/KOvEeboYAyPoeA4vpbcp3ARONxY9CEtvQOX973GF+lw1vVWeVqQiConCOWdJvkMHPVfg==
X-Received: by 10.28.178.17 with SMTP id b17mr2459624wmf.23.1491640381587;
	Sat, 08 Apr 2017 01:33:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.223.138 with HTTP; Sat, 8 Apr 2017 01:33:01 -0700 (PDT)
X-Originating-IP: [94.112.34.109]
In-Reply-To: <CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
	<CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
From: Pavel Moravec <pavel.moravec@braiins.cz>
Date: Sat, 8 Apr 2017 08:33:01 +0000
Message-ID: <CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com>
To: Jimmy Song <jaejoon@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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
X-Mailman-Approved-At: Sat, 08 Apr 2017 10:24:29 +0000
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 08:33:04 -0000

> Second, we can make this change relatively quickly. Most of the Segwit te=
sting stays valid and this change can be deployed relatively quickly.

It is true only for nodes software. Most of the world's mining
infrastructure (at least for pool mining) is not ready for such
change. Current version of Stratum protocol doesn't support block
version changing. A broad adoption would require:

- A new standard extension to the mining protocol (generally, we want
the hash rate to be free to change the used pool without efficiency
loss)
- Pool operators must change their software.
- All miners must update their firmware IF they have compatible
hardware (we know there is compatible hardware out there but
definitely not all of the currently used). The firmware can be changed
after the mining protocol extension is settled.

Until all miners update (firmware or hardware), the change encourages
large difference in mining efficiency. And IMO it gives another
advantage to large mining operations in general.

> But think of it this way, if some newer ASIC optimization comes up, would=
 you rather have a non-ASICBoosted hash rate to defend with or an ASICBoost=
ed hash rate? Certainly, the latter, being higher will secure the Bitcoin n=
etwork better against newer optimizations.

You make a strong assumption that the new optimization is not
compatible with overt ASICBoost. If it is compatible, ASICBoost
doesn't help you with "defending against" the new optimization at all.
And it can be the case that the new optimization is based on ASICBoost
so you can make the situation "worse" by allowing it.

> Certainly, if only one company made use of the extra nonce space, they wo=
uld have an advantage.

Can you explain why the reality should be significantly different? In
sufficiently near future.

> Is that patented in any jurisdiction, all jurisdictions or only certain j=
urisdictions? Would a patent granted for SHA256 in Swaziland be sufficient =
for Bitcoin to change the Proof of Work algorithm?

We don't have to deal with any such theoretical situation now. You
proposal goes in opposite direction, by adding support for patented
algorithm. I don't know myself what the possible legal implications
are (maybe only for a subset of miners) so I consider it as an
unnecessary risk. At least before some conclusive legal analysis says
differently.