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
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9D595955
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 20:08:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 086F8120
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 20:08:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161])
by mx-out02.mykolab.com (Postfix) with ESMTPS id 0F9F062128
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 22:08:31 +0200 (CEST)
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 16 Oct 2016 22:08:29 +0200
Message-ID: <2028733.BSPBufMBT3@strawberry>
In-Reply-To: <157cee7d85f.d54d998f341542.5677728872543901935@xbt.hk>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
<9782389.Gd5V7OpbDZ@strawberry>
<157cee7d85f.d54d998f341542.5677728872543901935@xbt.hk>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 16 Oct 2016 20:13:41 +0000
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: Sun, 16 Oct 2016 20:08:34 -0000
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.
> Having 2 months or 2 weeks of grace period
> makes totally no difference in this regard. If anyone tried to use segwit
> tx during your proposed 2 months grace period, all those txs were still
> everyone-can-spent.
>
> All you are advocating is just stalling the process with no improvement in
> security.
I hope the above explains the actual security issue better.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
|
