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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 43E2B40C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 21:29:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com
[209.85.216.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B4A2ED3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 21:29:10 +0000 (UTC)
Received: by mail-qt0-f180.google.com with SMTP id p16so46176304qta.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 13:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=LbZvU692mPAlUEpAa5MNdrA7Rwux5ktKjDQt+Pt74Ow=;
b=tT7VxfbHTO7bsMzC9WXrsrFTAn51iA3Nhanc5VIvX8zM9ntGwSTyO+FPBqq5CUq9Op
P2N4yvSNwxbrCpM7NWg+iP+t20GG93CboB/L7AaO9iqQMaW3P13FUi/9jvB9FR6pmZEO
oJTukvmrSrZtzESt9kwBLW+U+R061CImAIqbbF3fVXfC2AoU7xFDVT/w5eeTHJORGRyN
Xsbvve2I2hF3ax30R7NWLZ60WbfN4sjNmVBPgdDT1PzF4f8uqs3ul3Qbx+7PVYLIEBYq
B9xlUJDXvBzKCba8w0T603EmXQ/YQCumUWd7WTZ5eoXL+A0SvOa7BNyXZFkEKzr/8e+B
YdgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=LbZvU692mPAlUEpAa5MNdrA7Rwux5ktKjDQt+Pt74Ow=;
b=bE8HmmGaeetkpFSW1c9czPlAybaZC4ITDfinpx+bUJKIm3uWMZr0DpJ/N9cHLOxIVj
jssab9Odj/WQ212XWKQoKmxhaBqHTLAxusd4OydyFc3xj80e8St+D5CTGzcCsPOFZFMm
YvKvUp8uix6qjepEMg+2GwwkXUQzzPjFm3FoV9UYYMKwT2ObWNEvSsK0oryNneA8zbHY
T6PmVwAAAzhTVq6THygdpgylyfKcLTbDspRLKdsbu/RIugs5h9XCp0/6dN2m49isVv2M
2EzABAXm+h1Eg26BJbqlH1ocYLS6t2pqZhQkpnT4AKNpUzW4llgHRVeJM9PRNRuF0VNk
gAbA==
X-Gm-Message-State: AKaTC00GtYSmI03PTFbF6kMcp6zbAAEdBTF1SxlGZPC06+ITpT3NGuVXhQ8IbIbFDVMROKxkyNcKjYNSua0U0w==
X-Received: by 10.237.37.60 with SMTP id v57mr86895233qtc.135.1481405349812;
Sat, 10 Dec 2016 13:29:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.52.99 with HTTP; Sat, 10 Dec 2016 13:29:09 -0800 (PST)
In-Reply-To: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sat, 10 Dec 2016 21:29:09 +0000
Message-ID: <CAE-z3OUpbUA2yviYoZouuZ0fp1WbbVdehWwNCd3juNsN-u9csA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114125e0a4eda00543548f6e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] Forcenet: an experimental network with a new
header format
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: Sat, 10 Dec 2016 21:29:11 -0000
--001a114125e0a4eda00543548f6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Something not yet done:
> 1. The new merkle root algorithm described in the MMHF BIP
>
Any new merkle algorithm should use a sum tree for partial validation and
fraud proofs.
Is there something special about 216 bits? I guess at most 448 bits total
means only one round of SHA256. 16 bits for flags would give 216 for each
child.
Even better would be to make the protocol extendable. Allow blocks to
indicate new trees and legacy nodes would just ignore the extra ones. If
Bitcoin supported that then the segregated witness tree could have been
added as a easier soft fork.
The sum-tree could be added later as an extra tree.
> 3. Communication with legacy nodes. This version can=E2=80=99t talk to le=
gacy
> nodes through the P2P network, but theoretically they could be linked up
> with a bridge node
>
The bridge would only need to transfer the legacy blocks which are coinbase
only, so very little data.
> 5. Many other interesting hardfork ideas, and softfork ideas that works
> better with a header redesign
>
That is very true.
--001a114125e0a4eda00543548f6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-de=
v <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>><=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
Something not yet done:<br>
1. The new merkle root algorithm described in the MMHF BIP<br></blockquote>=
<div><br></div><div>Any new merkle algorithm should use a sum tree for part=
ial validation and fraud proofs.<br><br></div><div>Is there something speci=
al about 216 bits?=C2=A0 I guess at most 448 bits total means only one roun=
d of SHA256.=C2=A0 16 bits for flags would give 216 for each child.</div><b=
r><div>Even better would be to make the protocol extendable.=C2=A0 Allow bl=
ocks to indicate new trees and legacy nodes would just ignore the extra one=
s.=C2=A0 If Bitcoin supported that then the segregated witness tree could h=
ave been added as a easier soft fork.<br><br></div><div>The sum-tree could =
be added later as an extra tree.<br></div><div>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
3. Communication with legacy nodes. This version can=E2=80=99t talk to lega=
cy nodes through the P2P network, but theoretically they could be linked up=
with a bridge node<br></blockquote><div><br></div><div>The bridge would on=
ly need to transfer the legacy blocks which are coinbase only, so very litt=
le data.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
5. Many other interesting hardfork ideas, and softfork ideas that works bet=
ter with a header redesign<br></blockquote><div><br></div><div>That is very=
true.=C2=A0 <br></div></div></div></div>
--001a114125e0a4eda00543548f6e--
|
