From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z1l3a-0003fw-9h for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 00:36:50 +0000 X-ACL-Warn: Received: from mail-qc0-f176.google.com ([209.85.216.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z1l3X-0005kU-G4 for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 00:36:50 +0000 Received: by qcnj1 with SMTP id j1so19334391qcn.0 for ; Sun, 07 Jun 2015 17:36:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=15g/sy/yyHgDfbUdvwmz8f6EEZxAcSX9Uds5g2RPuHQ=; b=aI0k3jzwT1Rg77px8utIfwqrhqaDkCU2mZqTOR4YdItpjFV7fkAbb/YA4vzDp5Gz2y CHLT7dXQDaxkHmk7ynQzRerPVWOxWfTmYsfWUXuF9t1/W6EXzoYYcLdTvY87I8jZ7f0x O3bRkuB+Ba+I3CenPqNlv1RAObakFnBOmtYwUpfMUi2ihEjbQp0rofJhmU9sHTOdMGOq 0ATmLIjMMn/PBmYdSH5EkuuKNnPRaCp0YSAKQ1KHPnDZOKLpmuhvZQ5dBRTWW+lhpaHp tTVg5Jsjd7M01RfnNcc5kPdJ6mJUfR+M0v7CY7aP57VMnTOVlN/B05wgd65/11sBJPAY O6NA== X-Gm-Message-State: ALoCoQkvNHYeoprFfUvwq/VyBObhJNBmrQoFBam29+Tsr0ydGXu7IPeVqGSzEOsYiawihmRuT6kd X-Received: by 10.140.202.130 with SMTP id x124mr17577545qha.9.1433723802007; Sun, 07 Jun 2015 17:36:42 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by mx.google.com with ESMTPSA id b85sm523449qkb.8.2015.06.07.17.36.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 17:36:41 -0700 (PDT) Message-ID: <5574E39C.3090904@thinlink.com> Date: Sun, 07 Jun 2015 17:36:44 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bitcoin Dev Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Z1l3X-0005kU-G4 Subject: [Bitcoin-development] Block Size Experiment Underway X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 00:36:50 -0000 In September, 2014, a collective experiment began in the bitcoin ecosystem. Available block space (1MB) began to sometimes fall short of the space required to mine all of the transactions that would otherwise have been included. This chart, posted earlier, shows the onset of the some-blocks-at-maximum era. http://i.imgur.com/5Gfh9CW.png Although the average block is only about 400K, real blocks are bigger or smaller due to the random length of time between blocks (and other factors). I look at how often this is predicted to happen. Recently, transactions have been confirmed at a rate of about 100000/day*. The average transaction size for the past 6000 blocks has been 545 bytes. Using these values, txesPerMinute =3D 100000 / 24 / 60 =3D 69.4 txesInMaxBlock =3D 999977 / 545 =3D 1834 minutesToFillBlock =3D txesInMaxBlock/txesPerMinute =3D 26.4 Using the theoretical formula for the time before an inter-block interval of at least a given length ** blockChickenMinutes[x] :=3D 10 (exp(x/10) - x/10 - 1) we obtain minutesBetweenFullBlocks =3D blockChickenMinutes[minutesToFillBlock] =3D = 104 We currently expect a maximum-size block every 1 hour + 44 minutes, on average. If the transaction rate doubles, we should expect a maximum-size block every 14 minutes, on average. The non-linearity makes sense, because doubling the average without raising the maximum requires disproportionately more maximum-size blocks. This estimate is understated because transaction size and submission rate have their own distributions. Using the averages of 545 bytes and 100000/day ignores the fact that for some blocks, there are unusually big and/or numerous transactions, which increases the block size variance and causes blocks over the threshold to be encountered more frequently. These calculations are confirmed by empirical observation of the most recent 6000 blocks: http://i.imgur.com/0pQUsdl.png In many cases, the miner chose to create a 750KB block, which is unusually likely to be followed by another 750KB or 1MB block, because the next interval starts off with a 250KB backlog. Some backlog transactions may experience more than 1 block delay in these cases. * https://www.quandl.com/data/BCHAIN/NTRAN-Bitcoin-Number-of-Transactions= ** This is a chicken-crossing-the-road problem. Wait time =3D (exp(=CE=BB= x) =E2=88=92 =CE=BBx - 1) / =CE=BB Some discussion at https://github.com/nanotube/supybot-bitcoin-marketmonitor/pull/68.