From: Mike Hearn <hearn@vinumeris•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Fri, 31 Jul 2015 12:16:46 +0200 [thread overview]
Message-ID: <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5176 bytes --]
I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not "let's all use Lightning") -
this BIP is virtually the same as keeping the 1mb cap.
> Well, centralization of mining is already terrible. I see no reason why we
> should encourage making it worse.
>
Centralization of mining has been a continual gripe since Slush first
invented pooled mining. There has never been a time after that when people
weren't talking about the centralisation of mining, and back then blocks
were ~10kb.
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.
Yet developers, miners and users even outside of China routinely delegate
validation to others. Often for quite understandable technical reasons that
have nothing to do with block sizes.
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.
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.
If Bitcoin needs to support a large scale, it already failed.
>
It hasn't even been tried.
The desperately sad thing about all of this is that there's going to be a
fork, and yet I think most of us agree on most things. But we don't agree
on this.
Bitcoin can support a large scale and it must, for all sorts of reasons.
Amongst others:
1. Currencies have network effects. A currency that has few users is
simply not competitive with currencies that have many. There's no such
thing as a settlement currency for high value transactions only, as
evidenced by the ever-dropping importance of gold.
2. 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!
3. Growth is a part of the social contract. It always has been.
The best quote Gregory can find to suggest Satoshi wanted small blocks
is a one sentence hypothetical example about what *might* happen if
Bitcoin users became "tyrannical" as a result of non-financial transactions
being stuffed in the block chain. That position makes sense because his
scaling arguments assuming payment-network-sized traffic and throwing DNS
systems or whatever into the mix could invalidate those arguments, in the
absence of merged mining. But Satoshi did invent merged mining, and so
there's no need for Bitcoin users to get "tyrannical": his original
arguments still hold.
4. 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.
So why should anyone go through the massive hassle of setting up
exchanges, without the lure of large future profits?
5. Bitcoin needs users, lots of them, for its political survival. There
are many people out there who would like to see digital cash disappear, or
be regulated out of existence. They will argue for that in front of
governments and courts .... some already are. And if they're going to lose
those arguments, the political and economic damage of getting rid of
Bitcoin must be large enough to make people think twice. That means it
needs supporters, it needs innovative services, it needs companies, and it
needs legal users making legal payments: as many of them as possible.
If Bitcoin is a tiny, obscure currency used by drug dealers and a
handful of crypto-at-any-cost geeks, the cost of simply banning it outright
will seem trivial and the hammer will drop. There won't be a large scale
payment network OR a high-value settlement network. And then the world is
really screwed, because nobody will get a second chance for a very long
time.
[-- Attachment #2: Type: text/html, Size: 6012 bytes --]
next prev parent reply other threads:[~2015-07-31 10:16 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 [this message]
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
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='CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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