From: jl2012@xbt•hk
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Sun, 30 Aug 2015 13:13:54 -0400 [thread overview]
Message-ID: <8faa4df0135b558e5cd064ccaec09e73@xbt.hk> (raw)
In-Reply-To: <CABm2gDo66UzhLU3Dgc6Cj=0Au4xJNv-U9GUv8JaryakQFJ=VQA@mail.gmail.com>
Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
>
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it
> safer.
>
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
>
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).
This is based on the assumption that miners would always like to use up
the last byte of the available block size. However, this is just not
true:
1. The 6 year blockchain history has shown that most miners have a soft
cap with their block size.
2. Chinese miners, controlling 60% of the network, rejected Gavin's
initial 20MB proposal and asked for 8MB:
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with
8MB as a mid-term goal:
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100
uses the 20-percentile vote as the block size, it takes only 8% more
vote to keep the size at 2MB
For many reasons miners may want to have a smaller block size, which we
don't need to list them here. Although they can limit it by a softfork
or even 51% attack, it is a very violent process. Why don't we just
allow them to vote for a lower limit?
So I think the right way is to choose a mining-centralization-safe
limit, and let it free float within a range based on miner's vote. If we
are lucky enough to have some responsible miners, they will keep it as
low as possible, until the legitimate tx volume catches up. Even in the
worst case, the block size is still mining-centralization-safe. The
upper limit may increase linearly, if not exponentially, until we find a
better long-term solution. (sort of a combination of BIP100 and 101,
with different parameters)
--------
For the matter of "urgency", I agree with you that there is no actual
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
deploy (as you suggested), we really have the urgency to make a decision
now. Actually, the main point is not urgency but uncertainty. We have
debated for 5 years. Why won't we have 5 more years of debate, plus 5
years of deployment delay? Are we sticking to 1MB for 10 years? In that
case Bitcoin Core must be abandoned by the economic majority and a
Schism fork must occur.
next prev parent reply other threads:[~2015-08-30 17:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 22:22 Btc Drak
2015-08-21 23:17 ` Paul Sztorc
2015-08-22 0:06 ` Ahmed Zsales
2015-08-28 20:28 ` Btc Drak
2015-08-28 21:15 ` Matt Whitlock
2015-08-28 22:24 ` Gavin
2015-08-28 23:35 ` Chris Pacia
2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:42 ` Matt Whitlock
2015-08-28 23:42 ` Chris Pacia
2015-08-29 0:00 ` Jorge Timón
2015-08-29 0:29 ` Mark Friedenbach
2015-08-29 10:15 ` Btc Drak
2015-08-29 17:51 ` Eric Lombrozo
2015-08-29 19:13 ` Natanael
2015-08-29 19:03 ` jl2012
2015-08-29 20:41 ` Jorge Timón
2015-08-30 17:13 ` jl2012 [this message]
2015-08-30 18:56 ` Jorge Timón
2015-08-31 18:50 ` jl2012
2015-08-28 23:46 ` Btc Drak
2015-08-29 9:15 ` Elliot Olds
2015-08-28 23:38 ` Btc Drak
2015-08-28 23:36 ` Btc Drak
2015-08-28 23:44 ` Jorge Timón
2015-08-29 9:38 ` jl2012
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=8faa4df0135b558e5cd064ccaec09e73@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/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