Topic: Gold collapsing. Bitcoin UP. - page 1046. (Read 2032266 times)
Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse?
ironical the commodity in short supply that we are talking about preserving is space and bandwidth, charging transaction fees to reword miners does nothing to curb the miners from taking advantage of the limited space.
now if miners had to buy a claim to mine from a full node then fees would reflect the available bandwidth and space on the web.
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.
Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.
Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.
Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse? I guess this could make bitcoin unfriendly to microtransactions (one of it's finer points) and maybe easy to get around by scripting different origination addresses for each transaction if it were some kind of per-address limitation. Hmmm.
But let me better understand the current situation; Miners are already excluding transactions that are not worth their while? I assume they are doing this on the basis of fees paid? If this is the case, it would seem that removing the limit wouldn't change anything.... right? I mean, spammy transactions can already be assigned low priority and pushed into other blocks, so wouldn't that mitigate the problem all on it's own? Or is the fear that this could be abused by one of these entities spamming high fee transactions to themselves, solving the block making it "free", and thus excluding legitimate transactions? If this were the case, I don't see how a block size limit is doing anything to prevent this....
Option c is really just option b. I think that what you have outlined is exactly right, miners DO decide what to include, and right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming. The fear is that by raising the limit, you raise the burden of maintaining a "full node", which reduces the number of full nodes and thus the reduces the number of participants enforcing the network rules, and the other consensus mechanisms. Removing the limit would make no difference to the miners really, they make their own rules.
Miners still get to decide which transactions that they want to include...
And some miners do stupid things. "BCPool" created 17,976 single-satoshi dust outputs from that "1Enjoy" address by mining a bunch of spam transactions in block #309657 and again in block #309740. Assuming each output takes up 50 bytes in the UTXO database, that's 17,976 x 50 B = ~1 MB of garbage that will possibly forever sit in each node's RAM, as ouputs are not prunable if they never get spent (and these ones cost more to spend than they are worth!).
I'm not saying the limit shouldn't be raised, I'm just trying to present some empirical data that illustrates some things that have gone wrong.
Code:
BLOCK #309740: 10,486 DUST OUTPUTS
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749
BLOCK #309657: 7,490 DUST OUTPUTS
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749
BLOCK #309657: 7,490 DUST OUTPUTS
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.
Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.
Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.
Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse? I guess this could make bitcoin unfriendly to microtransactions (one of it's finer points) and maybe easy to get around by scripting different origination addresses for each transaction if it were some kind of per-address limitation. Hmmm.
But let me better understand the current situation; Miners are already excluding transactions that are not worth their while? I assume they are doing this on the basis of fees paid? If this is the case, it would seem that removing the limit wouldn't change anything.... right? I mean, spammy transactions can already be assigned low priority and pushed into other blocks, so wouldn't that mitigate the problem all on it's own? Or is the fear that this could be abused by one of these entities spamming high fee transactions to themselves, solving the block making it "free", and thus excluding legitimate transactions? If this were the case, I don't see how a block size limit is doing anything to prevent this....
The crunch increased interest in tenders divorced from a single nation’s strength, spurring the International Monetary Fund to boost almost 10-fold the allocation of special drawing rights, a reserve asset whose value is based on a basket of currencies, and fueling demand for so-called virtual currencies, such as bitcoin.
http://www.bloomberg.com/news/2014-08-06/russia-sanctions-accelerate-risk-to-dollar-dominance.html
http://www.bloomberg.com/news/2014-08-06/russia-sanctions-accelerate-risk-to-dollar-dominance.html
WTF, am I reading that correctly - in the context of the other posts, banks pay more than double the bitcoin market cap in fines, but IMF's SDR is involved how?
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.
Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.
Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.
I've always found your posts insightful and I know that you are a very intelligent person; I'm interested in your rationale for keeping the blocksize static.
The argument that "if the blocksize doesn't really matter, then why was a limit added?" seems valid to me. A smaller blocksize also limits growth of the UTXO database, which is actually the more critical resource. I'd like to see a healthy fee market develop along with a push towards off-chain transactions (perhaps using m-of-n Oracle sidechains). A smaller blocksize would incentivize that. That being said, Solex recently presented a helpful graphic that showed the increase in internet bandwidth since bitcoin's inception, indicating that 3MB blocks now would represent the same % of typically-available BW as 1 MB blocks did in 2009. So the argument can be made that "we can safely increase the blocksize in parallel with internet speeds." The Metcalfe value chart also shows a strong correlation between TXs per day and market cap, so an empirically-based argument can be made that limiting bitcoin's TX bandwidth would also limit its value.
One point you made that I think is not valid is the notion that a 1 MB blocksize is a core part of the coin's definition (i.e., part of the "Satoshi Social Contract" in the same way the 21 M coin limit is). There's plenty of evidence that indicates the 1 MB limit was never intended to be permanent. Of course, this doesn't mean that it's necessarily a good idea to increase it without careful thought and debate either.
I think there should be a limit otherwise no-one will pay any meaningful fees ever and people will stop mining. The system will only work when there is a limited amount of space because if it is unlimited it is advantageous for miners to include transactions with any fee, even 1 Satoshi. If that happens Bitcoin will stop to function correctly as the block rewards decrease.
If you believe that markets don't work without externally-imposed production quotas, then you're in the wrong place. Stick to central bank-created currencies.I signed up for Bitcoin with a 21M unit cap and a 1MB block cap.
That's great. I signed up for a Bitcoin that originally had no explicit cap on the transaction rate.Rationing transaction throughput was never part of the economic model of Bitcoin, and turning a temporary anti-spam measure into some kind of permanent feature is a form of attack against the currency.
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.
If the limit is increased I'm going to seriously consider to reduce my investment in Bitcoin significantly. When the limit is changed once it will be changed in the future as well as this will create a precedent. It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.
When the limit is removed, I hope you do sell all your coins.In fact, why wait?
I signed up for Bitcoin with a 21M unit cap and a 1MB block cap. Any changes to that will force me to seriously reconsider my investment as the chances of Bitcoin going to zero will increase tremendously.
You are conflating two completely different things. Like debating whether cars should drive on both sides of the road, and also what the speed limit should be.
Importantly. The original version of Bitcoin had an implicit block limit which was effectively 32MB, and Satoshi did a temporary anti-spam hack, seemingly without consultation.
Now you think it is a core principle?
I think there should be a limit otherwise no-one will pay any meaningful fees ever and people will stop mining. The system will only work when there is a limited amount of space because if it is unlimited it is advantageous for miners to include transactions with any fee, even 1 Satoshi. If that happens Bitcoin will stop to function correctly as the block rewards decrease.
If you believe that markets don't work without externally-imposed production quotas, then you're in the wrong place. Stick to central bank-created currencies.I signed up for Bitcoin with a 21M unit cap and a 1MB block cap.
That's great. I signed up for a Bitcoin that originally had no explicit cap on the transaction rate.Rationing transaction throughput was never part of the economic model of Bitcoin, and turning a temporary anti-spam measure into some kind of permanent feature is a form of attack against the currency.
The loss of full nodes is due to a delay in the appearance of Bitcoin-native businesses. There's nothing wrong with the demands of running a full node being something that only power users/small businesses and up can handle.
I expect this to gradually become a middle class trapping too, along with running email+SIP from the same home server (after all, they're the section of society that are being squeezed furthest out of their previous position in the relative earnings ranks and also who are reacting with most concern to the state surveillance culture)
It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.
Wachtwoord, do you think the limit should be permanently set to 1 MB? Or just that it should remain "limited" in order to drive a healthy fee market?
I think there should be a limit otherwise no-one will pay any meaningful fees ever and people will stop mining. The system will only work when there is a limited amount of space because if it is unlimited it is advantageous for miners to include transactions with any fee, even 1 Satoshi. If that happens Bitcoin will stop to function correctly as the block rewards decrease.
Why the limit should be at 1 MB? Well the same reason the maximum amount should be at 21M Bitcoin. If it is ever increased it creates a precedent to do so again, and again and again, ad infinitum. I signed up for Bitcoin with a 21M unit cap and a 1MB block cap. Any changes to that will force me to seriously reconsider my investment as the chances of Bitcoin going to zero will increase tremendously.
If people want the limitation to be removed I hope it's published as an altcoin (Bitcoin2) and the initial distribution as proposed by you Peter will be used.
It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.
Wachtwoord, do you think the limit should be permanently set to 1 MB? Or just that it should remain "limited" in order to drive a healthy fee market?
Buying space in the Blockchain (through fees) only works if the amount of available space is limited. I hope we'll quickly run into the 1 MB limit and the limit is NOT increased, then we'll see transfer fees increase. Increasing the limit is the same as printing more fiat currency, the value of space in the Blockchain will tumble towards zero and therefore the fees will too undermining the long term viability of Bitcoin.
That's FUD and historical revisionism that Jeff Garzik started spreading, for reasons about which I can only speculate.If the limit is increased I'm going to seriously consider to reduce my investment in Bitcoin significantly. When the limit is changed once it will be changed in the future as well as this will create a precedent. It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.
When the limit is removed, I hope you do sell all your coins.In fact, why wait?
Cross-post because this is becoming more and more relevant to the gold vs btc story.
Here's the current chart (made today):
My prediction is that we don't deal with the blocksize limit until after we experience another growth spurt (assuming one happens). If the Metcalfe relationship holds, it will look like the bitcoin price "bounced" off the TX limit and a credible argument could be made at that time that growth has become hindered by bandwidth. I'm personally not worried at all about the blocksize, as I'm confident we will find very strong support to do the right thing if the need arises.
The primary argument to retain the 1MB limit is that smaller blocks helps ensure decentralization of Bitcoin. Lots of people rightly care about this.
That was never a very good argument.The 1 MB limit was originally an anti-spam measure, and since it was put in place the biggest proponents for keeping it there were altcoiners who wanted Bitcoin to stay crippled to leave room for them.
The loss of full nodes is due to a delay in the appearance of Bitcoin-native businesses. There's nothing wrong with the demands of running a full node being something that only power users/small businesses and up can handle.
Buying space in the Blockchain (through fees) only works if the amount of available space is limited. I hope we'll quickly run into the 1 MB limit and the limit is NOT increased, then we'll see transfer fees increase. Increasing the limit is the same as printing more fiat currency, the value of space in the Blockchain will tumble towards zero and therefore the fees will too undermining the long term viability of Bitcoin.
If the limit is increased I'm going to seriously consider to reduce my investment in Bitcoin significantly. When the limit is changed once it will be changed in the future as well as this will create a precedent. It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.
The primary argument to retain the 1MB limit is that smaller blocks helps ensure decentralization of Bitcoin. Lots of people rightly care about this.
That was never a very good argument.The 1 MB limit was originally an anti-spam measure, and since it was put in place the biggest proponents for keeping it there were altcoiners who wanted Bitcoin to stay crippled to leave room for them.
The loss of full nodes is due to a delay in the appearance of Bitcoin-native businesses. There's nothing wrong with the demands of running a full node being something that only power users/small businesses and up can handle.
movin up:
Cross-post because this is becoming more and more relevant to the gold vs btc story.
Who is proposing to leave the transaction cap alone (retain blocksize limit in 1MB), and why? (Where is the battle line? 
)
)The primary argument to retain the 1MB limit is that smaller blocks helps ensure decentralization of Bitcoin. Lots of people rightly care about this.
As the average block size has increased the number of full nodes has been steadily declining. Once decentralization is lost then it is unlikely to be recovered. So this is a one-way path when changes are made which put decentralization at risk. The number of full nodes is in flux as they keep coming and going. Maybe there are about 8,000 at any one time. Ideally, this should not drop too low. So, there is a trade-off between average block size and the number of full nodes. No one knows the whether there is a tipping point where a certain block size might suddenly cause a lot of nodes to disappear because of the volume of traffic. Consumer bandwidth is the key limiting factor.
The best way to keep blocks small is via fees, and the minimum fee was increased 1 year ago which got rid of a lot of the messaging spam which had tx volumes at >60k per day early in 2013. So fee increases have already allowed the block limit to remain longer than previously expected. The block limit has a use for its psychological effect of driving the fees market, competition for block space. The problem there is that the fees market may not work smoothly until the block reward is 6.25 or even 3.125 btc.
However, a fixed block limit is very dangerous because of the potential for ecosystem conditions to create a sudden volume spike into this bottleneck crippling transaction throughput, collapse the price and create a PR disaster which will hang like a cloud for years afterwards.
IMHO, at the very least the 1MB should increase in line with the global improvement in bandwidth speed, and should be about 3MB by now.
This can be done using block version numbers and a super-majority trigger, or the more primitive block height check. However, time is running out and it looks like the 1MB will be maxed out during Q2 2015.
Jump to: