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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YyP1B-0001cp-3X
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 18:28:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.177 as permitted sender)
client-ip=209.85.220.177; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f177.google.com;
Received: from mail-qk0-f177.google.com ([209.85.220.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyP1A-0001Pv-9S
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 18:28:29 +0000
Received: by qkhg32 with SMTP id g32so49757119qkh.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 29 May 2015 11:28:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.19.82 with SMTP id d79mr18569277qkh.21.1432924102810;
Fri, 29 May 2015 11:28:22 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 29 May 2015 11:28:22 -0700 (PDT)
In-Reply-To: <COL131-DS8AE5724250D730A8B03C5CDC90@phx.gbl>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
<CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
<CAE-z3OXEGcUYYAsqqrVMQw=XA=5dt9u7XHDmuzhMJ8OkZ+k3yg@mail.gmail.com>
<CAE-z3OU8Vtmi_UK=nF1UNLsXCwd17mKDMS1qKudYB_kwDbOguA@mail.gmail.com>
<COL131-DS8AE5724250D730A8B03C5CDC90@phx.gbl>
Date: Fri, 29 May 2015 19:28:22 +0100
Message-ID: <CAE-z3OXxNhhVND5O3Sz3nkJehHj_xLsk6nbmy7n-F+H_VMbWtw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a114008ca23620605173ca448
X-Spam-Score: 3.3 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YyP1A-0001Pv-9S
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
stepfunction
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 18:28:29 -0000
--001a114008ca23620605173ca448
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, May 29, 2015 at 5:39 PM, Raystonn . <raystonn@hotmail.com> wrote:
> Regarding Tier=E2=80=99s proposal: The lower security you mention for e=
xtended
> blocks would delay, possibly forever, the larger blocks maximum block siz=
e
> that we want for the entire network. That doesn=E2=80=99t sound like an =
optimal
> solution.
>
I don't think so. The lower security is the potential centralisation
risk. If you have your money in the "root" chain, then you can watch it.
You can probably also watch it in a 20MB chain.
Full nodes would still verify the entire block (root + extended). It is a
"nuclear option", since you can make any changes you want to the rules for
the extended chain. The only safe guard is that people have to voluntarly
transfer coins to the extended block.
The extended block might have 10-15% of the total bitcoins, but still be
useful, since they would be the ones that move the most. If you want to
store your coins long term, you move them back to the root block where you
can watch them more closely.
It does make things more complex though. Wallets would have to list 2
balances.
--001a114008ca23620605173ca448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 29, 2015 at 5:39 PM, Raystonn . <span dir=3D"ltr"><<a href=3D"ma=
ilto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div style=3D"FONT-SIZE:10pt;FONT-FAMILY:'Arial';COLOR:#000000">
<div>Regarding Tier=E2=80=99s proposal: The lower security you mention for =
extended=20
blocks would delay, possibly forever, the larger blocks maximum block size =
that=20
we want for the entire network.=C2=A0 That doesn=E2=80=99t sound like an op=
timal=20
solution.</div></div></div></div></blockquote><div><br></div><div>I don'=
;t think so.=C2=A0 The lower security is the potential centralisation risk.=
=C2=A0 If you have your money in the "root" chain, then you can w=
atch it.=C2=A0 You can probably also watch it in a 20MB chain.<br><br></div=
><div>Full nodes would still verify the entire block (root + extended).=C2=
=A0 It is a "nuclear option", since you can make any changes you =
want to the rules for the extended chain.=C2=A0 The only safe guard is that=
people have to voluntarly transfer coins to the extended block.<br><br></d=
iv><div>The extended block might have 10-15% of the total bitcoins, but sti=
ll be useful, since they would be the ones that move the most.=C2=A0 If you=
want to store your coins long term, you move them back to the root block w=
here you can watch them more closely.<br><br></div><div>It does make things=
more complex though.=C2=A0 Wallets would have to list 2 balances.<br></div=
></div></div></div>
--001a114008ca23620605173ca448--
|
