From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 31F82273 for ; Mon, 22 Jun 2015 20:32:27 +0000 (UTC) X-Greylist: delayed 01:00:01 by SQLgrey-1.7.6 Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10916A8 for ; Mon, 22 Jun 2015 20:32:26 +0000 (UTC) Received: from st11p02im-spool001.me.com ([17.172.220.115]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTP id <0NQD00PJ929YCN70@st11p02im-asmtp001.me.com> for bitcoin-dev@lists.linuxfoundation.org; Mon, 22 Jun 2015 19:32:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-22_04:2015-06-22, 2015-06-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506220328 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)" Received: from localhost ([17.172.220.223]) by st11p02im-spool001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTP id <0NQD00WZU29YD070@st11p02im-spool001.mac.com>; Mon, 22 Jun 2015 19:32:22 +0000 (GMT) To: Gavin Andresen From: Jean-Paul Kogelman Date: Mon, 22 Jun 2015 19:32:22 +0000 (GMT) X-Mailer: iCloud MailClient15CPlus63 MailServer15C.19370 X-Originating-IP: [159.153.138.99] Message-id: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD 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] =?utf-8?q?Draft_BIP_=3A_fixed-schedule_block_size_i?= =?utf-8?q?ncrease?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:32:27 -0000 --Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable =0A=0AOn Jun 22, 2015, at 11:18 AM, Gavin Andresen wrote:=0A=0AThe maximum size shall be 8,000,000 bytes at a timestamp of= 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63= ,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:= 00 UTC (timestamp 2083190400). The maximum size of blocks in between doubl= ings will increase linearly based on the block's timestamp. The maximum si= ze of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.=0A= =C2=A0=0ASince 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 s= ize restriction again? Would using block height not be a more stable numbe= r to work with?=0A=0Ajp= --Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw) Content-type: multipart/related; boundary="Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA)"; type="text/html" --Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable


On Jun 22, 2015, at 11:18 AM, Gavin Andresen <g= avinandresen@gmail.com> wrote:
=
=

The maximu= m size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC = (timestamp 1452470400), and shall double every 63,072,000 seconds (two yea= rs, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190= 400). The maximum size of blocks in between doublings will increase linear= ly based on the block's timestamp. The maximum size of blocks after 2036-0= 1-06 00:00:00 UTC shall be 8,192,000,000 bytes.
 
=
Since it's possible that block timestamps aren't chronological = in order, what would happen if a block following a size increase trigger i= s 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 num= ber to work with?

jp
= --Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA)-- --Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)--