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
|
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 106E41118
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 16:53:09 +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 94DA389
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 16:53:08 +0000 (UTC)
Received: from localhost ([::1]:36641 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZgbfX-0002XI-HW; Mon, 28 Sep 2015 12:52:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 28 Sep 2015 12:52:51 -0400
From: jl2012@xbt.hk
To: Mike Hearn <hearn@vinumeris.com>
In-Reply-To: <CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
<20150928150543.GB28939@savin.petertodd.org>
<CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com>
Message-ID: <8461c6195ca65ce7355f693fa24bb177@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Mon, 28 Sep 2015 16:53:09 -0000
Mike Hearn via bitcoin-dev 於 2015-09-28 11:38 寫到:
> My point about IsStandard is that miners can and do bypass it,
> without expecting that to carry financial consequences or lower the
> security of other users. By making it so a block which includes
> non-standard transactions can end up being seen as invalid, you are
> increasing the risk of accidents that carry financial consequences.
Bypassing IsStandard should be considered as an "expert mode". The
message should be "don't bypass it unless you understand what you are
doing".
By the way, miners are PAID to protect the network. It is their greatest
responsibility to follow the development and keep their software up to
date.
> How do ordinary Bitcoin users benefit from this rollout strategy? Put
> simply, what is the point of this whole complex soft fork endeavour?
Let me try to answer this question. Softfork is beneficial to non-mining
full nodes as they will follow the majority chain. In the case of a
hardfork (e.g. BIP101), non-upgrading full nodes will insist to follow
the minority chain. (unless you believe that all non-miner should use an
SPV client)
Put it in a different angle. In a softfork, the new fork is a persistent
95% attack against the old fork, which will force all in-cooperating
miners to join (or leave). In a hardfork, however, there is no mechanism
to stop the old fork and we may have 2 chains co-exist for a long time.
Although it is not mentioned in the whitepaper, the ability to softfork
is a feature of Bitcoin. Otherwise, we won't have these OP_NOPs and the
original OP_RETURN.
|
