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

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

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.

- Eric Lombrozo

> On Jun 27, 2015, at 4:04 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
> 
> On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg@hush.com> wrote:
>> 
>> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote:
>> 
>>> Then you won't risk the other 'passengers' who don't consent to it.
>> 
>> But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore?
>> 
>> Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard.
> 
> But that option is not unknown, that's the point of this thread.
> "Doing nothing" would require to fix the mempool to scale with the
> number of unconfirmed transaction. This is something that we will
> eventually have to fix unless the plan is to eventually remove the
> blocksize limit.
> What will happen with full blocks is that fees will likely rise and
> the transactions with bigger fees will get confirmed first. This is
> something that will eventually happen unless the blocksize limit is
> removed before ever being hit.
> What this thread is saying is that this option (the so-called "doing
> nothing" option, which actually requires more work than any of the
> current proposals for increasing the blocksize) is perfectly valid,
> which is in contradiction to a perceived "need to increase the
> blocksize limit soon". Increasing the block size is only an option,
> not a "need". And changing the consensus rules and forcing everybody
> to adapt their software to the changes is certainly not "maintaining
> the status quo", I'm getting tired of hearing that absurd notion.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  reply	other threads:[~2015-06-27 11:18 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 [this message]
2015-06-27 11:43             ` Jorge Timón
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=1E68C70C-B33E-4414-B48B-7A497B59C893@gmail.com \
    --to=elombrozo@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /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