From: "Jorge Timón" <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Fri, 31 Jul 2015 13:51:04 +0200 [thread overview]
Message-ID: <CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Well, centralization of mining is already terrible. I see no reason why we
>> should encourage making it worse.
>
> I see constant assertions that node count, mining centralisation, developers
> not using Bitcoin Core in their own businesses etc is all to do with block
> sizes. But nobody has shown that. Nobody has even laid the groundwork for
> that. Verifying blocks takes milliseconds and downloading them takes seconds
> everywhere except, apparently, China: this resource usage is trivial.
He is not saying that. Whatever the reasons for centralization are, it
is obvious that increasing the size won't help.
In the best case, it will only make it slightly worse. How big of a
"slightly worse" are we willing to risk to increase the size is the
open question.
> So I see no reason why arbitrarily capping the block size will move the
> needle on these metrics. Trying to arrest the growth of Bitcoin for everyone
> won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs
> migrate away from chain.com, or make merchants stop using BitPay.
As far as I know, people just want to change an arbitrary number for
another arbitrary number.
But this arbitrary cap is a cap to centralization, not a tool to make
Bitcoin-Qt more important or to attack concrete Bitcoin companies like
you seem to think.
If you don't think the blocksize cap helps limiting centralization and
you think it would be fine to completely remove it, then it would be
better for the conversation that you said that directly instead of
supporting other arbitrary caps like 8GB (bip101).
I think it would be nice to have some sort of simulation to calculate
a "centralization heuristic" for different possible blocksize values
so we can compare these arbitrary numbers somehow. Even if the first
definition of this "centralization heuristic" is stupid, it would be
better than keep rolling dices and heatedly defend one result over
another.
To reiterate, If you don't think the blocksize cap helps limiting
centralization, please, say so.
If we can't agree on what the limit is for, we will never be able to
agree on whether 1MB (current situation) or 8GB (bip101) is the most
appropriate value to have at a given point in time.
>> We need to accept that, and all previous proposals I've seen don't seem to
>> do that.
>
> I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
> you're right, some use cases will be priced out. I initiated the
> micropayment channels project (along with Matt, tip of the hat) specifically
> to optimise a certain class of transactions. Even with 8mb+ blocks, there
> will still be a need for micropayment channels, centralised exchange
> platforms and other forms of off chain transaction.
Lightning is nothing more than a better design for trustless payment
channels, but it's really good that you agree that if we want to scale
not everything can be broadcast in-chain.
>> If Bitcoin needs to support a large scale, it already failed.
>
> It hasn't even been tried.
What he means is that if Bitcoin needs to support a scale that is only
feasible with high degrees of centralization (say, supporting 1 M tx/s
right now), then it has already failed in its decentralization goals.
In fact, with only a few miners, I'm not sure regulators will still
agree Bitcoin transactions are irreversible...
But you are right, we haven't tried to destroy bitcoin by removing the
only available consensus tool to limit centralization yet.
I don't want to try, do you?
> A decentralised currency that the vast majority can't use doesn't change the
> amount of centralisation in the world. Most people will still end up using
> banks, with all the normal problems. You cannot solve a problem by creating
> a theoretically pure solution that's out of reach of ordinary people: just
> ask academic cryptographers!
Let's go to "most people use bitcoin" first and then think about "many
people ONLY use Bitcoin" later, please.
I believe everybody here thinks that the more people are able to use
Bitcoin, the better.
But that doesn't
> All the plans for some kind of ultra-throttled Bitcoin network used for
> infrequent transactions neglect to ask where the infrastructure for that
> will come from. The network of exchanges, payment processors and startups
> that are paying people to build infrastructure are all based on the
> assumption that the market will grow significantly. It's a gamble at best
> because Bitcoin's success is not guaranteed, but if the block chain cannot
> grow it's a gamble that is guaranteed to be lost.
Risking destroying Bitcoin through centralization to be able to keep
free transactions for longer it's a very risky gamble.
Doing so explicitly against the will of some of the users by promoting
schism hardfork, and thus risking to economically destroy both Bitcoin
and Bitcoin_new_size (different currencies) in the process is also a
very risky gamble.
So may want to give some example of responsibility yourself to make
these calls to responsibility more credible.
You certainly cannot know what "all the payment processors and
startups plans" are based on, and spreading conspiracy theories about
the evil secret plans of Blockstream (or any other Bitcoin company)
doesn't help in keeping this discussion civilized, contaminates
bitcoin development in general and unhealthily polarizes the whole
Bitcoin ecosystem. Also, I believe is doing a disservice to your
reputation among technical people, but since you don't seem worried
about that, why should I be?
> So why should anyone go through the massive hassle of setting up exchanges,
> without the lure of large future profits?
Are you suggesting that bitcoin consensus rules should be designed to
maximize the profits of Bitcoin exchanges?
I assume not, but I'm really having troubles trying to read the
question with another meaning.
Can you rephrase this, please?
next prev parent reply other threads:[~2015-07-31 11:51 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 [this message]
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
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=CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com \
--to=jtimon@jtimon.cc \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=hearn@vinumeris.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