public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Sat, 27 Jun 2015 13:43:55 +0200	[thread overview]
Message-ID: <CABm2gDqvSCCTgjifpxZAy6wgb_f3yKp9-8P2d=n9fWdWxSGayA@mail.gmail.com> (raw)
In-Reply-To: <1E68C70C-B33E-4414-B48B-7A497B59C893@gmail.com>

On Sat, Jun 27, 2015 at 1:18 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> The economic policy’s status quo has been to avoid fee pressure. But the consensus status quo obviously is not to have a hard fork.
>
> There’s clearly a contradiction between these two policies, which is a big part of the reason this issue has come to this point. These two policies are fundamentally at odds.

Ok, so then the decision is to either change a policy or change a
consensus rule and then maintaining the status quo is simply not
possible.
Since per-node and per-wallet policies weren't universal anyway
(nobody can be forced to run the standard policy), making some changes
to the policy code of the different implementations that weren't
prepared for the current consensus rules (that includes bitcoin core)
seems orders of magnitude closer to "maintaining the status quo" than
a hardfork.
It's interesting to note that increasing the blocksize without fixing
the underlying problems that make it a perceived "need" will leave the
implementations unprepared for the new rules too (it is just
unprepared for ANY block size limit, not specifically unprepared for
1MB blocks).
So increasing the block size is actually the "lazy option" regardless
of how the "doing nothing option" is perceived by many uninformed
participants in the discussions.
Then I guess by "maintaining the status quo" some people just mean
"not fixing the known problems we have yet, leave it for later". Not
only some people propose to delay solving this problems: they don't
even want to be forced to fix them in 20 years!
That...or they just want to remove the block size limit entirely
forever, don't fear centralization, and are not being clear about it.


  reply	other threads:[~2015-06-27 11:43 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille
2015-06-26 14:38 ` Venzen Khaosan
2015-06-26 15:22 ` Milly Bitcoin
2015-06-26 15:24   ` Pieter Wuille
2015-06-26 18:05     ` Jeff Garzik
2015-06-26 18:32       ` Milly Bitcoin
2015-06-26 15:38 ` Tom Harding
2015-06-26 16:22   ` Venzen Khaosan
2015-06-26 17:04     ` Tom Harding
2015-06-26 17:55       ` Gavin Andresen
2015-06-26 17:57 ` Jeff Garzik
2015-06-26 18:12   ` Pieter Wuille
2015-06-26 18:23     ` Jeff Garzik
2015-06-26 18:31       ` Mark Friedenbach
2015-06-26 19:05         ` Aaron Voisine
2015-06-26 18:34       ` Pieter Wuille
2015-06-26 19:18         ` Ross Nicoll
2015-06-26 19:36           ` Peter Todd
2015-06-27  6:13             ` Filipe Farinha
2015-06-27  7:14               ` Aaron Voisine
2015-06-27 15:13                 ` Peter Todd
2015-06-27 19:40                   ` Aaron Voisine
2015-06-26 18:47       ` Patrick Strateman
2015-06-26 19:03         ` Tier Nolan
2015-06-26 19:12           ` Mark Friedenbach
2015-06-26 20:44       ` Owen Gunden
2015-06-27  2:18         ` Eric Lombrozo
2015-06-27  2:54           ` Eric Lombrozo
2015-06-27  8:16           ` Venzen Khaosan
2015-06-26 18:29     ` Alex Morcos
2015-06-27  7:43 ` Wladimir J. van der Laan
2015-06-27  9:55   ` NxtChg
2015-06-27 10:04     ` Wladimir J. van der Laan
2015-06-27 10:29       ` NxtChg
2015-06-27 11:04         ` Jorge Timón
2015-06-27 11:18           ` Eric Lombrozo
2015-06-27 11:43             ` Jorge Timón [this message]
2015-06-27 12:10           ` NxtChg
2015-06-28 12:13             ` Jorge Timón
2015-06-28 13:51               ` Ivan Brightly
2015-06-28 14:13                 ` Eric Lombrozo
2015-06-28 14:16                 ` Eric Lombrozo
2015-06-28 14:22                   ` Ivan Brightly
2015-06-28 15:05                 ` Jorge Timón
2015-06-28 16:01                   ` Ivan Brightly
2015-06-28 15:28               ` s7r
2015-06-28 15:45                 ` Jorge Timón
2015-06-27 10:19     ` Venzen Khaosan
2015-06-27 19:55       ` Aaron Voisine
2015-06-28 16:37         ` Venzen Khaosan
2015-06-28 20:56           ` Aaron Voisine
2015-06-27 10:13   ` Jorge Timón
2015-06-27 12:09     ` Wladimir J. van der Laan
2015-06-27 12:15       ` NxtChg
2015-06-27 12:17         ` Greg Sanders
2015-06-27 12:25           ` NxtChg
2015-06-27 12:35             ` Greg Sanders
2015-06-27 12:25         ` Wladimir J. van der Laan
2015-06-27 12:50           ` NxtChg
2015-06-27 13:01             ` Wladimir J. van der Laan
2015-06-28 12:03       ` Jorge Timón

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='CABm2gDqvSCCTgjifpxZAy6wgb_f3yKp9-8P2d=n9fWdWxSGayA@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@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