public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

           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$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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