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
|
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 290CF3C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 22:05:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id F1BF4112
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2015 22:05:15 +0000 (UTC)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 48B4F3BC078;
Tue, 21 Jul 2015 15:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
:references:cc:from:message-id:date:mime-version:in-reply-to
:content-type:content-transfer-encoding; s=jrn.me.uk; bh=Vj+bjNa
9wVW+MP0VgMS2umS8Ers=; b=1ehMldXj71+aT1K1AqHxtuNSy9guFjZkQwHHOns
qJOWmyhmQ5VziHWtT6iZwymeNt084TPPe91Li9Skz046QRJvlg95F6V5Mlns1Bz/
ab4XKmm548hmAD6BVtitvpOq/AyAO3kVCpF1EcMYyOJE4RMN4IgMaIC/bQ08jOe2
I0jk=
Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net
[86.30.131.63])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id A9DC53BC073;
Tue, 21 Jul 2015 15:05:14 -0700 (PDT)
To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= <jtimon@jtimon.cc>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
<CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55AEC21A.3090302@jrn.me.uk>
Date: Tue, 21 Jul 2015 23:05:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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: Tue, 21 Jul 2015 22:05:17 -0000
Not so much that the implementation is difficult, as it requires context=20
to validate a block size, rather than being able to validate it without=20
requiring the preceeding blocks. Yes, time on different machines may=20
vary, but block time is safe to use for this, because it's a=20
straight-forward test of "if block time is acceptable and block time is=20
after <date> then maximum block size allowed is n MB otherwise m MB".
Ross
On 21/07/2015 10:26, Jorge Tim=C3=B3n wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will differ in different computers and places when we have a
> universal tick with every block?
>
> Btw, BIP16 and BIP34 could be changed to height-based activation
> already. BIP16 simply should have used height instead of time from the
> beginning.
>
> On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Further to that - please disregard what I said about using block heigh=
t. Had
>> failed to realise that in using contextual information (block height) =
it
>> complicates block validation (i.e. it would be impossible to tell if a=
block
>> is too big, without having all previous blocks first). Block time is i=
n fact
>> the better option.
>>
>> Ross
>>
>>
>> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
>>
>> I'd back this if we can't find a permanent solution - 2MB gives us a l=
ot
>> more wiggle room in the interim at least; one of my concerns with bloc=
k size
>> is 3 transactions per second is absolutely tiny, and we need space for=
the
>> network to search for an equilibrium between volume and pricing withou=
t risk
>> of an adoption spike rendering it essentially unusable.
>>
>> I'd favour switching over by block height rather than time, and I'd su=
ggest
>> that given virtually every wallet/node out there will require testing =
(even
>> if many do not currently enforce a limit and therefore do not need
>> changing), 6 months should be considered a minimum target. I'd open wi=
th a
>> suggestion of block 390k as a target.
>>
>> Ross
>>
>> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>>
>> Opening a mailing list thread on this BIP:
>>
>> BIP PR: https://github.com/bitcoin/bips/pull/173
>> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>>
>> The general intent of this BIP is as a minimum viable alternative plan=
to my
>> preferred proposal (BIP 100).
>>
>> If agreement is not reached on a more comprehensive solution, then thi=
s
>> solution is at least available and a known quantity. A good backup pl=
an.
>>
>> Benefits: conservative increase. proves network can upgrade. permit=
s some
>> added growth, while the community & market gathers data on how an incr=
eased
>> block size impacts privacy, security, centralization, transaction thro=
ughput
>> and other metrics. 2MB seems to be a Least Common Denominator on an
>> increase.
>>
>> Costs: requires a hard fork. requires another hard fork down the roa=
d.
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> 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
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
|
