summaryrefslogtreecommitdiff
path: root/95/8164215d4632687d283e056170419f837068ff
blob: d375d9853529a4a25e93fcc694d599c2c87fca5b (plain)
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
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 3B8EE94F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Oct 2016 03:46:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
	[74.201.84.163])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E561E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Oct 2016 03:46:20 +0000 (UTC)
Received: from mail.zoho.com by mx.zohomail.com
	with SMTP id 1476675971736667.6857896593053;
	Sun, 16 Oct 2016 20:46:11 -0700 (PDT)
Date: Mon, 17 Oct 2016 11:46:11 +0800
From: Johnson Lau <jl2012@xbt.hk>
To: "Tom Zander" <tomz@freedommail.ch>, 
	"bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <157d0bf2a93.e5a7dc16354163.8523890663577544011@xbt.hk>
In-Reply-To: <2028733.BSPBufMBT3@strawberry>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<9782389.Gd5V7OpbDZ@strawberry>
	<157cee7d85f.d54d998f341542.5677728872543901935@xbt.hk>
	<2028733.BSPBufMBT3@strawberry>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	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] Start time for BIP141 (segwit)
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: Mon, 17 Oct 2016 03:46:22 -0000




 ---- On Mon, 17 Oct 2016 04:08:29 +0800 Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ---- 
 > On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote: 
 > > > Honestly, if the reason for the too-short-for-safety timespan is that 
 > > > you 
 > > > want to use BIP9, then please take a step back and realize that SegWit 
 > > > is a contriversial soft-fork that needs to be deployed in a way that is 
 > > > extra safe because you can't roll the feature back a week after 
 > > > deployment. All transactions that were made in the mean time turn into 
 > > > everyone-can- spent transactions. 
 > >  
 > > No one should use, nor anyone is advised to use, segwit transactions 
 > > before it is fully activated.  
 >  
 > Naturally, I fully agree. 
 >  
 > It seems I choose the wrong words, let me rephrase; 
 >  
 > You can't roll the SegWit back a week after people are allowed to send  
 > segwit transactions (lock-in + fallow period). All transactions that were  
 > made in the mean time turn into everyone-can- spent transactions. 
 > 
 > Because the network as a whole and any implementation is unable to roll back  
 > in an environment where SegWit is a contriversial soft-fork, it is super  
 > important to make sure that it is properly supported by all miners. This  
 > takes time and the risk you take by pushing this is that actual real people  
 > loose actual real money because of the issue I outlined inthe previous  
 > paragraph. 
 
It would only happen if a large proportion of miners are false-signalling, like how BU did with BIP109 and forked your Classic away on testnet

But this is a egg-and-chicken problem and extending the grace period would not have any improvement. Until the rules are fully activated, it is totally impossible to tell if some miners are false signalling. The only method to prevent it, as usual, is the majority of miners will orphan the blocks of malicious miners. Like in the last year, some miners did not correctly implement BIP66 and got punished by losing many blocks.

If your are suggesting >51% of miners may false-signal (like in the BIP109 case), we already have a much bigger problem.

If people are really worrying about that, I would advise them not to use segwit extensively at the beginning, and wait for at least a week to see any sign of false signalling (which will be shown as invalid orphaned blocks). If the grace period was 2 weeks, they need to wait for 3 weeks; if the grace period was 2 months, they need to wait for 2 months and a week. Pre-activation consensus-imposed grace period could never replace post-activation self-imposed observation period