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
|
Return-Path: <patrick.strateman@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 75B3BAAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 21:39:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com
[209.85.192.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA93B141
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 21:39:12 +0000 (UTC)
Received: by pdbki1 with SMTP id ki1so146718452pdb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 14:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:disposition-notification-to:date:from:user-agent
:mime-version:to:subject:references:in-reply-to:content-type;
bh=uJPLqf2O8NVA1691sYKY1MS2svDpFAn9aOveV5epwzc=;
b=U5MyHTZNXLVG9Vb3P5DkIkPMwa049rMLxRYvSuNgv9CsjkHO3NHIuoTacAQOr3XErS
kxP/IwxMGBFSkTbWlOoZk9g/jK7ezzXbre+oxZD1oYhnmSgSqP2IbOBxFIFR3tp5NmWE
2Bs/fY0A7GAjFZOVLQRBvRtQ2sYL110ML5fMyUqhKX9RBNB/gzgCPorb3ioRy381UWDR
4KIrnJbDBGp3Qa2VVGukfQZ65R8Xse9D95vIj97dNGquH46p2q2p04wSKWycLtWeTEIL
BPdGiSIpJQnyn7VxgDgXRD77TVe3ZYsyuOkDnVdlaA35jL06zQWsTQYCtpQUPQm+ntd+
Dndw==
X-Received: by 10.70.32.66 with SMTP id g2mr43887241pdi.82.1435009152570;
Mon, 22 Jun 2015 14:39:12 -0700 (PDT)
Received: from [10.45.134.9] (c-24-5-81-164.hsd1.ca.comcast.net. [24.5.81.164])
by mx.google.com with ESMTPSA id f1sm20897965pdp.24.2015.06.22.14.39.11
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 22 Jun 2015 14:39:11 -0700 (PDT)
Message-ID: <5588807B.7030400@gmail.com>
Date: Mon, 22 Jun 2015 14:39:07 -0700
From: Patrick Strateman <patrick.strateman@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com> <20150622205420.GA8892@savin.petertodd.org>
<CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com>
In-Reply-To: <CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------020804050407050102040706"
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] 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 21:39:13 -0000
This is a multi-part message in MIME format.
--------------020804050407050102040706
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.
On 06/22/2015 02:21 PM, Gavin Andresen wrote:
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
> > Since it's possible that block timestamps aren't chronological
> in order, what would happen if a block following a size increase
> trigger is back in the past before the size increase? Would that
> block have a lower size restriction again? Would using block
> height not be a more stable number to work with?
>
> In the nVersion bits proposal that I co-authored we solved that
> issue by
> comparing the timestamp against the median time, which is
> guaranteed by
> the protocol rules to monotonically advance.
>
>
> That complicates the implementation quite a bit.
>
> I mostly implemented a variant that replaced the MAX_BLOCK_SIZE
> constant with a function that took both a timestamp and a block
> height, and there are several places in the current reference
> implementation where digging out the block height (or, worse,
> calculating the median timestamp for the block) would involve changing
> quite a few functions in the call-chain or acquiring the cs_main lock
> to consult the current best chain.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------020804050407050102040706
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.<br>
<br>
<div class="moz-cite-prefix">On 06/22/2015 02:21 PM, Gavin Andresen
wrote:<br>
</div>
<blockquote
cite="mid:CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Jun 22, 2015 at 4:54 PM,
Peter Todd <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">> Since it's possible that block
timestamps aren't chronological in order, what would
happen if a block following a size increase trigger is
back in the past before the size increase? Would that
block have a lower size restriction again? Would using
block height not be a more stable number to work with?<br>
<br>
</div>
</div>
In the nVersion bits proposal that I co-authored we solved
that issue by<br>
comparing the timestamp against the median time, which is
guaranteed by<br>
the protocol rules to monotonically advance.<br>
</blockquote>
<div><br>
</div>
<div>That complicates the implementation quite a bit.</div>
<div><br>
</div>
<div>I mostly implemented a variant that replaced the
MAX_BLOCK_SIZE constant with a function that took both a
timestamp and a block height, and there are several places
in the current reference implementation where digging out
the block height (or, worse, calculating the median
timestamp for the block) would involve changing quite a
few functions in the call-chain or acquiring the cs_main
lock to consult the current best chain.</div>
</div>
<div><br>
</div>
-- <br>
<div class="gmail_signature">--<br>
Gavin Andresen<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------020804050407050102040706--
|
