From: Hector Chu <hectorchu@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Tue, 4 Aug 2015 13:19:18 +0100 [thread overview]
Message-ID: <CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]
On 4 August 2015 at 12:59, Jorge Timón <jtimon@jtimon•cc> wrote:
> That is not my position. Again, I don't know what the right blocksize
> for the short term is (I don't think anybody does).
>
You have no position (i.e. neutral). In other words, keeping the existing
limit.
> Therefore how the change can affect mining centralization must be the
> main concern, instead of (also artificial) projections about usage
> growth (no matter how organic their curves look).
>
The degree of mining decentralization is only one of many concerns. Users'
main concern is timely confirmation of low-fee transactions. Miners'
concern is the amount of profit they make.
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.
>
The limit won't even get to be hit, because all the users that get thrown
out of Bitcoin will have moved over to a system supporting a larger block
size.
I don't know where you get your "majority" from or what it even means
> (majority of users, majority of the coins, of miners?)
>
The majority which the miners are beholden to is the economic majority.
https://en.bitcoin.it/wiki/Economic_majority
> But there's something I'm missing something there...why my position
> doesn't matter if it's not a majority?
>
Your position is only one of many and it does not carry excess weight to
the others. Individually it won't matter, because you can't control the
implementation that other people run.
> How is what the the majority has been told it's best an objective argument?
>
Don't fight the market. The way the system is designed, the miners will
follow along with what the economic majority have decided.
So if you say 8, I must ask, why not 9?
> Why 9 MB is not safe for mining centralization but 8 MB is?
>
8MB has simply been the focal point for this debate. 9MB is also safe if
8MB is, but I suppose the opponents will be even less happy with 9 than
with 8, and we don't want to unnecessarily increase the conflict.
It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
>
A one-time increase to 8MB is safer than a dynamically growing limit over
time for exactly this reason. Admittedly whenever the next debate to
increase the block size over 8MB happens it will be even more painful and
non-obvious, but that is the safety check to prevent unbounded block size
increase.
[-- Attachment #2: Type: text/html, Size: 4348 bytes --]
next prev parent reply other threads:[~2015-08-04 12:19 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 14:25 Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
2015-07-30 15:12 ` Jorge Timón
2015-07-30 16:23 ` Jameson Lopp
2015-07-30 16:36 ` Bryan Bishop
2015-07-30 16:43 ` Jameson Lopp
2015-07-30 16:36 ` Venzen Khaosan
2015-07-30 17:51 ` Jorge Timón
2015-07-30 18:00 ` Jorge Timón
2015-07-30 16:56 ` Gary Mulder
2015-07-30 17:13 ` Mark Friedenbach
2015-07-30 16:20 ` Gavin Andresen
2015-07-30 16:41 ` Suhas Daftuar
2015-07-30 16:48 ` Adam Back
2015-07-30 16:49 ` Pieter Wuille
2015-07-31 10:16 ` Mike Hearn
2015-07-31 11:43 ` Venzen Khaosan
2015-07-31 11:51 ` Jorge Timón
2015-07-31 12:15 ` Mike Hearn
2015-07-31 13:07 ` Marcel Jamin
2015-07-31 14:33 ` Jorge Timón
2015-07-31 14:58 ` Mike Hearn
2015-07-31 15:28 ` Venzen Khaosan
2015-07-31 20:09 ` Elliot Olds
2015-08-04 10:35 ` Jorge Timón
2015-08-04 11:04 ` Hector Chu
2015-08-04 11:27 ` Pieter Wuille
2015-08-04 11:34 ` Hector Chu
2015-08-04 12:10 ` Venzen Khaosan
2015-08-04 13:13 ` Jorge Timón
2015-08-04 13:28 ` Hector Chu
2015-08-04 13:42 ` Venzen Khaosan
2015-08-04 17:59 ` Jorge Timón
2015-08-04 13:12 ` Gavin Andresen
2015-08-04 13:54 ` Pieter Wuille
2015-08-04 14:30 ` Venzen Khaosan
2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan
2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos
2015-08-05 8:14 ` Gareth Williams
2015-08-04 11:59 ` Jorge Timón
2015-08-04 12:19 ` Hector Chu [this message]
2015-08-04 13:34 ` Venzen Khaosan
2015-08-04 13:37 ` Jorge Timón
2015-08-05 7:29 ` Elliot Olds
2015-08-06 1:26 ` Jorge Timón
2015-08-06 13:40 ` Gavin Andresen
2015-08-06 14:06 ` Pieter Wuille
2015-08-06 14:21 ` Gavin Andresen
2015-08-06 14:53 ` Pieter Wuille
[not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen
2015-08-06 15:26 ` Pieter Wuille
2015-08-06 18:43 ` Michael Naber
2015-08-06 18:52 ` Pieter Wuille
2015-08-07 16:06 ` Thomas Zander
2015-08-07 16:30 ` Pieter Wuille
2015-08-07 17:00 ` Thomas Zander
2015-08-07 17:09 ` Pieter Wuille
2015-08-07 21:35 ` Thomas Zander
2015-08-07 22:53 ` Adam Back
2015-08-08 16:54 ` Dave Scotese
2015-08-07 17:50 ` Gavin Andresen
2015-08-07 18:05 ` Jameson Lopp
2015-08-07 18:10 ` Pieter Wuille
2015-08-07 21:43 ` Thomas Zander
2015-08-07 22:00 ` Thomas Zander
2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding
2015-08-06 21:56 ` Peter Todd
2015-08-06 15:25 ` Jorge Timón
2015-08-06 16:03 ` Gavin Andresen
2015-08-06 16:11 ` Mike Hearn
2015-08-06 17:15 ` Jorge Timón
2015-08-06 19:42 ` Gavin Andresen
2015-08-06 20:01 ` Pieter Wuille
2015-08-06 21:51 ` Jorge Timón
2015-08-06 23:09 ` Elliot Olds
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds
2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding
2015-08-09 18:54 ` Mark Friedenbach
2015-08-09 20:14 ` Hector Chu
[not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
2015-08-09 20:48 ` Hector Chu
2015-08-10 4:48 ` Joseph Poon
2015-08-10 17:03 ` odinn
2015-08-10 17:14 ` Pieter Wuille
2015-08-10 17:45 ` odinn
2015-08-09 21:27 ` Tom Harding
2015-08-09 21:40 ` Chris Pacia
2015-08-09 21:45 ` Hector Chu
2015-08-09 21:57 ` Patrick Strateman
2015-08-09 22:03 ` Hector Chu
2015-08-09 22:36 ` Patrick Strateman
2015-08-10 1:52 ` Tom Harding
2015-08-10 3:31 ` Patrick Strateman
2015-08-09 22:06 ` Patrick Strateman
2015-08-09 22:09 ` Hector Chu
2015-08-09 22:27 ` Patrick Strateman
2015-08-09 22:30 ` Hector Chu
2015-08-09 22:44 ` Gavin Andresen
2015-08-09 22:51 ` Btc Drak
2015-08-10 8:27 ` Thomas Zander
2015-08-10 8:36 ` Patrick Strateman
2015-08-10 4:39 ` Joseph Poon
2015-08-10 21:02 ` Anthony Towns
2015-08-10 21:19 ` Anthony Towns
2015-08-10 21:43 ` Adam Back
2015-08-11 9:01 ` Hector Chu
2015-08-11 17:17 ` Simon Liu
2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop
2015-07-30 17:46 ` Jorge Timón
2015-08-02 22:35 ` Anthony Towns
2015-07-30 20:20 ` Thomas Zander
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=CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com \
--to=hectorchu@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/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