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
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 914CD957
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2016 13:09:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com
[62.13.148.101])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 61A90122
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Oct 2016 13:09:36 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u9HD9Xvf090323;
Mon, 17 Oct 2016 14:09:33 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u9HD9UeI077056
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 17 Oct 2016 14:09:31 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 5FB8B4012E;
Mon, 17 Oct 2016 13:05:18 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 4F96A207F6; Mon, 17 Oct 2016 09:09:27 -0400 (EDT)
Date: Mon, 17 Oct 2016 09:09:27 -0400
From: Peter Todd <pete@petertodd.org>
To: Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20161017130927.GA19897@fedora-21-dvm>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
<7939356.11nSWPlGYM@strawberry>
<22046ac7-df36-2e2a-759e-b3dd01601c59@gmail.com>
<2381760.VTJ5BOIlGi@strawberry>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline
In-Reply-To: <2381760.VTJ5BOIlGi@strawberry>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: f1181efe-946a-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwUUF1YAAgsB AmAbWlBeUFR7WmI7 bghPaBtcak9QXgdq
T0pMXVMcUQwQdRVk U2ceVR5ycgMIcXx0 bQg0X3FTXREsIFt0
RkgFCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXEzhc WB1FMVMXTA4FGSR0 bTE6RGl2VQ0eSios LgBnQl4B
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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] 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 13:09:40 -0000
--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 17, 2016 at 01:17:39PM +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote:
> > On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> > > Lets get back to the topic. Having a longer fallow period is a simple
> > > way to be safe. Your comments make me even more scared that safety is
> > > not taken into account the way it would.
> >=20
> > Can you please explain how having a longer grace period makes it any
> > safer? Once the fork reaches the LOCKED_IN status, the fork will become
> > active after the period is over. How does having a longer grace period
> > make this any safer besides just adding more waiting before it goes
> > active?=20
>=20
> As Marek wrote just minutes before your email came in; companies will not=
=20
> roll out their updates until it locks in. Peter Todd says the same thing.
> So your assumption that the lock-in time is the END of the upgrading is=
=20
> false. Thats only the case for miners.
>=20
> The entire point here is that SegWit is much bigger than just full nodes=
=20
> (including miner).
> An entire ecosystem of Bitconin will have a need to upgrade.
>=20
> I understand people saying that non-miners don't *need* to upgrade in ord=
er=20
> to avoid being kicked of the network, but truely, thats a bogus argument.
>=20
> People want to actually participate in Bitcoin and that means they need t=
o=20
> understand all of it. Not just see anyone-can-spend transactions.
> I think its rather odd to think that developers on this list can decide
> the risk profile that Bitcoin using companies or individuals should have.
Please don't misleadingly reference/quote me.
I made it quite clear in my last post that because segwit is a backwards
compatible soft-fork, the vast majority of code out there will not have to
change; my own OpenTimestamps being a good example. All I'll have to do to
prepare for segwit is upgrade the (pruned) full nodes that the OpenTimestam=
ps
servers depend on to determine what's the most-work valid chain, and in the
event I was concerned about compatibility issues, I could easily run my
existing nodes behind updated segwit-supporting (pruned) nodes.
Like most users, my OpenTimestamps code doesn't "fully understand" transact=
ions
at all - I rely on my full node to do that for me. What it does understand
about transactions and blocks remains the same in segwit. I can receive
transactions from segwit users with lite-client security without any action=
at
all, and full-node security once I upgrade my full nodes (or run them behind
upgraded nodes).
Your proposed alternative to segwit - flexible transactions - has none of t=
hese
beneficial properties. And as Matt Corallo reported, it's no-where near rea=
dy
for deployment: three buffer overflows in 80 lines of code is a serious
problem.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJYBM2EAAoJEGOZARBE6K+yCRQH/14iEWDZEKbaYslJxjJIBwp+
okkQImISH9/LQ0aG8F1E0TjmQ6WDu1WcvKgF0pO3/J0/VYljnVb4Ttn8vHE4UYkJ
VZfH2F0dwB8gSBeNQceW9YBP1EWL52cmc5XENk7aQaCfVD9iax9XdBE8MCYU/Pv1
mtJVXWl/dW2G6nBe0tGW5DPmS5pnDqOrSx2I8k2HzCakRg831Xp6Zd9kUCEt5Rfo
MgOPUuiJqT9FShhC8lU5MtgzvnuytzypFGKs7umtqStRSWyN5zOrd9EZEm2Owb6J
iC/mUMIj8soIteJXb4PaxcQvKImkdiYaRXC4oc8ZSJ/6RqkXb7HV78XixBrKfls=
=3vyT
-----END PGP SIGNATURE-----
--NzB8fVQJ5HfG6fxh--
|
