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
|
Return-Path: <mail@chrisacheson.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BD56B7D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 07:46:50 +0000 (UTC)
X-Greylist: delayed 20:54:02 by SQLgrey-1.7.6
Received: from homiemail-a79.g.dreamhost.com (sub5.mail.dreamhost.com
[208.113.200.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A3B3DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 07:46:49 +0000 (UTC)
Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id 83CF66002B13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 00:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=chrisacheson.net; h=
subject:to:references:from:message-id:date:mime-version
:in-reply-to:content-type:content-transfer-encoding; s=
chrisacheson.net; bh=3jeVBpW11Es8Fo4kln/7W8TMFyk=; b=EnZnqJwJ4qS
AlBBhOCzhM3jtMdkuWYZIVqQx0YTa9vlw6JZL+jayQNtGZQ2oPG1fZIoiLQHwmip
e6TtdGrFOckY56/nyehGio/3CaBqkxaz3eTwT1yQrMeAGC9GJ1nqCxygOzPIIAS6
Jem2E6lQ6i21DXDAXPezXmkCCP+VzaYk=
Received: from [192.168.1.2] (unknown [104.153.30.236])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: mail@chrisacheson.net)
by homiemail-a79.g.dreamhost.com (Postfix) with ESMTPSA id 0F0D16002B12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 00:46:48 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
<E7A3E345-15C9-4C4C-B3D7-C75634243430@gmail.com>
<CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
From: Chris Acheson <mail@chrisacheson.net>
Message-ID: <2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net>
Date: Sat, 15 Apr 2017 03:46:47 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
X-Mailman-Approved-At: Sat, 15 Apr 2017 11:51:19 +0000
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
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, 15 Apr 2017 07:46:50 -0000
On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote:
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject
> the blocks of passive participants, due to avoidable design
> limitations-- I can't help but feel that you don't even care to
> understand the concern I was bringing up. :(
Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is safer than just
considering the fork active on the flag date.
Unless we have majority miner support for the fork, we have to assume
that a chain split will occur at some point. With the orphaning
approach, we know exactly when that will be, and can plan around it.
Miners know that they need to upgrade by the flag date in order to get
paid. We even have an opportunity to back out if it looks like we don't
have enough economic support.
With the non-orphaning approach, the split won't occur until someone
chooses to craft a malicious block (short bitcoin; rent hash power;
profit). We don't know when that will be, so we can't plan around it.
Some nodes and miners will assume it won't happen at all. When it
happens, our responses to it will be clumsy, uncoordinated, and likely
panicked.
While the orphaning approach is potentially disruptive to miners, it is
necessarily so in order to minimize disruption to users. In general,
users should be prioritized over miners. The point of Bitcoin is to have
secure, digital money that we can *use*, not to enable people to earn
money from running busy-work computations.
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
I have scrutinized the strategy of BIP148 a fair bit. I was initially
opposed to it, but after Bitfury showed their support, and especially
after the Asicboost revelation, I think it has solid potential to
succeed. It would be a waste not to at least attempt to organize around
it. If it turns out that we can't get the necessary support in time, we
can abandon the effort and reassess our options.
|
