From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Jeff Garzik <jgarzik@gmail.com>
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Date: Fri, 17 Jul 2015 20:29:16 +0000 [thread overview]
Message-ID: <201507172029.17056.luke@dashjr.org> (raw)
In-Reply-To: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1 MB
lately. The only reason block size limit lifting is remotely reasonable is if
we can trust miners to at the very least keep their soft limits set at a
manageable size, but this assumption appears to already be failing in
practice.
We are unlikely to approach 1 MB of actual volume by November, so I would
prefer to see the activation date on this moved later - maybe November 2016,
if not 2017. It would also be an improvement to try to follow reasonably-
expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubling
in only a few months seems to be far from a "conservative" increase.
If we can get some kind of commitment from miners not to move their soft
limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
acceptable as-is.
On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
> It establishes a precedent for hard forks not to require a vote though.
Hardforks are not something where voting makes sense. They need consensus
among /nodes/, not majority among /miners/. No hardfork has ever had such a
vote.
Luke
next prev parent reply other threads:[~2015-07-17 20:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14 ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06 ` Chris Wardell
2015-07-17 19:13 ` Ross Nicoll
2015-07-19 22:51 ` Ross Nicoll
2015-07-21 9:26 ` Jorge Timón
2015-07-21 13:04 ` Peter Todd
2015-07-21 13:58 ` Peter Todd
2015-07-22 15:51 ` Tom Harding
2015-07-22 17:02 ` Sriram Karra
2015-07-22 17:40 ` Sriram Karra
2015-07-22 17:43 ` Jeff Garzik
2015-07-22 22:30 ` Peter Todd
2015-07-23 5:39 ` jl2012
2015-07-22 17:00 ` jl2012
2015-07-21 22:05 ` Ross Nicoll
2015-07-23 11:24 ` Jorge Timón
2015-07-17 20:29 ` Luke Dashjr [this message]
2015-07-17 21:13 ` Angel Leon
2015-07-17 22:25 ` Tier Nolan
2015-07-18 9:22 ` Jorge Timón
2015-07-18 9:24 ` Jorge Timón
2015-07-24 8:52 ` Thomas Zander
2015-07-24 9:43 ` Slurms MacKenzie
2015-07-18 4:32 ` Venzen Khaosan
2015-07-17 22:40 Raystonn
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=201507172029.17056.luke@dashjr.org \
--to=luke@dashjr.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jgarzik@gmail.com \
/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