From: Daniele Pinna <daniele.pinna@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Unlimited Max Blocksize (reprise)
Date: Thu, 27 Aug 2015 00:22:42 +0200 [thread overview]
Message-ID: <CAEgR2PHdRGe2Sj+yO_Ng0cCr_89qi_KXaqMKTY6J2Ksz-PWwzA@mail.gmail.com> (raw)
In-Reply-To: <CAEgR2PHnJfCwMzFCrJr_TnFzRjJ7GVE-4=omva92nO6g9z2LSQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
I don't get how it's very risky to have the Mike and Gavin redirect the
course of the bitcoin protocol but it's totally fine to consider complex
miner voting protocols as a hard fork option.
I believe that this community has not given due weight to the analysis
proposed by Peter__R on the existence of fee markets with uncapped max
blocksizes. The critiques made toward his work were in no way definitive
and discussion just stopped. Is it the math that bothers people?
If his work stands the test of scrutiny, then a controlled raising of the
max blocksize in the interim to ease into the fee market dynamic described
is the best option. Possibly a stepwise BIP101 where the community
hardforks every two years until we all trust the fee market dynamics.
The main critique to uncapped max blocksizes which I've heard stems from
our incapacity to quantify the advantages that large miners have over
smaller ones. As I will show in an upcoming paper, these advantages do not
stem from the act of propagating large blocks but rather from the block
subsidies which allow miners to mine unnecessary large blocks irregardless
of the fees contained therein. One typical example is Peter Todd's
suggested attack whereby a miner creates a massive block filled with spam
transactions that pay himself solely to slow down the rest of the network
and gain an advantage. Putting aside the increased orphan risk arising from
the propagation of such a large block, this attack would never be viable if
it weren't for the existence of current block subsidies.
As such, exponential increases to the max blocksize make perfect sense
since the block reward decreases exponentially also. All arguments invoking
rates of technological advances (see Gavin's original posts) don't mean
anything. Rational miners will NOT be incentivized to mine gargantuan spam
filled blocks in the presence of a vanishing block reward.
I truly hope this matter gets the consideration it deserves. Particularly
with the upcoming scaling workshops.
Dpinna
On Aug 21, 2015 11:35 PM, "Daniele Pinna" <daniele.pinna@gmail•com> wrote:
"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: 4204 bytes --]
next parent reply other threads:[~2015-08-26 22:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAEgR2PEMueQc7GgYWYMOZgtKHvxHgoe1rT1F+YpG2x0h74+_Gw@mail.gmail.com>
[not found] ` <CAEgR2PHnJfCwMzFCrJr_TnFzRjJ7GVE-4=omva92nO6g9z2LSQ@mail.gmail.com>
2015-08-26 22:22 ` Daniele Pinna [this message]
2015-08-27 0:48 ` Jorge Timón
2015-08-30 11:49 Daniele Pinna
[not found] ` <B52558A9-8897-450B-B386-503773EE0867@gmx.com>
2015-08-30 21:10 ` Tom Harding
2015-08-30 17:00 Peter R
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=CAEgR2PHdRGe2Sj+yO_Ng0cCr_89qi_KXaqMKTY6J2Ksz-PWwzA@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