Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfahA-0007rT-EU for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 17:52:28 +0000 X-ACL-Warn: Received: from sulfur.webpack.hosteurope.de ([217.115.142.104]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Sfah9-0000s1-2C for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 17:52:28 +0000 Received: from 84-72-69-53.dclient.hispeed.ch ([84.72.69.53] helo=[192.168.0.21]); authenticated by sulfur.webpack.hosteurope.de running ExIM with esmtpsa (TLSv1:AES256-SHA:256) id 1Sfah3-0000ZI-9R; Fri, 15 Jun 2012 19:52:21 +0200 Message-ID: <4FDB764A.90909@justmoon.de> Date: Fri, 15 Jun 2012 19:52:10 +0200 From: Stefan Thomas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1339782747;0f4996dd; 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: 1Sfah9-0000s1-2C Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability 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: Fri, 15 Jun 2012 17:52:28 -0000 I do agree that changing/lifting the block size limit is a hard fork measure, but Mike raised the point and I do believe that whatever we decide to do now will be informed by our long term plan as well. So I think it is relevant to the discussion. > Can someone please help quantify the situation? kthanks :) According to BlockChain.info we seem to have lots of small blocks of 0-50KB and some larger 200-300 KB blocks. So in terms of near term measure one thing I would like to know is why miners (i.e. no miners at all) are fully exhausting the available block size despite thousands of transactions in the memory pool. I'm not too familiar with the default inclusion rules, so that would certainly be interesting to understand. There are probably some low hanging fruit here. The fact that SatoshiDice is able to afford to pay 0.0005 BTC fees and fill up the memory pool means that either users who care about speedy confirmation have to pay higher fees, the average actual block size has to go up or prioritization has to get smarter. If load increases more then we need more of any of these three tendencies as well. (Note that the last one is only a very limited fix, because as the high priority transactions get confirmed faster, the low priority ones take even longer.) On 6/15/2012 7:17 PM, Jeff Garzik wrote: > On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas wrote: >> The artificial limits like the block size limit are essentially putting > [...] > > Changing the block size is an item for the hard-fork list. The chance > of the block size limit changing in the short term seems rather low... > it is a "nuclear option." > > Hard-fork requires a very high level of community buy-in, because it > shuts out older clients who will simply refuse to consider >1MB blocks > valid. > > Anything approaching that level of change would need some good, hard > data indicating that SatoshiDice was shutting out the majority of > other traffic. Does anyone measure mainnet "normal tx" confirmation > times on a regular basis? Any other hard data? > > Clearly SatoshiDice is a heavy user of the network, but there is a > vast difference between a good stress test and a network flood that is > shutting out non-SD users. > > Can someone please help quantify the situation? kthanks :) >