From: Mark Friedenbach <mark@friedenbach•org>
To: Thomas Zander <thomas@thomaszander•se>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Tue, 11 Aug 2015 00:08:42 -0700 [thread overview]
Message-ID: <CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com> (raw)
In-Reply-To: <1623892.Xps1bl6nlD@coldstorage>
[-- Attachment #1: Type: text/plain, Size: 7615 bytes --]
On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
> > This is where things diverge. It's fine to pick a new limit or growth
> > trajectory. But defend it with data and reasoned analysis.
>
> We currently serve about 0,007% of the world population sending maybe one
> transaction a month.
> This can only go up.
>
> There are about 20 currencies in the world that are unstable and showing
> early
> signs of hyperinflation. If even small percentage of these people cash-out
> and
> get Bitcoins for their savings you'd have the amount of people using
> Bitcoin
> as savings go from maybe half a million to 10 million in the space of a
> couple
> of months. Why so fast? Because all the world currencies are linked.
> Practically all currencies follow the USD, and while that one may stay
> robust
> and standing, the linkage has been shown in the past to cause
> chain-effects.
>
> It is impossible to predict how much uptake Bitcoin will take, but we have
> seen big rises in price as Cyprus had a bailin and then when Greece first
> showed bad signs again.
> Lets do our due diligence and agree that in the current world economy there
> are sure signs that people are considering Bitcoin on a big scale.
>
> Bigger amount of people holding Bitcoin savings won't make the transaction
> rate go up very much, but if you have feet on the ground you already see
> that
> people go back to barter in countries like Poland, Ireland, Greece etc.
> And Bitcoin will be an alternative to good to ignore. Then transaction
> rates
> will go up. Dramatically.
>
> If you are asking for numbers, that is a bit tricky. Again; we are at
> 0,007%... Thats like a f-ing rounding error in the world economy. You can't
> reason from that. Its like using a float to do calculations that you should
> have done in a double and getting weird output.
>
> Bottom line is that a maximum size of 8Mb blocks is not that odd. Because
> a 20
> times increase is very common in a "company" that is about 6 years old.
> For instance Android was about that age when it started to get shipped by
> non-
> Google companies. There the increase was substantially bigger and the
> company
> backing it was definitely able to change direction faster than the Bitcoin
> oiltanker can change direction.
>
> ...
>
> Another metric to remember; if you follow hackernews (well, the incubator
> more
> than the linked articles) you'd be exposed to the thinking of these
> startups.
> Their only criteria is growth. and this is rather substantial growth. Like
> 150% per month. Naturally, most of these build on top of html or other
> existing technologies. But the point is that exponential growth is
> expected
> in any startup. They typically have a much much more agressive timeline,
> though. Every month instead of every year.
> Having exponential growth in the blockchain is really not odd and even if
> we
> have LN or sidechains or the next changetip, this space will be used. And
> we
> will still have scarcity.
I'm sorry, I really don't want to sound like a jerk, but not a single word
of that mattered. Yes we all want Bitcoin to scale such that every person
in the world can use it without difficulty. However if that were all that
we cared about then I would be remiss if I did not point out that there are
plenty of better, faster, and cheaper solutions to finding global consensus
over a payment ledger than Bitcoin. Architectures which are algorithmically
superior in their scaling properties. Indeed they are already implemented
and you can use them today:
https://www.stellar.org/
http://opentransactions.org/
So why do I work on Bitcoin, and why do I care about the outcome of this
debate? Because Bitcoin offers one thing, and one thing only which
alternative architectures fundamentally lack: policy neutrality. It can't
be censored, it can't be shut down, and the rules cannot change from
underneath you. *That* is what Bitcoin offers that can't be replicated at
higher scale with a SQL database and an audit log.
It follows then, that if we make a decision now which destroys that
property, which makes it possible to censor bitcoin, to deny service, or to
pressure miners into changing rules contrary to user interests, then
Bitcoin is no longer interesting. We might as well get rid of mining at
that point and make Bitcoin look like Stellar or Open-Transactions because
at least then we'd scale even better and not be pumping millions of tons of
CO2 into the atmosphere from running all those ASICs.
On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
> problems.
>
Straw man, storage is not an issue.
> You can buy broadband in every relevant country that easily supports the
> bandwidth we need. (remember we won't jump to 8Mb in a day, it will likely
> take at least 6 months).
>
Neither one of those assertions is clear. Keep in mind the goal is to have
Bitcoin survive active censorship. Presumably that means being able to run
a node even in the face of a hostile ISP or government. Furthermore, it
means being location independent and being able to move around. In many
places the higher the bandwidth requirements the fewer the number of ISPs
that are available to service you, and the more visible you are.
It may also be necessary to be able to run over Tor. And not just today's
Tor which is developed, serviced, and supported by the US government, but a
Tor or I2P that future governments have turned hostile towards and actively
censor or repress. Or existing authoritative governments, for that matter.
How much bandwidth would be available through those connections?
It may hopefully never be necessary to operate under such constraints,
except by freedom seeking individuals within existing totalitarian regimes.
However the credible threat of doing so may be what keeps Bitcoin from
being repressed in the first place. Lose the capability to go underground,
and it will be pressured into regulation, eventually.
To the second point, it has been previously pointed out that large miners
stand to gain from larger blocks, for the same basic underlying reasons as
selfish mining. The incentive is to increase blocks, and miners are able to
do so at will and without cost. I would not be so certain that we wouldn't
see large blocks sooner than that.
> We should get the inverted bloom filters stuff (or competing products)
> working
> at least on a one-to-one basis so we can solve the propagation time
> problem.
> There frankly is a huge amount of optimization that can be done in that
> area,
> we don't even use locality (pingtime) to optimize distribution.
> From my experience you can expect a 2-magnitude speedup in that same 6
> month
> period by focusing some research there.
>
This is basically already deployed thanks to Matt's relay network. Further
improvements are not going to have dramatic effects.
> Remember 8Gb/block still doesn't support VISA/Mastercard.
>
No, it doesn't. And 8GB/block is ludicrously large -- it would absolutely,
without any doubt destroy the very nature of Bitcoin, turning it into a
fundamentally uninteresting reincarnation of the existing financial system.
And still be unable to compete with VISA/Mastercard.
So why then the pressure to go down a route that WILL lead to failure by
your own metrics?
I humbly suggest that maybe we should play the strengths of Bitcoin instead
-- it's trustlessness via policy neutrality.
Either that, or go work on Stellar. Because that's where it's headed
otherwise.
[-- Attachment #2: Type: text/html, Size: 9121 bytes --]
next prev parent reply other threads:[~2015-08-11 7:09 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 14:57 Gavin Andresen
2015-08-07 15:16 ` Pieter Wuille
2015-08-07 15:55 ` Gavin Andresen
2015-08-07 16:28 ` Pieter Wuille
2015-08-07 17:47 ` Ryan Butler
2015-08-07 18:25 ` Mark Friedenbach
2015-08-07 18:57 ` Ryan Butler
2015-08-07 19:07 ` Ryan Butler
2015-08-07 19:15 ` Mark Friedenbach
2015-08-07 20:17 ` Ryan Butler
2015-08-07 20:33 ` Dave Hudson
2015-08-07 18:17 ` jl2012
2015-08-07 18:35 ` Bryan Bishop
2015-08-07 18:36 ` Simon Liu
2015-08-11 23:20 ` Elliot Olds
2015-08-07 17:33 ` Jorge Timón
2015-08-07 22:12 ` Thomas Zander
2015-08-07 23:06 ` Adam Back
2015-08-08 22:45 ` Dave Scotese
2015-08-08 23:05 ` Alex Morcos
2015-08-09 5:52 ` Hector Chu
2015-08-09 10:32 ` Thomas Zander
2015-08-09 10:42 ` Thomas Zander
2015-08-09 20:43 ` Dave Scotese
2015-08-11 17:03 ` Jorge Timón
2015-08-10 11:55 ` Jorge Timón
2015-08-10 12:33 ` Btc Drak
2015-08-10 13:03 ` Jorge Timón
2015-08-10 22:13 ` Thomas Zander
2015-08-11 17:47 ` Jorge Timón
2015-08-11 18:46 ` Michael Naber
2015-08-11 18:48 ` Mark Friedenbach
2015-08-11 18:55 ` Michael Naber
2015-08-11 19:45 ` Jorge Timón
2015-08-11 21:31 ` Michael Naber
2015-08-11 18:51 ` Bryan Bishop
2015-08-11 18:59 ` Michael Naber
2015-08-11 19:27 ` Jorge Timón
2015-08-11 19:37 ` Michael Naber
2015-08-11 19:51 ` Pieter Wuille
2015-08-11 21:18 ` Michael Naber
2015-08-11 21:23 ` Adam Back
2015-08-11 21:30 ` Angel Leon
2015-08-11 21:32 ` Pieter Wuille
2015-08-11 21:34 ` Adam Back
2015-08-11 21:39 ` Michael Naber
2015-08-12 6:10 ` Venzen Khaosan
2015-08-11 22:06 ` Angel Leon
2015-08-11 21:35 ` Michael Naber
2015-08-11 21:51 ` Pieter Wuille
2015-08-12 3:35 ` Elliot Olds
2015-08-12 4:47 ` Venzen Khaosan
2015-08-14 21:47 ` Elliot Olds
2015-08-12 0:56 ` Tom Harding
2015-08-12 1:18 ` Eric Voskuil
2015-08-12 8:10 ` Thomas Zander
2015-08-12 9:00 ` Jorge Timón
2015-08-12 9:25 ` Thomas Zander
2015-08-11 19:53 ` Jorge Timón
2015-08-11 20:56 ` Michael Naber
2015-08-12 7:54 ` Thomas Zander
2015-08-12 8:01 ` Thomas Zander
[not found] ` <1679272.aDpruqxXDP@coldstorage>
2015-08-12 8:51 ` Jorge Timón
2015-08-12 9:23 ` Thomas Zander
2015-08-12 9:45 ` Jorge Timón
2015-08-12 16:24 ` Thomas Zander
2015-08-17 14:49 ` BitMinter operator
2015-08-17 15:01 ` Peter Todd
2015-08-10 14:12 ` Gavin Andresen
2015-08-10 14:24 ` Alex Morcos
2015-08-10 22:12 ` Thomas Zander
2015-08-10 14:34 ` Pieter Wuille
2015-08-10 22:04 ` Thomas Zander
2015-08-20 14:40 ` Will Madden
2015-08-10 14:55 ` Jorge Timón
2015-08-10 22:09 ` Thomas Zander
2015-08-10 22:52 ` Pieter Wuille
2015-08-10 23:11 ` Pieter Wuille
2015-08-11 5:34 ` Thomas Zander
2015-08-11 6:03 ` Mark Friedenbach
2015-08-11 6:31 ` Thomas Zander
2015-08-11 7:08 ` Mark Friedenbach [this message]
2015-08-11 8:38 ` Thomas Zander
2015-08-11 9:14 ` Angel Leon
2015-08-11 19:00 ` Mark Friedenbach
2015-08-11 19:26 ` Michael Naber
2015-08-11 20:12 ` Adam Back
2015-08-12 0:32 ` odinn
2015-08-11 11:10 ` Thomas Zander
2015-08-12 0:18 ` odinn
2015-08-07 21:30 ` Jim Phillips
2015-08-07 18:22 ` Anthony Towns
2015-08-07 18:36 ` Peter R
2015-08-12 1:56 Corey Haddad
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='CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com' \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=thomas@thomaszander$(echo .)se \
/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