Foxpup
Legendary
Offline
Activity: 4466
Merit: 3122
Vile Vixen and Miss Bitcointalk 2021-2023
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 01:16:40 AM |
|
Increase the max block size isn't going to do much if most miners aren't already using that max. A significant portion of the blocks created today are 250KB or less in size.
Increasing the max block size especially isn't going to do much if most miners don't upgrade. Bitcoin 0.9 no longer produces such blocks (I think).
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 02:03:27 AM |
|
Increase the max block size isn't going to do much if most miners aren't already using that max. A significant portion of the blocks created today are 250KB or less in size.
Increasing the max block size especially isn't going to do much if most miners don't upgrade. Bitcoin 0.9 no longer produces such blocks (I think). I think you are misunderstanding, the cap has been 1MB for a long time now. Most blocks are less than 250KB. So raising the cap isn't going to make those blocks larger. For one reason or another miners are producing smaller blocks. Now if the block size was consistently close to 1MB and paying tx were having to wait multiple blocks then yes raising the cap is going to help but we aren't there yet. If miner X is choosing to produce a block that is 87KB why would raising the cap from 1MB to 20MB change anything?
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4466
Merit: 3122
Vile Vixen and Miss Bitcointalk 2021-2023
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 02:20:06 AM |
|
Most blocks are less than 250KB. So raising the cap isn't going to make those blocks larger. For one reason or another miners are producing smaller blocks. Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour).
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 02:31:50 AM |
|
Most blocks are less than 250KB. So raising the cap isn't going to make those blocks larger. For one reason or another miners are producing smaller blocks. Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour). or set a single config parameter "blockmaxsize" to 250KB. No modification of the client is required. The double fee requirement was for blocks over 500KB. v0.8.6 set the default max block size to 350KB. v0.9.0 set the default max block size to 700KB. It is very likely major miners are setting the "blockmaxsize" and other mining parameters.
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4466
Merit: 3122
Vile Vixen and Miss Bitcointalk 2021-2023
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 04:06:45 AM |
|
The double fee requirement was for blocks over 500KB.
Source? In every version I've seen until 0.9, it's always been 250kB. It was never 500kB as far as I know.
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 07:27:20 AM |
|
Is there a possibility that a minimum block size could be implemented? Would this help the issue?
|
|
|
|
btcxyzzz
Legendary
Offline
Activity: 888
Merit: 1000
Monero - secure, private and untraceable currency.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 01:13:16 PM |
|
I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins...
|
|
|
|
nkocevar
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 04:04:36 PM |
|
Fortunately, there is always Dogecoin to transact micro payments.
But you have to think about the tediousness of constantly switching back and forth from DOGE to BTC whenever you want to make a micro transaction. Although you could always just keep a small amount of doge.
|
|
|
|
devphp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 04:17:08 PM |
|
Fortunately, there is always Dogecoin to transact micro payments.
But you have to think about the tediousness of constantly switching back and forth from DOGE to BTC whenever you want to make a micro transaction. Although you could always just keep a small amount of doge. Yeah, just keep small amount of Dogecoin, like you keep small change in your physical wallet to buy a coffee for example.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 04:22:29 PM |
|
I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins... It hasn't fallen. On a day to day basis there is a lot of volatility in the number of transactions. Volume also tends to spike when the price makes major moves (highest volume days tend to be around ATHs and ATLs). If you look at transaction volume on a moving average it has steadily increased.
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 05:00:46 PM Last edit: May 19, 2014, 11:54:33 PM by Peter R |
|
I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins... It's not falling. It's rising. The number of transactions per block is what affects how full the blocks are, not the total output volume. The number of transactions per day has been steadily increasing: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FOypDNTl.png&t=665&c=gSf_BuNWwJ_d4g) The above chart is distorted by the "on-chain" gambling bubble of mid 2012 to mid 2013. Most gambling now takes place off-chain (in fact, just-dice.com processes over 100 bets per second). If we attempt to remove the "on-chain gambling" bubble to get a better sense of organic growth in the number of transactions per day in the bitcoin economy, we finds its been growing exponentially at approximately 320% per year. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F1MHBBDw.png&t=665&c=5xltWhwfSCxEYA)
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 05:15:46 PM |
|
Most blocks are less than 250KB. So raising the cap isn't going to make those blocks larger. For one reason or another miners are producing smaller blocks. Specifically, the reason is that Bitcoin versions prior to 0.9 do not produce blocks larger than 250kB unless there are transactions paying more than double the minimum required fee (which is almost never the case). Some pools (notably Eligius) removed this restriction, but most kept the default policy. Miners using Bitcoin 0.9 should only be producing small blocks if there are absolutely no more fee-paying transactions in the memory pool (unless they've modified their clients to restore the old behaviour). This would increase the aggregate cost of orphans. Orphan costs are reduced when blocksize variance is minimized. To keep blocksize variance low, a pool of unconfirmed transactions larger than the average blocksize is required. If miners were completely cooperative, to minimize the tragedy-of-the-commons effect they would agree on informal best practices for filling up blocks (not enforced). This will probably never happen, but the fact that there is almost always a pool of unconfirmed transactions while most blocks aren't even close to full shows that miners are cooperating to a certain extent for the benefit of the network.
|
|
|
|
tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1081
I may write code in exchange for bitcoins.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 19, 2014, 11:31:27 PM |
|
Is there a possibility that a minimum block size could be implemented? Would this help the issue?
Death and Taxes, if I understand the discussion correctly, implementing minimum block size seems like it would be the solution. The issue would be that if you hit a period in which there were very few transactions waiting to be confirmed then perhaps they would have to wait till more transactions arrived in order to meet the minimum. However, that shouldn't ever be a problem given the graphs and predictions you're showing us about the volume of transactions. Also, perhaps this transaction minimum would be implemented as a percentage of transactions waiting to be confirmed. This would obviously mess with difficulty, but that can be adjusted, right? Can we have a little discussion about the possibility of a min_block_size parameter?
|
|
|
|
|