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
140
141
142
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EF59AC25
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 04:47:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E8F2A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 04:47:45 +0000 (UTC)
Received: by mail-ua0-f179.google.com with SMTP id a1so54033554uaf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 21:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=VzhTx/P2L0KE2OM5mIhTni6kS7nM67GEZ16Y0iTOLsg=;
b=Qp6BV6eytZZIxKu9XgzFnjFSelS10NnJVhLRRu6soVsBVaOtmfNAUKaBrKHFZb5iU+
bPjIKnNAXzNOo+5cu8AzA2xlekwC5dA3HrrDIQBh3OomUEGgQUprh3T9xIxoBVdx2gI5
Cx3hbDLywluVfRv8yBj6yRXik5Eqi4Hui3uOJKft9yUSabx3RZMI2I9wyZGHvvU5EVfo
NGAWiz9omwFVhFnh317louNS6RYqCGfQc2oJhtmCgNpmOOkxVdoeMMOG2s7OXMI8ql12
qmDKQk0I0c789LxjPhWWWo31SP3OglujS669irLcaS+MhXrcyr2//zKN4Zfv1NSOLTnO
4siQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=VzhTx/P2L0KE2OM5mIhTni6kS7nM67GEZ16Y0iTOLsg=;
b=gR/2iahX3xXG31AwEL36XEEfr0RaYLiJcrYg6xksI2F1D36xsBSO+Ys+lGYcLDmBf9
NqZfdrv+DFZZmIoc0H9TEcn3yASM/HYIq/EtGqsxymRMp6RXm2o3yWWIYJV6Q035/UQ5
HiD05Nk4QyHzdJsUiVb4h+raAfqJuEz77YJWmeJtseTvGfdIBJdHxzoibgTNhmN98G+H
ZAz9gAgmOIexoxltNZNuwdQ7xIDwAB/CsdNLjc9ktwhgNhsxx/KA3MTffhpz69/jZWZN
lt7vAlegsuoYw7hh2ucgr6v5Wn9btGdObpoS+fCK05kIiclMPUfrmtp5ovtfA2c3tHY3
jfvQ==
X-Gm-Message-State: AN3rC/5z8dne/ay2HCLjkM4y9syQC81VvfdeiFeRbcq3eUvEkaIDqQFL
GnL1kiO81voem5x00zlra9v7IfSrdA==
X-Received: by 10.159.32.67 with SMTP id 61mr4331899uam.42.1492231664501; Fri,
14 Apr 2017 21:47:44 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.94.132 with HTTP; Fri, 14 Apr 2017 21:47:43 -0700 (PDT)
In-Reply-To: <CAAjy6kBHo9adDSVSn6mDqm07q8c+8FN_eOyOz8GS=sLzoj+02Q@mail.gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
<CAAjy6kAi6L9=4tgtay3m3YUk8SLs3NxD0JXp78TWmJXVMNfASQ@mail.gmail.com>
<CAAS2fgSekez6+o+9VU3rPSAyxuA+tzVfiyJJcx-_a8h0_Uq4fw@mail.gmail.com>
<CAAjy6kBHo9adDSVSn6mDqm07q8c+8FN_eOyOz8GS=sLzoj+02Q@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 15 Apr 2017 04:47:43 +0000
X-Google-Sender-Auth: SqavohFca0qVXKhxB37FMmBlI8E
Message-ID: <CAAS2fgTwfn0RzjxVe1R5FL842y2x-GK9LvcpxWuFpSmi2zy-Qg@mail.gmail.com>
To: Steven Pine <steven.pine@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 04:47:46 -0000
On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine <steven.pine@gmail.com> wrote:
> but segwit does
> have a 'time out' as defined in BIP 9 with the date of November 15th?
There is a technical requirement that BIP 9 bit allocations must have
a timeout so that a bit is not forever burned if a proposal is ever
abandoned (e.g. because something better came along before it
activated). This isn't a timeout for the proposal, but for the bit
assignment. If a proposal hasn't activated but there is still
interest it will just get a new bit (and can alternate back and forth
between a pair). This is a timeout of the bit, not the proposal.
It has to be setup this way because there is no real way to
communicate abandonment to old software, so a timeout must be set in
advance.
> Does core plan
"Core" doesn't plan on much of anything beyond the immediate pipeline
of activities, similar to other large open source collaboration, or
open standards development organizations. It isn't a company.
Individuals have plans about their own work which they may collaborate
in one place or another.
But allocating a new bit is how BIP9 works.
> meaning was every census change has gone through a core defined process (not
> counting the changes that occurred before there were BIPs and such), isn't
What is a "core defined process"? BIP _itself_ was created by someone
who, AFAICT, has never made a commit to Bitcoin Core. Numbers are
currently assigned, a nearly judgement-less administrative task, by
someone that authors competing fork of the software (Knots).
> it would seem like the first time census occurred outside core
Yet it was proposed on this list, had a BIP defined... if it got
eventually used it would presumably end up in the Bitcoin Core project
eventually... so what exactly is your definition of outside? Above you
seemed to be saying a BIP was not outside, but here you are saying
something documented as a BIP is outside?
If your preference is to not insult then it may be advisable to not
disregard distinctions which you do not understand as semantics. :) I
am not prone to arguing over semantics-- the continually binning in
almost all public collaboration as the work of some centralized entity
is really harmful to our community. The distinction is real, and not
semantics.
> To be clear, the fast and reckless part for you is the mechanism by which
> segwit could possibly be made active? Do you envision a means of segwit
> being made consensus that does not have 95% mining support?
Sure, and I said so directly in my message. I believe I was
adequately clear that my complaint about BIP148 is specifically that
it has forced orphaning of passive participants which can be easily
avoided but at the expense of actually needed users to adopt the
change.
For clarity, it could be summarized as: I would not classify BIP148 as
a user activated soft-fork but instead as "user enforced miner
soft-fork activation". The consequence of this is that it likely
cannot achieve low disruptiveness-- this limitation would be excusable
if we weren't aware of any alternative, but in this case we are and
the only relative downside of it is that users will need to upgrade
for it-- which should not be a problem in principle if we believe a
UASF is really user activated.
|
