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
|
Return-Path: <digitsu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1FCEFDDD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Dec 2015 05:13:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com
[209.85.192.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 771BBE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Dec 2015 05:13:50 +0000 (UTC)
Received: by qgz52 with SMTP id 52so26103845qgz.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 21:13:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:mime-version:message-id:in-reply-to:references:from:to:cc
:subject:content-type;
bh=VByX4tj4HJ6EEYMS6IVX/RXKFR0QyUXGFkd3YbwK4tY=;
b=D/8xTjdQKybfE5Pin2BiTlBWkBShxuDB67sP1ZxVl1jEZZoHjWEh2jaZL53dNcwKmL
Mzhe8EpBudeJ2pZ+MvsCF9nPpxOwv9B8phr8q7P8d8+nJJ6u7cvkn4i9PMsEPhVVrhXf
Ci4BYEvOo6TI03mGrsqV+6pzcezL8sDqqeXuU4nUQXNXaSL1kvK4vKB1TvA1HaOE5oWg
MyS/U3Y+Kto7uohtbCCpDxFxwWnTxZsR7E1mbi1aVTmw0bU5qzcNdp6NZjdtvna+JE7P
+eC5yP7aGe5BP17pm4Nq4NkUQS4HkOB6JcoZi3/kvzyyIhraxRW1cgw94S6NjBCk6t/e
EaKg==
X-Received: by 10.140.102.226 with SMTP id w89mr29383099qge.44.1449897229678;
Fri, 11 Dec 2015 21:13:49 -0800 (PST)
Received: from hedwig-18.prd.orcali.com
(ec2-54-85-253-144.compute-1.amazonaws.com. [54.85.253.144])
by smtp.gmail.com with ESMTPSA id
g132sm9557676qhc.46.2015.12.11.21.13.48
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 11 Dec 2015 21:13:48 -0800 (PST)
Date: Fri, 11 Dec 2015 21:13:48 -0800 (PST)
X-Google-Original-Date: Sat, 12 Dec 2015 05:13:48 GMT
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/)
Message-Id: <1449897228198.c655b3ae@Nodemailer>
In-Reply-To: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
References: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
X-Orchestra-Oid: F9030F7F-8DFF-4397-9509-CB9B5351DB32
X-Orchestra-Sig: 3c9a5768451461b5f125bd2bc8428c2156ef916b
X-Orchestra-Thrid: TD56C876D-E76D-40BE-ACDA-81C322724964_1519937925061843681
X-Orchestra-Thrid-Sig: 039320e413e349a882eae29b1df68b722d8b9658
X-Orchestra-Account: e2bf1027582c408be0fcf2c03a2d2c11442d6c5e
From: digitsu@gmail.com
To: "Gavin Andresen" <gavinandresen@gmail.com>
Content-Type: multipart/alternative;
boundary="----Nodemailer-0.5.0-?=_1-1449897228528"
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 12 Dec 2015 06:02:40 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Sat, 12 Dec 2015 05:13:51 -0000
------Nodemailer-0.5.0-?=_1-1449897228528
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
If this means essentially that a soft fork deployment of SegWit will =
require SPV wallet servers to change their logic (or risk not being able to=
send payments) then it does seem to me that a hard fork to deploy this non=
controversial change is not only cleaner (on the data structure side) but =
safer in terms of the potential to affect the user experience.=C2=A0
=E2=80=94
Regards,
On Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 11:18 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> =
wrote:
>> This is basically what I meant by
>>
>> struct hashRootStruct
>> {
>> uint256 hashMerkleRoot;
>> uint256 hashWitnessesRoot;
>> uint256 hashextendedHeader;
>> }
>>
>> but my design doesn't calculate other=5Froot as it appears in your tree =
(is
>> not necessary).
>>
>> It is necessary to maintain compatibility with SPV nodes/wallets.
> Any code that just checks merkle paths up into the block header would =
have
> to change if the structure of the merkle tree changed to be three-headed =
at
> the top.
> If it remains a binary tree, then it doesn't need to change at all-- the
> code that produces the merkle paths will just send a path that is one =
step
> deeper.
> Plus, it's just weird to have a merkle tree that isn't a binary tree.....=
> --=20
> --
> Gavin Andresen
------Nodemailer-0.5.0-?=_1-1449897228528
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<div>If this means essentially that a soft fork deployment of SegWit will =
require SPV wallet servers to change their logic (or risk not being able to=
send payments) then it does seem to me that a hard fork to deploy this non=
controversial change is not only cleaner (on the data structure side) but =
safer in terms of the potential to affect the user experience.=C2=A0</div>
<div><br></div>
<div class=3D=22mailbox=5Fsignature=22>
<br>=E2=80=94
Regards, </div>
<br><br><div class=3D=22gmail=5Fquote=22><p>On Sat, Dec 12, 2015 at 1:43 AM=
, Gavin Andresen via bitcoin-dev <span dir=3D=22ltr=22><<a =
href=3D=22mailto:bitcoin-dev@lists.linuxfoundation.org=22 =
target=3D=22=5Fblank=22>bitcoin-dev@lists.linuxfoundation.=
org</a>></span> wrote:<br></p><blockquote class=3D=22gmail=5Fquote=22 =
style=3D=22margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
=22><div><div dir=3D=22ltr=22>
<div class=3D=22gmail=5Fextra=22>
<div class=3D=22gmail=5Fquote=22>On Fri, Dec 11, 2015 at 11:18 AM, Jorge =
Tim=C3=B3n <span dir=3D=22ltr=22><<a href=3D=22mailto:jtimon@jtimon.=
cc=22>jtimon@jtimon.cc</a>></span> wrote:<br><blockquote =
class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex=22>
<p dir=3D=22ltr=22>This is basically what I meant by</p>
<span class=3D=22=22>
<p dir=3D=22ltr=22>struct hashRootStruct<br>
{<br>
uint256 hashMerkleRoot;<br>
uint256 hashWitnessesRoot;<br>
uint256 hashextendedHeader;<br>
}</p>
</span><p dir=3D=22ltr=22>but my design doesn't calculate other=5Froot as =
it appears in your tree (is not necessary).</p>
<p dir=3D=22ltr=22></p>
</blockquote>
</div>It is necessary to maintain compatibility with SPV nodes/wallets.=
</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>Any code that just checks merkle paths up =
into the block header would have to change if the structure of the merkle =
tree changed to be three-headed at the top.</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>If it remains a binary tree, then it =
doesn't need to change at all-- the code that produces the merkle paths =
will just send a path that is one step deeper.</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>Plus, it's just weird to have a merkle =
tree that isn't a binary tree.....</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>-- <br><div class=3D=22gmail=5Fsignature=
=22>--<br>Gavin Andresen<br></div>
</div>
</div></div></blockquote></div><br>
------Nodemailer-0.5.0-?=_1-1449897228528--
|
