public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Cc: 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: Fri, 15 Nov 2013 05:52:40 -0500	[thread overview]
Message-ID: <20131115105240.GD17034@savin> (raw)
In-Reply-To: <527C0D12.8030905@ceptacle.com>

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

On Thu, Nov 07, 2013 at 10:58:42PM +0100, Michael Gronager wrote:
> > Q=0    -> f = 0.0033 BTC/kB Q=0.1  -> f = 0.0027 BTC/kB Q=0.25 -> f
> > = 0.0018 BTC/kB Q=0.40 -> f = 0.0012 BTC/kB
> 
> You second list of numbers is an unlikely extreme:
> 
> > k = 1mS/kB
> 
> The propagation latency in the network is more due to the block
> verification than due to its network (fiber) propagation time,
> bringing down the number of hops helps tremendously, so I agree that
> we can probably bring down k by a factor of ~10 (k=8-12) if we
> consider only pools directly connected. This should bring us close to
> break even with the current fee size, but we should really get some
> empirical data for interconnected large pools.

Well if large pools wanted it would be trivial for all of them to just
connect to each other... but my 25kB/s average data rate sure indicates
that they either aren't bothering, or aren't bothering to do that
correctly.

> However - important
> note - if you are a 1% miner - don't include transactions!

Which is an awful solution, although probably a correct one.... After
all, if you don't include transactions, you can start mining blocks
earlier too based on just the header.

> > Q=0    -> f = 0.000042 BTC/kB Q=0.1  -> f = 0.000034 BTC/kB Q=0.25
> > -> f = 0.000023 BTC/kB Q=0.40 -> f = 0.000015 BTC/kB
> > 
> 
> > 
> > This problem is inherent to the fundemental design of Bitcoin: 
> > regardless of what the blocksize is, or how fast the network is,
> > the current Bitcoin consensus protocol rewards larger mining pools
> > with lower costs per KB to include transactions.
> 
> I don't see a problem of rewarding economy of scale, as long as the
> effect is not too grave (raising the min fee would actually make it
> more profitable for smaller miners).

That's a fundemental misunderstanding; there's no such thing as a min
fee.

As for economies of scale, the "product" we're paying miners for is
decentralization and resistance to 51% attack. If instead only get 51%
attack resistance, we're getting a bum deal. If that's all we're
getting, we don't actually have 51% resistance...

-- 
'peter'[:-1]@petertodd.org
00000000000000075ed91531e07d2045b5823da050fe373bde7bb363965e44ae

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

      reply	other threads:[~2013-11-15 10: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
2013-11-07 20:31 ` Peter Todd
2013-11-07 21:58   ` Michael Gronager
2013-11-15 10:52     ` Peter Todd [this message]

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=20131115105240.GD17034@savin \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gronager@ceptacle.com \
    /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