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: Tue, 4 Aug 2015 12:35:06 +0200 [thread overview]
Message-ID: <CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris•com> wrote:
>> How more users or more nodes can bring more miners, or more importantly,
>> improve mining decentralization?
>
>
> Because the bigger the ecosystem is the more interest there is in taking
> part?
As explained by Venzen, this is a non-sequitur.
> I mean, I guess I don't know how to answer your question.
I don't know the answer either, that's fine. It's the opposite
question that I've been insistently repeating and you've been
(consciously or not) consistently evading.
But that's also fine because I believe you finally answer it a few lines below.
> When Bitcoin was
> new it had almost no users and almost no miners. Now there are millions of
> users and factories producing ASICs just for Bitcoin.
The emergence of a btc price enabled the emergence of professional
miners, which in turn enabled the emergence of sha256d-specialized
hardware production companies.
Nothing surprising there.
By no means it consitutes an example of how a bigger consensus sizes
can cause less mining centralization.
> Surely the correlation is obvious?
Correlation does not imply causation. I will better leave it at that...
>> 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.
>
>
> Gavin did run simulations. 20mb isn't arbitrary, the process behind it was
> well documented here:
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>
> I chose 20MB as a reasonable block size to target because 170 gigabytes per
> month comfortably fits into the typical 250-300 gigabytes per month data
> cap– so you can run a full node from home on a “pretty good” broadband plan.
>
> Did you think 20mb was picked randomly?
No, I think 20 MB was chosen very optimistically, considering 3rd
party services rates (not the same service as self-hosting) in the
so-called "first world". And then 20 MB goes to 20 GB, again with
optimistic and by no means scientific expectations.
But where the number comes from it's not really what I'm demaning,
what I want is some criterion that can tell you that a given size
would be "too centralized" but another one isn't.
I haven't read any analysis on why 8GB is a better option than 7GB and
9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
or 21 GB).
A simulation test passing 20 GB but not 21 GB would make it far less arbitrary.
>> 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.
>
>
> I have a hard time agreeing with this because I've seen Bitcoin go from
> blocks that were often empty to blocks that are often full, and in this time
> the number of miners and hash power on the network has gone up a huge amount
> too.
I'm of course talking about consensus maximum blocksize, not about
actual blocksize.
Yes, again, when mining becomes profitable, economic actors tend to
appear and get those profits.
But don't confuse total hashrate improvements with an "increase in the
number of miners" or with mining decentralization.
> You can argue that a miner doesn't count if they pool mine. But if a miner
> mines on a pool that uses exactly the same software and settings as the
> miner would have done anyway, then it makes no difference. Miners can switch
> between pools to find one that works the way they like, so whilst less
> pooling or more decentralised pools would be nice (e.g. getblocktemplate),
> and I've written about how to push it forward before, I still say there are
> many more miners than in the past.
>
> If I had to pick between two changes to improve mining decentralisation:
>
> 1) Lower block size
Finally, I think you finally answered my repetitive question here.
If I say "Mike Hearn understands that the consensus block size maximum
rule is a tool for limitting mining centralization" I'm not putting
words in your mouth, right?
I think many users advocating for an increase in the consensus limit
don't understand this, which is extremely unfortunate for the debate.
> 2) Finishing, documenting, and making the UX really slick for a
> getblocktemplate based decentralised mining pool
>
> then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
Great! Maybe after 2 mining centralization improves so much that we're
confortable not only not lowering it but rather increasing it.
>> you should be consequently advocating for full removal of the limit rather
>> than changes towards bigger arbitrary values.
>
>
> I did toy with that idea a while ago. Of course there can not really be no
> limit at all because the code assumes blocks fit into RAM/swap, and nodes
> would just end up ignoring blocks they couldn't download in time anyway.
> There is obviously a physical limit somewhere.
Did the fact that you "understand that the consensus block size
maximum rule is a tool for limitting mining centralization" influenced
your rejection of that idea at all?
> But it is easier to find common ground with others by compromising. Is 8mb
> better than no limit? I don't know and I don't care much: I think Bitcoin
> adoption is a slow, hard process and we'll be lucky to increase average
> usage 8x over the next couple of years. So if 8mb+ is better for others,
> that's OK by me.
The only way that "not caring much whther we have a consensus limit or
not" and "understand that the consensus block size maximum rule is a
tool for limitting mining centralization" at the same time is by not
caring about mining centralization at all.
Is that your position?
If you don't care about having a limit but you don't want to limit
transaction volume, then ++current_size will ALWAYs be your
"compromise position" and no blocksize increase will ever be enough
until the limit is completely removed.
Is that your position?
> Re: exchange profit. You can pick some other useful service provider if you
> like. Payment processors or cold storage providers or the TREZOR
> manufacturers or whoever.
Yes, and I believe the same points stand.
> My point is you can't have a tiny high-value-transactions only currency AND
> all the useful infrastructure that the Bitcoin community is making. It's a
> contradiction. And without the infrastructure bitcoin ceases to be
> interesting even to people who are willing to pay huge sums to use it.
You keep talking about "high-value-transactions-only" like if
non-urgent transaction fees rising from zero to, say, 1 satoshi, would
automatically result in that "high-value-transactions-only" Bitcoin.
Please, stop talking as if someone was proposing a
"high-value-transactions-only" Bitcoin. That may happen but nobody
really knows. If it happens it may not be bad thing necessarily (ie
bitcoin microtransactions can still happen using trustless payment
channels and x is still cheaper than x% for any transacted value
higher than 100) but that's really not what we're talking about here
so it seems distraction that can only help further polirizing this
discussion.
What we're talking about here is that hitting the limit would
(hopefully) make miners start caring about fees. Enough that they stop
being irrational about free transactions. If both things happen,
non-urgent transaction fees will likely rise (as said, above zero).
You think that would be a catastrophe for adoption and I disagree.
But (as Pieter has repeatedly explained) for any size there will be
use cases that will be eventually priced out.
So when rising this consensus limit, not increasing centralization
should be the priority and the potential impact in market fees a much
more secondary concern.
Do you agree with this?
I'm sure there are many intermediate positions between "caring more
about mining centralization than market fees when deciding about a
consensus rule that limits mining centralization" and "not caring
about mining centralization at all".
I really don't want to put words in your mouth, but I honestly don't
know what your position is.
I don't really know how else can I ask the same question: you don't
care the consensus maximum blocksize rule being here at all or not
(you just said that).
Is it because you don't think it limits mining centralization or
because you don't care about limiting mining centralization with
consensus rules at all?
next prev parent reply other threads:[~2015-08-04 10:35 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
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 [this message]
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='CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hearn@vinumeris$(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