From: Michael Gronager <gronager@ceptacle.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)
Date: Thu, 07 Nov 2013 16:53:12 +0100 [thread overview]
Message-ID: <527BB768.8010202@ceptacle.com> (raw)
In-Reply-To: <CANEZrP0wUkjHP8LyUnNDSkYRy-tbSo8A7NmdL4nPFwMZ6oHV-Q@mail.gmail.com>
Mike, Pieter,
My writeup outlines a framework for good approximation to a minimal fee
as well as the optimal block size. The model has basically just one
parameter, the propagation time - if that goes down, so can the fee.
(Well there is another parameter too, the time btw blocks, which
currently with the current hash acceleration is more like 400 than 600).
Also seconding Mike, that, yes, it would be tremendously useful to track
propagation times and other things on the network to help us all decide
the proper settings.
Finally, it would be great if someone from academia would grab the ball
and do the full probabilistic analysis based on my outline.
Michael
On 7/11/13, 16:22 , Mike Hearn wrote:
> 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 <pieter.wuille@gmail.com
> <mailto:pieter.wuille@gmail.com>> wrote:
>
> Correcting myself:
>
> On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille
> <pieter.wuille@gmail.com <mailto: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.
> 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
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
next prev parent reply other threads:[~2013-11-07 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 14:11 [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) Michael Gronager
2013-11-07 15:00 ` Pieter Wuille
2013-11-07 15:19 ` Pieter Wuille
2013-11-07 15:22 ` Mike Hearn
2013-11-07 15:53 ` Michael Gronager [this message]
2013-11-07 20:31 ` Peter Todd
2013-11-07 21:58 ` Michael Gronager
2013-11-15 10:52 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527BB768.8010202@ceptacle.com \
--to=gronager@ceptacle.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox