summaryrefslogtreecommitdiff
path: root/b5/9e344c3e929a9bd1d86163fefe6d4738b8d91d
blob: dde097ceeff9e1fe85a91a004659da8c4f548afb (plain)
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
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C8242305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 20:46:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com
	[209.85.215.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9EDF144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 20:46:53 +0000 (UTC)
Received: by lagi2 with SMTP id i2so27925983lag.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 13:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=w7HrZVMnB/Gh6CxXWXk75waoiK7GSFqAwbqzVEHo8v0=;
	b=YAAM+PcJOxL0ga7Nxqhi7Gh0yJqTjCp+Hkr5qFVvQjD5LTZoQrHzdYMabR6hDdLqJ/
	FGfOzd2EgL9VWT1hiNGzXHFrJ2PFEDv0C9/FwsnLS9OCZcOayGq/eq41AX2J1YDBM0nh
	EDDe18gAYcd+kWSHDH4/fbgXwz3ksdMg1WOx+BdhvxcYgAUjDLe5RXFK955iShK1iZFk
	rYKG2G/sJ3HrXz5eeM+xDHnfwqunBVqpAcwmNiOlDAaWHKba97b7Y0BtKhMdM9ot6PZN
	ocYApDtoEhQqCpXNdCRmMDDLsPi5f+0PvVmvac0YW4jh+79BLXRQzrZR0RcZ3VE5UM06
	0Fgg==
MIME-Version: 1.0
X-Received: by 10.152.115.199 with SMTP id jq7mr3950933lab.113.1435006011832; 
	Mon, 22 Jun 2015 13:46:51 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 13:46:51 -0700 (PDT)
In-Reply-To: <CAPswA9wVEs6oH8CxafLvLy78bpC937HZccjXHwyq8JVMV7qiQA@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<CAPswA9wVEs6oH8CxafLvLy78bpC937HZccjXHwyq8JVMV7qiQA@mail.gmail.com>
Date: Mon, 22 Jun 2015 16:46:51 -0400
Message-ID: <CABsx9T1KsOHF2u+Sk0c1d1U11ff-FJH9EjC4XNZP4-puWKE_Lg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: multipart/alternative; boundary=001a11c2588e95ff050519215fb2
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
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: Mon, 22 Jun 2015 20:46:54 -0000

--001a11c2588e95ff050519215fb2
Content-Type: text/plain; charset=UTF-8

On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:

> * In the specification, you refer to "t_start". I guess you mean
> "time_start"?
>

Thanks, I'll fix.


> * Miners can, especially when close to a block doubling or shortly
> after activation, to some extent manipulate max block size by
> manipulating the time stamp in the block header within valid limits.
> According to the pseudo code in the specification, the first and a
> handful of subsequent blocks after activation could actually have
> negative max block sizes due to this (depending on how you define the
> % operator of the pseudo code). I haven't checked the reference
> implementation, but I do think that the specification section should
> explicitly handle this.
>

Excellent point. That could only happen if activation happened on 11 Jan
2016; instead of complicating the code and spec with another condition, I
think it would be better to specify that the activation date is the later
of the miner supermajority and 11 Jan, with the first big block two weeks
later.


-- 
--
Gavin Andresen

--001a11c2588e95ff050519215fb2
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 M=
on, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">* In the specification, yo=
u refer to &quot;t_start&quot;. I guess you mean &quot;time_start&quot;?<br=
></blockquote><div><br></div><div>Thanks, I&#39;ll fix.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
* Miners can, especially when close to a block doubling or shortly<br>
after activation, to some extent manipulate max block size by<br>
manipulating the time stamp in the block header within valid limits.<br>
According to the pseudo code in the specification, the first and a<br>
handful of subsequent blocks after activation could actually have<br>
negative max block sizes due to this (depending on how you define the<br>
% operator of the pseudo code). I haven&#39;t checked the reference<br>
implementation, but I do think that the specification section should<br>
explicitly handle this.<br></blockquote><div><br></div><div>Excellent point=
. That could only happen if activation happened on 11 Jan 2016; instead of =
complicating the code and spec with another condition, I think it would be =
better to specify that the activation date is the later of the miner superm=
ajority and 11 Jan, with the first big block two weeks later.</div><div>=C2=
=A0</div></div><div><br></div>-- <br><div class=3D"gmail_signature">--<br>G=
avin Andresen<br></div>
</div></div>

--001a11c2588e95ff050519215fb2--