From: "Jorge Timón" <jtimon@jtimon•cc>
To: jl2012@xbt•hk
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Sun, 30 Aug 2015 20:56:22 +0200 [thread overview]
Message-ID: <CABm2gDp=1XHzyXF=JbVLWzfyuFKSnbMbDwLk_2NpWq5s3vukpA@mail.gmail.com> (raw)
In-Reply-To: <8faa4df0135b558e5cd064ccaec09e73@xbt.hk>
On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt•hk> wrote:
> 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
> [...]
No, I'm not making such assumption. I'm focusing on what they CAN do,
while suspending judgement on their good will and not trying to
predict their future behavior from historic behaviour.
With 60% of the hashrate, you can easily get 100% by orphaning
everybody else's blocks. More importantly, being under the same
jurisdiction they can be forced to behave in certain way (for example,
censor transactions) by law.
I'm very worried about the current situation no matter how benevolent
current miners are. Thus weakening the only limit to mining
centralization that we have at the consensus rule level seems
extremely risky at this point.
> 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)
My point is, a "soft cap" determined by miners clearly doesn't protect
us from mining centralization: the "hard cap" does.
Knowing that, and given that miners can currently set their own policy
block size maximum, what does this "voting on a lower limit" achieve?
What are the gains? Why are we "lucky" if they keep the lower one as
low as possible?
> 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.
Thank you for admitting it is not urgent!
I suggested 5 years for the concrete hardfork in bip99 because it's
clearly non-urgent and I wanted to be very conservative. I'm happy to
reduce that to say, 1 year (specially given that the change is very
simple to implement).
For a simple block size change (like, say bip102) 1 year (maybe 6
months + miner's confirmation) is probably more than enough as well.
And we can always deploy an urgency hardfork if it is necessary.
> 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.
Fortunately we haven't been discussing this for 5 years, I don't know
where you get that from.
A schism fork it's certainly always a possibility but I would only
consider it after an urgency hardfork (once the issue becomes urgent)
fails due to not being uncontroversial.
Would you agree with me on that?
What would be your criterion for considering an increase in block size urgent?
Mine is: we should consider a block increase only when minimum market
fees for transactions to be mined (currently zero satoshis) increase
above a high fee (admittedly undefined, but certainly greater than
zero).
Even if it's "urgent", I think we should only increase the maximum if,
at the same time, the new size can be considered safe
mining-centralization-wise (unfortunately we don't have any metric to
measure that nor enough tools to realistically simulate different
sizes in different network topologies at the moment). But once we have
them, the next discussion will be much simpler, so I don't see the
need for block size maximum that changes over time (neither
exponentially nor linearly).
Would you agree with me that mining centralization should be the most
important criterion when changing the block size maximum rule rather
than the level of minimum fees?
If the community can't agree on this, I'm afraid there will be a
schism hardfork eventually. Another possibility is that those who
aren't concerned with mining centralization start their own altcoin
(centralizedcoin? ), maybe a spinoff [
https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
keep Bitcoin's utxo at the moment of the separation.
But if the community agrees with this and just disagrees on the
maximum block size consensus rule having any effect on mining
centralization (like Gavin and I disagree), we should calm down and
use scientific processes to find out what the relation between the two
actually is (if there's any relation at all).
Would you agree with me on this?
next prev parent reply other threads:[~2015-08-30 18:56 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
2015-08-30 18:56 ` Jorge Timón [this message]
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='CABm2gDp=1XHzyXF=JbVLWzfyuFKSnbMbDwLk_2NpWq5s3vukpA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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