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: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C40F040C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 17:22:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com
[209.85.213.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 334C51A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 17:22:24 +0000 (UTC)
Received: by mail-vk0-f41.google.com with SMTP id z204so93410815vkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Apr 2017 10:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=2LLRpWUnTn+RFq9RPJaltts3Le3d2V9TJG96PRN4TwU=;
b=UBerMQ+F16bdtZ4Hrg2d+B5z/XrAl4oWA9Z4dNpXvze7SM3or7+Ri67VaAk6TPdND7
KOiJRWbWSZvZzDle1bWiNcCvXtCb2wenHq0x+8PjSQh0w2v9licemDNalQIuti2a1/W6
IevpiILaZ3Fi23d0ALxq7t/YAy7bamG9MVqP6NWaPMsWSH3UxpVRCNDOk+fkOt71hXTT
5OXUn86Obb63q86HWkEJ4wx4ML9BiZDq+6YfzB9vRqwVXVyK4+RDRF1KR9ZUoCFjIqcL
/Wz2Sh9HYX1gGc45x4msGOdHhjangQfb8qlJFBxo1+zdl8QVQAXQ6nF4RK/9ayJvGPfE
UrIg==
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=2LLRpWUnTn+RFq9RPJaltts3Le3d2V9TJG96PRN4TwU=;
b=O5R1Hu6f32y2vxbNFv/ltkA/mtC+gU9FiEeGXokNmK81rFoRAVrrk4gRTJr9AgEF8j
2alWAuR8YWoIb1LM3Bnebb3ERKTublBBNwcRwqHr7LGKp8/LNC8gCbbQowefmV0+c+EL
8BdAvKhzUCdmjulX39PIHgVyAKprHvig/uacCon9EXcMBRM5EkXRx0sdqfdZZs2eeOae
cLqnCNM/q7+d4G3fHR6DzP9/nodlolGX65vDAmStTYswHrsTQOOgUkp1ok330Mws8QIX
nvEGNPUZx/vHoaaJZuaHuJIW0EJQ3SpmSfYwrKd3+l9j5pEf7dybzsn4tEYaYqNfSrKq
hDjg==
X-Gm-Message-State: AFeK/H3yOCgeLfIMXqHZkNK0fm/F/eEsc8j6ASiBxBkjxxtp9V636mvp7qlK5VwIxPq4P/TquLd/ojKG7b4/cw==
X-Received: by 10.31.204.1 with SMTP id c1mr9320280vkg.100.1491672143203; Sat,
08 Apr 2017 10:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.151.136 with HTTP; Sat, 8 Apr 2017 10:22:22 -0700 (PDT)
In-Reply-To: <CABm2gDo+XreV1va2rrHrBCf9x-pcGWqjaQcn7ptRJ4jRE=N79g@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
<CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
<CABm2gDo+XreV1va2rrHrBCf9x-pcGWqjaQcn7ptRJ4jRE=N79g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 8 Apr 2017 19:22:22 +0200
Message-ID: <CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com>
To: Jimmy Song <jaejoon@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
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 17:22:24 -0000
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.
Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).
But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.
To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".
On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Praxeology Guy,
>
>> Why would the actual end users of Bitcoin (the long term and short term
>> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>
>
> Certainly, if only one company made use of the extra nonce space, they wo=
uld
> have an advantage. But think of it this way, if some newer ASIC optimizat=
ion
> comes up, would you rather have a non-ASICBoosted hash rate to defend wit=
h
> or an ASICBoosted hash rate? Certainly, the latter, being higher will sec=
ure
> the Bitcoin network better against newer optimizations.
>
>
> Why?
|
