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 --]
prev parent 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 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$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@ceptacle$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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