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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2744D36
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2016 16:44:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9DC5C184
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2016 16:44:49 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id E3F1E38A2C8D;
Thu, 10 Mar 2016 16:44:01 +0000 (UTC)
X-Hashcash: 1:25:160310:mus@musalbas.com::b0VdIpL7Ea4t3+BE:dKhST
X-Hashcash: 1:25:160310:bitcoin-dev@lists.linuxfoundation.org::7/gbV9FREKkcSSRj:b=Q8D
From: Luke Dashjr <luke@dashjr.org>
To: "Mustafa Al-Bassam" <mus@musalbas.com>
Date: Thu, 10 Mar 2016 16:43:59 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; )
References: <201603081904.28687.luke@dashjr.org>
<201603100053.43822.luke@dashjr.org>
<56E17E67.9040508@musalbas.com>
In-Reply-To: <56E17E67.9040508@musalbas.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201603101644.00799.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 16:45:58 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
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 16:44:50 -0000
On Thursday, March 10, 2016 2:02:15 PM Mustafa Al-Bassam wrote:
> On 10/03/16 00:53, Luke Dashjr wrote:
> > On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote:
> >>> 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.
In this scenario, it would seem the previous Bitcoin is alive any working, and
that the hard-fork has failed. How to resolve such a split is outside the
scope of the BIP process IMO.
Luke
|
