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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9059B7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 03:45:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC976221
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 03:45:48 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.161])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 3993EC10C5;
Tue, 18 Aug 2015 20:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1439955948; bh=p6uoKAH79GC/D0rxPlCN5mMVYLukDAQxPgO7/bCbTq0=;
h=Date:From:To:CC:Subject:References:In-Reply-To:From;
b=i2d+XKgIKYNQROCIhYEidsd6GUDphblAii6leNtSiT/YV+WN6y3kqqd59vy6T1Fgx
/E1z0SnOGzMy6ZqJ5rBKVycm+uAY77PYVptgxiHciTa/XizudrPIn4SHLKXX4Ewuf9
Cmi0YsJ57I453vMA9otIE7YDVCMVzdRax6nV3adY=
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id E0C001C023A
Message-ID: <55D3FBEB.8030804@riseup.net>
Date: Tue, 18 Aug 2015 20:45:47 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Tier Nolan <tier.nolan@gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com> <558A0B4A.7090205@riseup.net>
<558A1E8E.30306@novauri.com> <CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> <CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com> <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com> <55946E68.5070805@riseup.net>
<CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com>
In-Reply-To: <CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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, 19 Aug 2015 03:45:49 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tier ~
I don't think the XT author(s) are going to do what you are
describing. Their recent release, at
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/README.md
doesn't show any sign of moving toward a version which would be
"increasing consensus." Instead, they ignore any meaningful process
and, as I have recently indicated, have created somthing which
"sidetrack(s) real discussion necessary to resolve the issues so as to
achieve some level of consensus in block size debates."
That doesn't rule out that the BIP authors can't work together and
create something meaningful and useful, though. As I stated before,
"In my past message(s), I've suggested that Jeff's BIP 100
is a better alternative to Gavin's proposal(s), but that I didn't
think that this should be taken to mean that I am saying one thing is
"superior" to Gavin's work, rather, I emphasized that Gavin work with
Jeff and Adam."
I am also looking forward to seeing some visualizations or graphs of
the miner votes going on right now on BIP 100 and BIP 101, for example.
Regarding XT, my statement is simple:
"Do not download this loathsome XT thing. Cast it back into the fires
from whence it came."
- - Odinn
On 08/17/2015 06:15 AM, Tier Nolan via bitcoin-dev wrote:
> One of the comments made by the mining pools is that they won't run
> XT because it is "experimental".
>
> Has there been any consideration to making available a version of
> XT with only the blocksize changes?
>
> The least "experimental" version would be one that makes the
> absolute minimum changes to core.
>
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the
> longest tip changes. This saves creating a new function.
>
> Without the consensus measuring code, the patch would be even
> easier. Satoshi's proposal was just a block height comparison (a
> year in advance).
>
> The state storing code is also another complication. If the
> standard "counting" upgrade system was used, then no state would
> need to be stored in the database.
>
> On Wed, Jul 1, 2015 at 11:49 PM, odinn
> <odinn.cyberguerrilla@riseup.net
> <mailto:odinn.cyberguerrilla@riseup.net>> wrote:
>
> (My replies below)
>
> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org
>> <mailto:adam@cypherspace.org> <mailto:adam@cypherspace.org
>> <mailto:adam@cypherspace.org>>> wrote:
>
>> The hard-cap serves the purpose of a safety limit in case our
>> understanding about the economics, incentives or game-theory is
>> wrong worst case.
>
>
>> True.
>
> Yep.
>
>
>> BIP 100 and 101 could be combined. Would that increase
>> consensus?
>
> Possibly ~ In my past message(s), I've suggested that Jeff's BIP
> 100 is a better alternative to Gavin's proposal(s), but that I
> didn't think that this should be taken to mean that I am saying one
> thing is "superior" to Gavin's work, rather, I emphasized that
> Gavin work with Jeff and Adam.
>
> At least, at this stage the things are in a BIP process.
>
> If the BIP 100 and BIP 101 would be combined, what would that look
> like on paper?
>
>
>> - Miner vote threshold reached - Wait notice period or until
>> earliest start time - Block size default target set to 1 MB -
>> Soft limit set to 1MB - Hard limit set to 8MB + double every 2
>> years - Miner vote to decide soft limit (lowest size ignoring
>> bottom 20% but 1MB minimum)
>
>> Block size updates could be aligned with the difficulty setting
>> and based on the last 2016 blocks.
>
>> Miners could leave the 1MB limit in place initially. The vote
>> is to get the option to increase the block size.
>
>> Legacy clients would remain in the network until >80% of miners
>> vote to raise the limit and a miner produces a >1MB block.
>
>> If the growth rate over-estimates hardware improvements, the
>> devs could add a limit into the core client. If they give notice
>> and enough users update, then miners would have to accept it.
>
>> The block size becomes min(miner's vote, core devs). Even if 4
>> years notice is given, blocks would only be 4X optimal.
>
>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJV0/vrAAoJEGxwq/inSG8CUSQH/0rX9j1f/tSYYxUeD8ktLm6b
WkB26eNEIEwpTNGwjjYbfVou29ZGGkp58P2jv7S52RekTS3dQshjj5wgFdXE1IX4
HhgMVEnyX2Hgooeu9O32HHfjSLxgxkAozibu0NM4NnRfFQU/DTSz5+H1rABUKnl3
k2LWkhoyX517/x1GUPiGGweGpOTSwC/6BxuhCUjx1vuL9Bpp93gWRf9cRlf99Xn3
GaaXCvGFeL/VT2P9uwUWLLuOinEdvx+AGScIfdhNuN6JhN3KFY6dHXSCYTvNtNg/
XEZWNeyF3nu5lCtNQCryobDobhVdhSsv6FIWgmEdS7Ubh30jv1oWbR1wELWFEDc=
=iY5p
-----END PGP SIGNATURE-----
|
