Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-17 📝 Original message:On Friday, July 17, 2015 ...
📅 Original date posted:2015-07-17
📝 Original message: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
📝 Original message: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