"Conclusion
The blockchain permanently restricted to 1MB is great if you are a major bank looking to co-opt the network for a next generation limited trust settlement network between major banks, financial service providers, and payment processors. It is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary."
great post.
Topic: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... - page 23. (Read 105071 times)
February 05, 2015, 02:48:48 AM
February 05, 2015, 02:48:11 AM
Agreed, and thanks for the taking the time to thoroughly explain and hopefully set some people straight on this.
[...but dang, I was scared for a second after reading the post title but before the post content had loaded
]
February 05, 2015, 02:21:35 AM
D&T, a very informative OP.
Empirically, ~1MB blocks support 2.7 tps.
https://bitcointalksearch.org/topic/m.10360199
Empirically, ~1MB blocks support 2.7 tps.
https://bitcointalksearch.org/topic/m.10360199
February 05, 2015, 02:07:08 AM
my point is: the chain is already pretty big. If it becomes 20 fold as big i will be forced to stop using bitcoin because i don't want a lite-client or rely on 3rd parties with my coins but on the other hand can't afford upgrading harddrive all the time (especially not with these bad btc prices).
If you raise blocklimit 20-fold it will become unaffordable for normal people to store the blockchain on their computers and because of that people loose access.
If you raise blocklimit 20-fold it will become unaffordable for normal people to store the blockchain on their computers and because of that people loose access.
Why does everyone believe that raising the block limit will instantly raise the blockchain too? It will not. It will take time until that will happen!
February 05, 2015, 01:49:27 AM
my point is: the chain is already pretty big. If it becomes 20 fold as big i will be forced to stop using bitcoin because i don't want a lite-client or rely on 3rd parties with my coins but on the other hand can't afford upgrading harddrive all the time (especially not with these bad btc prices).
If you raise blocklimit 20-fold it will become unaffordable for normal people to store the blockchain on their computers and because of that people loose access.
On a sidenote:
I am not the only one totally annoyed by how bitcoin behaves in an effort to keep the dominant position and be the 'one coin for all' and with this hurts the alt-industry. I think at this point it becomes inevitable to start using more than one chain and stop looking at btc as the only coin worth bothering with.
All the problems dissolve at exactly the moment we accept a multi-coin/chain solution.
according to OP, if i understand right: if we don't raise limit little people loose access (i doubt it)
BUT raising the blocklimit will also ensure little people to loose access.
Conclusion: one blockchain for everyone is no viable idea
With raising the blocklimit and creating a chain as big as 200gb and more as soon as 1 or 2 years down the road bitcoin won't be able to reach the enduser.
If you raise blocklimit 20-fold it will become unaffordable for normal people to store the blockchain on their computers and because of that people loose access.
On a sidenote:
I am not the only one totally annoyed by how bitcoin behaves in an effort to keep the dominant position and be the 'one coin for all' and with this hurts the alt-industry. I think at this point it becomes inevitable to start using more than one chain and stop looking at btc as the only coin worth bothering with.
All the problems dissolve at exactly the moment we accept a multi-coin/chain solution.
according to OP, if i understand right: if we don't raise limit little people loose access (i doubt it)
BUT raising the blocklimit will also ensure little people to loose access.
Conclusion: one blockchain for everyone is no viable idea
With raising the blocklimit and creating a chain as big as 200gb and more as soon as 1 or 2 years down the road bitcoin won't be able to reach the enduser.
February 05, 2015, 01:17:10 AM
Excellent post. This was very clear and the best 'pro' argument for the fork. It pretty much squashed any of those ridiculous (no, we have not had a real 'anti-fork arguments) in the other thread.
It's nice to see that we still have a few very intelligent individuals.
It's nice to see that we still have a few very intelligent individuals.
February 05, 2015, 01:16:05 AM
Great post obviously.
As for what to replace the 1 MB anti-spam restriction with, I think Gavin's proposal is very good:
http://gavintech.blogspot.ca/2015/01/twenty-megabytes-testing-results.html
Instead of sudden and massive block size limit increases every two or four years, it would increase a little every block.
As for what to replace the 1 MB anti-spam restriction with, I think Gavin's proposal is very good:
http://gavintech.blogspot.ca/2015/01/twenty-megabytes-testing-results.html
Quote
But then we need a concrete proposal for exactly how to increase the size. Here's what I will propose:
1. Current rules if no consensus as measured by block.nVersion supermajority.
Supermajority defined as: 800 of last 1000 blocks have block.nVersion == 4
Once supermajority attained, block.nVersion < 4 blocks rejected.
2. After consensus reached: replace MAX_BLOCK_SIZE with a size calculated based on starting at 2^24 bytes (~16.7MB) as of 1 Jan 2015 (block 336,861) and doubling every 6*24*365*2 blocks -- about 40% year-on-year growth. Stopping after 10 doublings.
3. The perfect exponential function:
size = 2^24 * 2^((blocknumber-336,861)/(6*24*365*2))
... is approximated using 64-bit-integer math as follows:
This is a piecewise linear interpolation between doublings, with maximum allowed size increasing a little bit every block.
1. Current rules if no consensus as measured by block.nVersion supermajority.
Supermajority defined as: 800 of last 1000 blocks have block.nVersion == 4
Once supermajority attained, block.nVersion < 4 blocks rejected.
2. After consensus reached: replace MAX_BLOCK_SIZE with a size calculated based on starting at 2^24 bytes (~16.7MB) as of 1 Jan 2015 (block 336,861) and doubling every 6*24*365*2 blocks -- about 40% year-on-year growth. Stopping after 10 doublings.
3. The perfect exponential function:
size = 2^24 * 2^((blocknumber-336,861)/(6*24*365*2))
... is approximated using 64-bit-integer math as follows:
Code:
double_epoch = 6*24*365*2 = 105120
(doublings, remainder) = divmod(blocknumber-336861, double_epoch)
if doublings >= 10 : (doublings, remainder) = (10, 0)
interpolate = floor ((2^24 << doublings) * remainder / double_epoch)
max_block_size = (2^24 << doublings) + interpolate
This is a piecewise linear interpolation between doublings, with maximum allowed size increasing a little bit every block.
Instead of sudden and massive block size limit increases every two or four years, it would increase a little every block.
February 05, 2015, 01:12:10 AM
Great post.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
I like the simplicity of this strategy and it has grounding in practical limitations for physical hardware.
Although I would suggest to have it at the midway points between halvings so as to smooth out any lumpiness in the response to fees/reward when changing the halving and max_block_size increase together. Analogous to presidential and mid-term election cycles.
So quadruple max_block_size at 315k, 525k, 735k, 945k, thereafter every 210k blocks. But need to begin with a one-off quadruple increase to 4 MByte ASAP (to account for previous increase that would have ideally happened at 315k).
Edit: on further thought maybe doubling every 105k blocks is less disruptive again, instead of banging the limit every so often. So a one-off quadruple to 4 MB ASAP then double to 8 MB at next halving (420k blocks) and double every 105k blocks thereafter, i.e. double approx. every 2 years, more or less, depending on hashrate, which is a rough proxy for network demand via price.
yeah, sounds good.
the actual numbers and frequency could be tweaked, but the idea seems good.
This prevents us from having to hardfork it every time.
February 04, 2015, 11:53:03 PM
Great post.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
I like the simplicity of this strategy and it has grounding in practical limitations for physical hardware.
Although I would suggest to have it at the midway points between halvings so as to smooth out any lumpiness in the response to fees/reward when changing the halving and max_block_size increase together. Analogous to presidential and mid-term election cycles.
So quadruple max_block_size at 315k, 525k, 735k, 945k, thereafter every 210k blocks. But need to begin with a one-off quadruple increase to 4 MByte ASAP (to account for previous increase that would have ideally happened at 315k).
Edit: on further thought maybe doubling every 105k blocks is less disruptive again, instead of banging the limit every so often. So a one-off quadruple to 4 MB ASAP then double to 8 MB at next halving (420k blocks) and double every 105k blocks thereafter, i.e. double approx. every 2 years, more or less, depending on hashrate, which is a rough proxy for network demand via price.
February 04, 2015, 11:23:44 PM
Did you cry as much about the upgrade from 32bit to 64bit operating systems?
Or from 1.44 MB floppy disks to 200 MB CDs?
Or from 1.44 MB floppy disks to 200 MB CDs?
I'm still using floppies, I don't know why anyone would think they are obsolete.
But I still need to upgrade my operating system, so I think this will be a long night.
That is not true, Windows 8.1 is not officially offered on the medium of floppy discs. Those discs are not genuine.
the sad thing is, you're probably not even the most stupid person i have met on these forums.
February 04, 2015, 11:21:39 PM
Thank you for expressing what many of us knows intuitively, but lack the technical articulation to bring the argument to full fidelity. Wonderful stuff.
February 04, 2015, 11:16:57 PM
Great post.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years. This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.
February 04, 2015, 10:59:06 PM
Great post D&T. As a miner raising the block limit is the next best thing that can happen after a moonish exchange rate.
February 04, 2015, 10:51:12 PM
That is not true, Windows 8.1 is not officially offered on the medium of floppy discs. Those discs are not genuine.
Are you telling me I just got scammed?
February 04, 2015, 10:50:07 PM
That is not true, Windows 8.1 is not officially offered on the medium of floppy discs. Those discs are not genuine.
You must be the toast of every party. 
February 04, 2015, 10:45:40 PM
Very good post, hopefully this will help some of the confused out there!
February 04, 2015, 10:48:36 PM
Did you cry as much about the upgrade from 32bit to 64bit operating systems?
Or from 1.44 MB floppy disks to 200 MB CDs?
Or from 1.44 MB floppy disks to 200 MB CDs?
I'm still using floppies, I don't know why anyone would think they are obsolete.
But I still need to upgrade my operating system, so I think this will be a long night.
That is not true, Windows 8.1 is not officially offered on the medium of floppy discs. Those discs are not genuine.
February 04, 2015, 10:45:24 PM
Thanks for this. Bitcoin needs to scale and increasing the block size limit should part of that roadmap.
February 04, 2015, 10:36:50 PM
Did you cry as much about the upgrade from 32bit to 64bit operating systems?
Or from 1.44 MB floppy disks to 200 MB CDs?
Or from 1.44 MB floppy disks to 200 MB CDs?
I'm still using floppies, I don't know why anyone would think they are obsolete.
But I still need to upgrade my operating system, so I think this will be a long night.
February 04, 2015, 10:21:11 PM
There needs to be a consideration of chilling effects, or otherwise, upon ancillary technological development that is directed towards the current rules, when even merely discussing changing the rules.
Jump to: