From: "Jorge Timón" <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Thu, 6 Aug 2015 17:25:47 +0200 [thread overview]
Message-ID: <CABm2gDo6bpWst-8=pr4+et+jrwNX5bt5CwSTsm5OSj1pncayjA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com>
On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> This is a much more reasonable position. I wish this had been starting
>> point of this discussion instead of "the block size limit must be
>> increased as soon as possible or bitcoin will fail".
>
>
> It REALLY doesn't help the debate when you say patently false statements
> like that.
I'm pretty sure that I can quote Mike Hearn with a sentence extremely
similar to that in this forum or in some of his blog posts (not in
https://medium.com/@octskyward/crash-landing-f5cc19908e32 at a first
glance...).
But yeah, what people said in the past is not very important: people
change their minds (they even acknowledge their mistake some times).
What interests me more it's what people think now.
I don't want to put words in your mouth and you are more than welcome
to correct what I think you think with what you really think.
All I'm trying to do is framing your fears properly.
If I say "all fears related to not raising the block size limit in the
short term can be summarized as a fear of fees rising in the short
term".
Am I correct? Am I missing some other argument?
Of course, problems that need to be solved regardless of the block
size (like an unbounded mempool) should not be considered for this
discussion.
> My first blog post on this issue is here:
> http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> ... and I NEVER say "Bitcoin will fail". I say:
>
> "If the number of transactions waiting gets large enough, the end result
> will be an over-saturated network, busy doing nothing productive. I don’t
> think that is likely– it is more likely people just stop using Bitcoin
> because transaction confirmation becomes increasingly unreliable."
If you pay high enough fees your transactions will be likely mined in
the next block.
So this seems to be reducible to the "fees rising" concern unless I am
missing something.
> So please stop with the over-the-top claims about what "the other side"
> believe, there are enough of those (on both sides of the debate) on reddit.
> I'd really like to focus on how to move forward, and how best to resolve
> difficult questions like this in the future.
I think I would have a much better understanding of what "the other
side" thinks if I ever got an answer to a couple of very simple
questions I have been repeating ad nausea:
1) If "not now" when will it be a good time to let fees rise above zero?
2) When will you consider a size to be too dangerous for centralization?
In other words, why 20 GB would have been safe but 21 GB wouldn't have
been (or the respective maximums and respective +1 for each block
increase proposal)?
On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> What is bad is artificially limiting or centrally controlling the supply of
> that space.
3) Does this mean that you would be in favor of completely removing
the consensus rule that limits mining centralization by imposing an
artificial (like any other consensus rule) block size maximum?
I've been insistently repeating this question too.
Admittedly, it would be a great disappointment if your answer to this
question is "yes": that can only mean that either you don't understand
how the consensus rule limits mining centralization or that you don't
care about mining centralization at all.
If you really want things to move forward, please, prove it by
answering these questions so that we don't have to imagine what the
answers are (because what we imagine is probably much worse than your
actual answers).
I'm more than willing to stop trying to imagine what "big block
advocates" think, but I need your answers from the "big block
advocates".
Asking repeatedly doesn't seem to be effective. So I will answer the
questions myself in the worse possible way I think a "big block
advocate" could answer them.
Feel free to replace my stupid answers with your own:
----------------------- (FICTION ANSWERS [given the lack of real answers])
3) Does this mean that you would be in favor of completely removing
the consensus rule that limits mining centralization by imposing an
artificial (like any other consensus rule) block size maximum?
Yes, I would remove the rule because I don't care about mining centralization.
2) When will you consider a size to be too dangerous for centralization?
In other words, why 20 GB would have been safe but 21 GB wouldn't have
been (or the respective maximums and respective +1 for each block
increase proposal)?
Never, as said I don't care about mining centralization.
I thought users and Bitcoin companies would agree with a 20 GB limit
hardfork with proper lobbying, but I certainly prefer 21 GB.
From 1 MB to infinity, the bigger the better, always.
1) If "not now" when will it be a good time to let fees rise above zero?
Never. Fees are just an excuse, the real goal is making Bitcoin centralized.
------------------------
I'm quite confident that you will have better answers than those.
Please, let me know what you think.
next prev parent reply other threads:[~2015-08-06 15:25 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 14:25 [bitcoin-dev] Block size following technological growth 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
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 [this message]
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='CABm2gDo6bpWst-8=pr4+et+jrwNX5bt5CwSTsm5OSj1pncayjA@mail.gmail.com' \
--to=jtimon@jtimon.cc \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=gavinandresen@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