From: Daniele Pinna <daniele.pinna@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max C
Date: Fri, 21 Aug 2015 23:35:18 +0200 [thread overview]
Message-ID: <CAEgR2PEwhrAtsxBkVEeHn_jqK4+TgNkUY36qT1wktEwp2jmS_g@mail.gmail.com> (raw)
In-Reply-To: <CAEgR2PFhubcZmiCnZOAYfNOeXwhsu6m1Xd9=KMmP7wueFQaK9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."
Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect of
coinbase subsidization. As the block rewards get smaller, so will large
miner advantages. An easy way to think about this is as follows:
Currently, the main critique of larger blocksizes is that we'll connected
miners can cut out smaller miners by gratuitously filling up blocks with
self-paying transactions. This only works because block subsidies exist.
The moment block rewards become comparable to block TX fees, this exploit
ceases to be functional.
Basically, large miners will still be forced to move full blocks, but it
will go against their interest to fill them with spam since their main
source of income is the fees themselves. As a result, large miners (unlike
smaller ones) will lose the incentive to mine an un full block this evening
the playing field.
In this context, large blocksizes as proposed by BIP100-101 hope to
stimulate the increase of TX fees by augmenting the network's capacity. The
sooner block rewards become comparable to block fees, the sooner we will
get rid of mine centralization.
Dpinna
[1]
http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
[-- Attachment #2: Type: text/html, Size: 1705 bytes --]
parent reply other threads:[~2015-08-21 21:35 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAEgR2PFhubcZmiCnZOAYfNOeXwhsu6m1Xd9=KMmP7wueFQaK9A@mail.gmail.com>]
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=CAEgR2PEwhrAtsxBkVEeHn_jqK4+TgNkUY36qT1wktEwp2jmS_g@mail.gmail.com \
--to=daniele.pinna@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/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