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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4DD4411
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 05:39:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43AF38B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 05:39:22 +0000 (UTC)
Received: from localhost ([::1]:43719 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.82) (envelope-from <jl2012@xbt.hk>) id 1ZI9E0-002TJq-GZ
for bitcoin-dev@lists.linuxfoundation.org;
Thu, 23 Jul 2015 01:39:20 -0400
Received: from 119.246.245.241 ([119.246.245.241]) by
server47.web-hosting.com (Horde Framework) with HTTP; Thu, 23 Jul 2015
05:39:20 +0000
Date: Thu, 23 Jul 2015 05:39:20 +0000
Message-ID: <20150723053920.Horde.NFnYiomFYphgmxoOpN4phA3@server47.web-hosting.com>
From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
<CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
<20150721130412.GA4551@savin.petertodd.org>
<20150721135846.GB13429@savin.petertodd.org>
<CADm_WcZDLfAwCJn8qc1Myp-OQhgPzx+A7b6nw8u9Z7mgQ6hveg@mail.gmail.com>
<B4B9D029-06BB-4049-966F-A5F9F34C68F4@petertodd.org>
In-Reply-To: <B4B9D029-06BB-4049-966F-A5F9F34C68F4@petertodd.org>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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, 23 Jul 2015 05:39:22 -0000
Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sorry, but I think you need to re-read my first message. What you've
> written below has nothing to do with what I actually said re: how
> you're BIP102 and associated pull-req doesn't measure miner consensus.
>
>
I think I have already answered this with my previous mail. If there
is consensus among major exchanges and merchants, the preference of
miners are not particularly relevant. A checkpoint could be
implemented in a decentralized way to make sure miners of the original
chain won't be able to overtake the new chain.
Bitcoin has no intrinsic value. Bitcoin has value because people are
willing to exchange it with something really valuable (e.g. a pizza;
or USD which could buy a pizza). If most bitcoin-accepting business
agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin,
and the original chain is just a dSHA256 alt-coin which one can't even
merge mine with BIP102. Switching to BIP102 is the only economically
viable choice for miners.
Having said that, a miner voting may still be useful. It is just to
make sure enough miners are ready for the change, instead of measuring
their consensus. For example, the new rule will be implemented 1) 1
week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever
happens first.
For SPV wallets, they have to strengthen their security model after
the BIP66 fork, anyway. They should be able to identify potential
consensus fork in the network and stop accepting incoming txs when it
is in doubt. My "version 0 flag block" proposal could be a good
generic way to indicate a hardfork to SPV wallets. (see my previous
email on this topic)
|
