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 16:33:14 +0200 [thread overview]
Message-ID: <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Hey Jorge,
>
>> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
How more users or more nodes can bring more miners, or more
importantly, improve mining decentralization?
> To repeat: it's not obvious to me at all that everything wrong with Bitcoin
> can be solved by shrinking blocks. I don't think that's going to suddenly
> make everything magically more decentralised.
I don't think anybody is defending that position so you can stop refuting it.
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be high
> enough to ensure organic growth is not constrained, which is good enough.
Well, negatiations don't make the number less arbitrary. As far as I
know, the sequence of events was this:
1) Gavin proposes 20MB to 20GB
2) Some chinese miners say they can securely handle at most 8 MB.
3) Gavin proposes 8 MB to 8 GB
In any case, history is irrelevant for this point: if party 1 proposes
arbitrary value A and party 2 proposes arbitrary value B, any
"compromise" value between those 2 is still an arbitrary value. For
example, A + ((B-A)/2) is still an arbitrary value.
I'm sorry, but until there's a simulation that I can run with
different sizes' testchains (for example using #6382) to somehow
compare them, I will consider any value arbitrary. A "I run this with
blocksize=X and nothing seems to have broken" doesn't help here.
We need to compare, and a criterion to compare.
>> 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.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the source
> code.
Agreed on the first sentence, I'm just saying that the influence of
the blocksize in that function is monotonic: with bigger sizes, equal
or worse mining centralization.
About the second sentence, yes, I could destroy Bitcoin by changing
one single constant if I could somehow force users to adopt my version
of the software. I'm sure I can actually find several examples if
necessary. "Through centralization" is harder, but say we chose
std::numeric_limits<int64_t>::max() as the maximum block size (in
practice, entirely removing the block size limit), then the consensus
rules don't have any rule to limit mining centralization.
Sacrificing that tool, and doing so this early on could certainly turn
Bitcoin into an effectively centralized system, destroying Bitcoin (or
at least the "p2p currency" part of it, which is the most interesting
one for many Bitcoin users including me).
So, once it's clear that nobody is saying that centralization depends
ONLY on the block size, can you tell us please if you think it's
useful for limiting mining centralization or not?
If you think the blocksize consensus limit does nothing to limit
centralization then there's no tradeoff to consider and you should be
consequently advocating for full removal of the limit rather than
changes towards bigger arbitrary values.
Otherwise you may want to explain why you think 8 GB is enough of a
limit to impede further centralization.
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
Sorry, I don't know about Pieter, but I was mostly talking about
mining centralization, certainly not about payment services.
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
No, that's not what we are doing.
It's good that you talk about your fears but, please, let other people
talk about theirs on their own.
>> > 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?
>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The motivation
> is profit, and profits are higher when there are more users to sell to. This
> is business 101.
I can imagine a non-for-profit exchange but there's no point in
finding edge cases: no general disagreement here.
> If you remove the potential for future profit, you remove the motivation to
> create the services that we now enjoy and take for granted. Because if you
> think Bitcoin can be useful without exchanges then let me tell you, I was
> around when there were none. Bitcoin was useless.
My first post on the bitcoin forums (and vague hardfork proposal, I
started reading in December 2010) was January 21, 2011 (vs yours Dec
14th 2010, as Greg pointed out in the other thread). I bought my first
bitcoins (and also sold most of them shortly after, stupid me) using
some web that used paypal and was closed down not too long after that.
At first I couldn't participate in exchanges because I had no Liberty
Reserve account...
Look, I'm sure there's many stories about how we met Bitcoin that we
can share having a beer in a bar or something. But probably most of
the subscribers to this list don't really care, and if they care they
can ask us privately, or you can create a new thread (probably better
in bitcointalk or somewhere else than here): they are completely
irrelevant in this technical discussion.
So, back on-topic: do I agree that exchanges are extremely important
for the Bitcoin ecosystem?
Yes, of course I do.
But that doesn't mean that their "potential for future profit" should
be a primary concern when deciding consensus rules changes that affect
ALL users.
But even before that, I disagree with the premise that "not rising the
consensus blocksize as soon as possible" will ruin the exchanges or
"remove their potential for future profit".
next prev parent reply other threads:[~2015-07-31 14:33 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 [this message]
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=CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@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