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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DA2E7721
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 00:54:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5C234106
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 00:54:44 +0000 (UTC)
Received: from [192.168.0.136] (1-64-179-042.static.netvigator.com
[1.64.179.42]) (authenticated bits=0)
by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tB90sdcf015976
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 16:54:41 -0800
Content-Type: multipart/signed;
boundary="Apple-Mail=_C1692F82-5447-4EE8-A6D5-47BC12BF9D74";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <201512082348.54788.luke@dashjr.org>
Date: Wed, 9 Dec 2015 08:54:38 +0800
Message-Id: <52A2BDFA-FEEC-459F-A3CB-07F3DFAD0732@toom.im>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<5666FD8D.8050201@openbitcoinprivacyproject.org>
<2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
<201512082348.54788.luke@dashjr.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVYUBULRXZBrYZuxV/Dy5xtTRzmwILCRYq51mt6YmQYJTUIRHnq8tlUj6ICYcYjJidwJPqKLy0yzXJ6Rop37Rd1f
X-Sonic-ID: C;XhLFbA+e5RGatsgxU3XIUw== M;+DQgbg+e5RGatsgxU3XIUw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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] Capacity increases for the Bitcoin system.
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: Wed, 09 Dec 2015 00:54:45 -0000
--Apple-Mail=_C1692F82-5447-4EE8-A6D5-47BC12BF9D74
Content-Type: multipart/alternative;
boundary="Apple-Mail=_9D8289E2-6624-466F-B0ED-895A20847040"
--Apple-Mail=_9D8289E2-6624-466F-B0ED-895A20847040
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Dec 9, 2015, at 7:48 AM, Luke Dashjr <luke@dashjr.org> wrote:
> How about we pursue the SegWit softfork, and at the same time* work on =
a
> hardfork which will simplify the proofs and reduce the kludgeyness of =
merge-
> mining in general? Then, if the hardfork is ready before the softfork, =
they
> can both go together, but if not, we aren't stuck delaying the =
improvements of
> SegWit until the hardfork is completed.
So that all our code that parses the blockchain needs to be able to find =
the sigwit data in both places? That doesn't really sound like an =
improvement to me. Why not just do it as a hard fork? They're really not =
that hard to do.
--Apple-Mail=_9D8289E2-6624-466F-B0ED-895A20847040
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Dec 9, 2015, at 7:48 AM, Luke =
Dashjr <<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;">How about we pursue the SegWit =
softfork, and at the same time* work on a<span =
class=3D"Apple-converted-space"> </span></span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">hardfork which will simplify the proofs and reduce the =
kludgeyness of merge-</span><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;">mining in general? Then, if the =
hardfork is ready before the softfork, they<span =
class=3D"Apple-converted-space"> </span></span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">can both go together, but if not, we aren't stuck delaying =
the improvements of<span =
class=3D"Apple-converted-space"> </span></span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">SegWit until the hardfork is completed.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"></blockquote></div><br><div>So =
that all our code that parses the blockchain needs to be able to find =
the sigwit data in both places? That doesn't really sound like an =
improvement to me. Why not just do it as a hard fork? They're really not =
that hard to do.</div></body></html>=
--Apple-Mail=_9D8289E2-6624-466F-B0ED-895A20847040--
--Apple-Mail=_C1692F82-5447-4EE8-A6D5-47BC12BF9D74
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWZ3vPAAoJEIEuMk4MG0P1cWgIAIl1d2LitOT2jzLCakyNbiMW
tT4nli0q8b9nCWgISpsLCSRMN7jbEQNpjFr8XbsZleT8hEdO77UvjudwfVgFRPF5
mwbyirP2b4BMXW1515VVex7XZ9XRwBPvHqCgLAvjsYPgfWGQq2B9C07VY9VEBQLq
PiiYEt0vgFQwSjAn/FRueP8756GLinSmUKZYPx7Cqdd3vpWEwoefk0O23ghLFEVn
sDXMCnbZqLKNyq2jcM3afnlptDNBwtuhRKyjCmZMKGFOzUGmXw4jzYqE22Bhzlen
pM29ZnJ2XWPmS7t7aYtyQeUnBfwXJ//iAwxqv1isXse+Kn4/Da+om/bV5UIwd7I=
=FmOP
-----END PGP SIGNATURE-----
--Apple-Mail=_C1692F82-5447-4EE8-A6D5-47BC12BF9D74--
|
