Mike Hearn [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-31 đź“ť Original message:> > How more users or more ...
đź“… Original date posted:2015-07-31
đź“ť Original message:>
> 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?
I mean, I guess I don't know how to answer your question. 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. Surely the
correlation is obvious?
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?
> 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.
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
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.
> 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.
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.
> Sorry, I don't know about Pieter, but I was mostly talking about
> mining centralization, certainly not about payment services.
>
OK. I write these emails for other readers too :) In the past for instance,
developers who run services without running their own nodes has come up.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/7730a126/attachment-0001.html>;
đź“ť Original message:>
> 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?
I mean, I guess I don't know how to answer your question. 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. Surely the
correlation is obvious?
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?
> 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.
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
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.
> 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.
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.
> Sorry, I don't know about Pieter, but I was mostly talking about
> mining centralization, certainly not about payment services.
>
OK. I write these emails for other readers too :) In the past for instance,
developers who run services without running their own nodes has come up.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/7730a126/attachment-0001.html>;