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 1VeRPb-0006Ef-69 for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 15:22:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VeRPa-00010e-5d for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 15:22:23 +0000 Received: by mail-oa0-f53.google.com with SMTP id j17so1147738oag.12 for ; Thu, 07 Nov 2013 07:22:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.62.242 with SMTP id b18mr256216oes.85.1383837736753; Thu, 07 Nov 2013 07:22:16 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Thu, 7 Nov 2013 07:22:16 -0800 (PST) In-Reply-To: References: <527B9F9B.4060808@ceptacle.com> Date: Thu, 7 Nov 2013 16:22:16 +0100 X-Google-Sender-Auth: gIpMTBQCV-60p95bJhAbuF44_Lg Message-ID: From: Mike Hearn To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11c24b0ab9e3d104ea97d419 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VeRPa-00010e-5d Cc: Bitcoin Dev , Michael Gronager Subject: Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) 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: Thu, 07 Nov 2013 15:22:23 -0000 --001a11c24b0ab9e3d104ea97d419 Content-Type: text/plain; charset=UTF-8 I think trying to help miners figure out the propagation/fees tradeoff at the moment is a non-starter until we understand it better ourselves. A server that tracks and records block propagation times, how many fees per passed up per block, orphan stats per size bucket etc would be tremendously helpful. On Thu, Nov 7, 2013 at 4:19 PM, Pieter Wuille wrote: > Correcting myself: > > On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille > wrote: > > I believe that C. Decker's paper used measurements for propagation > > delays for blocks 180000-190000, which happened between may and juli > > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3. > > They did use data from blocks 20000-210000, september-november 2012. > That was still before the 0.8 release, however. > > -- > Pieter > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c24b0ab9e3d104ea97d419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think trying to help miners figure out the propagation/f= ees tradeoff at the moment is a non-starter until we understand it better o= urselves. A server that tracks and records block propagation times, how man= y fees per passed up per block, orphan stats per size bucket etc would be t= remendously helpful.


On Thu, Nov 7= , 2013 at 4:19 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
Correcting myself:

On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> I believe that C. Decker's paper used measurements for propagation=
> delays for blocks 180000-190000, which happened between may and juli > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
They did use data from blocks 20000-210000, september-november 2012.<= br> That was still before the 0.8 release, however.

--
Pieter

---------------------------------------------------------------------------= ---
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explor= e
techniques for threading, error checking, porting, and tuning. Get the most=
from the latest Intel processors and coprocessors. See abstracts and regist= er
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c24b0ab9e3d104ea97d419--