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
|
Return-Path: <mus@musalbas.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 90FE3AAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2016 14:02:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from science.musalbas.com (science.musalbas.com [195.154.112.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FFB2148
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2016 14:02:18 +0000 (UTC)
Received: from [10.7.0.6] (unknown [10.7.0.6])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by science.musalbas.com (Postfix) with ESMTPSA id 7A4CC6A09B2;
Thu, 10 Mar 2016 14:02:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=musalbas.com;
s=mail; t=1457618536;
bh=2iBh4Kh9RQSpOuE/TEgkxqg/IWMJ30zUj5JpLjp+F+c=;
h=Subject:To:References:From:Date:In-Reply-To;
b=dmD+1ScSiC4rQeOZYKVEsX8VJYFytNJi0VFp1XMfAx52YpvUYCcrpGQIjhXOh4Nlb
krwpmkC0khXXf/LSPuXuG+1Inv4R0pxPTSDZEs3xpzXI8n4YH1hcOW4mFkT8NOUx6N
UgptXtZcegEP1f29lEnbClIAf33Pb1yB8oYDTw8s=
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
References: <201603081904.28687.luke@dashjr.org>
<56E0BFDC.5070604@musalbas.com> <201603100053.43822.luke@dashjr.org>
From: Mustafa Al-Bassam <mus@musalbas.com>
Message-ID: <56E17E67.9040508@musalbas.com>
Date: Thu, 10 Mar 2016 14:02:15 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <201603100053.43822.luke@dashjr.org>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
X-Mailman-Approved-At: Thu, 10 Mar 2016 15:51:17 +0000
Subject: Re: [bitcoin-dev] BIP 2 promotion to Final
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 10 Mar 2016 14:02:22 -0000
On 10/03/16 00:53, Luke Dashjr wrote:
> On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote:
>>> the soft-fork does not become Final for as long as such a hard-fork
>>> has potentially-majority support, or at most three months.
>> This wording is awkward. What is "potentially-majority"?
> A group that is large enough that it may constitute a majority.
> How can I reword this better/clearer?
"potentially has majority support"?
>
>>> A hard-fork BIP requires adoption from the entire Bitcoin economy,
>>> particularly including those selling desirable goods and services in
>>> exchange for bitcoin payments, as well as Bitcoin holders who wish to
>>> spend or would spend their bitcoins (including selling for other
>>> currencies) differently in the event of such a hard-fork.
>> What if one shop owner, for example, out of thousands, doesn't adapt the
>> hard-fork? It is expected, and should perhaps be encouraged, for a small
>> minority to not accept a hard fork, but by the wording of the BIP
>> ("entire Bitcoin economy"), one shop owner can veto a hard-fork.
> It's not the hard-fork they can veto (in this context, anyway), but the
> progression of the BIP Status field. However, one shop cannot operate in a
> vacuum: if they are indeed alone, they will soon find themselves no longer
> selling in exchange for bitcoin payments, as nobody else would exist willing
> to use the previous blockchain to pay them. If they are no longer selling,
> they cease to meet the criteria here enabling their veto.
I think in general this sounds like a good definition for a hard-fork
becoming active. But I can envision a situation where someone will try
to be annoying about it and point to one instance of one buyer and one
seller using the blockchain to buy and sell from each other, or set one up.
> Luke
|
