[PATCH] increase block size limit

[jgarzik]

We should be able to at least match Paypal's average transaction rate...

Code:

diff --git a/main.h b/main.h
index c5a0127..c92592a 100644
--- a/main.h
+++ b/main.h
@@ -14,7 +14,10 @@ class CBlockIndex;
 class CWalletTx;
 class CKeyItem;
 
-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+	TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;
 static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
 static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
 static const int64 COIN = 100000000;

URL: http://yyz.us/bitcoin/patch.bitcoin-block-sz-limit

[1715211956]

1715211956

[1715211956]

1715211956

[theymos]

Applying this patch will make you incompatible with other Bitcoin clients.

[satoshi]

Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.

[jgarzik]

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

[FreeMoney]

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

[jgarzik]

We can phase in a change later if we get closer to needing it.

IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.

Satoshi just said it can be changed, so technically the network is capable.

It is also an incompatible change, as you see.....

[martin]

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

[jgarzik]

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

[satoshi]

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

[kiba]

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.

[appamatto]

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.

You just described a whole-network upgrade.  I'd call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.

I agree, especially since generators are both the source of blocks and "votes" in the network.  Since a block restriction would allow generators to charge higher transaction fees, they might "vote" against an increase in the max size in the future.

It seems unlikely to be a real problem though.

[caveden]

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

[ArticMine]

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.

My question is this: What will happen first?
1) Bitcoin transaction volume increases by a factor of 4
2) Current Bitcoin clients become obsolete.

[markm]

Hmm Satoshi wrote that over two years ago and we still aren't actually close to needing it yet.

Still I guess it mostly depends on how many more years it is going to be before someone actually goes out there and signs up Walmart or President's Choice or A&P (are they still around?) or Sainsbury's or something and actually shows us a little of this vast flood of users they keep yelling is going to descend upon us any moment now.

So far it seems possible the volume of ranting about vast numbers of users coming at us is actually inversely proportional to the number of users the ranter actually has signed up lined up ready to bring aboard.

-MarkM-

[ArticMine]

http://blockchain.info/charts/n-transactions With a 10x increase in the number of transactions over the last year it is reasonable to say that we can reach the 1MB limit in well under a year. The point is that in order to roll out a hard fork one has to delay its implementation way into the future in order to avoid chaos in the network. It we reach the limit before anything is done it will be way too late and a massive loss in confidence will result.

[BitcoinINV]

off-topic and I am sorry but I could not help myself. Why did satoshi ever stop posting visiting us?

[ArticMine]

off-topic and I am sorry but I could not help myself. Why did satoshi ever stop posting visiting us?

There are many theories of this. One of them is can Bitcoin continue to function without centralized control? By leaving us he in effect left Bitcoin leaderless and that is by design. This block size issue is likely to be the perfect test since the community has no choice but to implement a hard fork. If Bitcoin survives this it will come out way stronger, there is however also a significant chance that block size issue will turn Bitcoin into a failed experiment.  By the way I would not consider your post off topic at all.  

[markm]

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

[Technomage]

http://blockchain.info/charts/n-transactions With a 10x increase in the number of transactions over the last year it is reasonable to say that we can reach the 1MB limit in well under a year. The point is that in order to roll out a hard fork one has to delay its implementation way into the future in order to avoid chaos in the network. It we reach the limit before anything is done it will be way too late and a massive loss in confidence will result.

Exactly. We're not having these discussions too early at all, on the contrary. We will probably need 1 year of lead time for such a massive change, and indeed it is possible that we will be pushing the limit within 1 year. So this is no joke.

[BitcoinINV]

Here soon blockchain.info is going to roll soo fast you can not even see the transactions.

[ArticMine]

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

Satoshi Dice is currently paying 0.001 BTC in fees per transaction which translates into 0.03 USD per transaction. I would not call this "dust spam". What we have here is exponential growth pushing against a hard limit. This is a prescription for disaster. Arguing whether the disaster happens in four months or sixteen months is beside the point.

[jgarzik]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

[Technomage]

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

[markm]

Okay how about making max block size a configuration file / commandline variable?

From then on, no hard fork of the code would be required to change it, only, potentially, a hard fork of the blockchain?

Shops can have signs on their doors warning customers about the actual setting that shop uses for max block size, and customers can choose higher size supporting shops if they feel confident risking their money in blockchain branches they think might end up with less hashing power behind them than forks adopting a more traditional / more conservative limit?

Customers would maybe prefer merchants whose limit is set so high only a few miners world wide can handle it thus that have lower hash power, plus their coins will still be safe back on the original size branch because no higher size block can ever move any original sized block chain's coins anywhere at all.

Merchants wanting to actually be able to receive real original coins on the real original chain will set their clients to not approve blocks larger than those of the original chain, the chain which established the damn things have any value at all in the first place.

Maybe we should make two forks right away, a double sized block and a half sized blocks chain, and see which chain's coins best retain or gain value?

The config file setting method of setting the max will at least get rid of all the "we have to fork the code" excuses / arguments, reducing it to each node's choice what value to put in its config file. Thus putting the power with the nodes, not with the developers. (Which might be a really really really crappy idea. "Eat shit! Half a million houseflies can't be wrong!")

-MarkM-

[nikkisnowe]

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

[misterbigg]

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

They aren't ridiculous or indecipherable at all. In fact they are a very polite way of mocking many of the clueless opinions from non-technical folks.

[Peter Todd]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

Speaking of, you made a "dust-spam non-standard" patch right? Where is it?

[dacoinminster]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

A tiny fraction of a bitcoin might represent an ounce of gold (for instance), and so it should NOT be assumed useless or disallowed by the protocol!

I think prioritizing transactions by fees is better than trying to rule out transactions which don't have an immediately obvious purpose.

[Peter Todd]

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

Sane "colored coin" or "smartcoin" protocols don't depend on some fixed "1 satoshi = 1 share" ratio. Rather for each transaction moving an asset around they calculate what fraction of the asset was assigned to what transaction output, which means you can divide the asset indefinitely without requiring the actual amount of Bitcoins to change. If the asset represented by a txout is worth less than the minimum transaction fee, it's still dust that doesn't make sense to spend.

It's unfortunate that the first smartcoin-type protocols weren't written that way; on the other hand none of them have actually been used in practice. I've written a protocol that does this correctly as apart of my fidelity bonds protocol, see here although I haven't written code to implement it yet.

[mp420]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees. If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

[markm]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees.

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.

If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

[ArticMine]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees.

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.

If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

How does this address a critical part of Satoshi's post namely that this be implemented "... in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete"?

[Technomage]

I just checked. We're currently at 0.7 transactions per second. If it can scale to 7 transactions per second, well, we still have a long way to go before we even start to have truly crowded blocks.

As important as this issue will eventually be, it's not worth it to get too heated about it at this point. Even when the blocks start getting crowded it's not an immediate issue, fees will simply go up a bit which is not a big deal since the transactions are currently almost free.

[markm]

How does this address a critical part of Satoshi's post namely that this be implemented "... in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete"?

We immediately put in a block number at which max block size will be read from the config file instead of being hard-coded into the code.

Then sit back and yack until what actual number to put in that spot in the config file becomes clear.

-MarkM-

[iCEBREAKER]

It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.

I don't see the urgency, so it's more like a snooze button than a wakeup call.

[ArticMine]

I just checked. We're currently at 0.7 transactions per second. If it can scale to 7 transactions per second, well, we still have a long way to go before we even start to have truly crowded blocks.

As important as this issue will eventually be, it's not worth it to get too heated about it at this point. Even when the blocks start getting crowded it's not an immediate issue, fees will simply go up a bit which is not a big deal since the transactions are currently almost free.

Based on the 10x growth of the number of Bitcoin transactions over the last year that places the issue under a year away. The problem is that it can take a year to do a hard fork properly.

[Technomage]

True. I think that a plan must be figured out within the next 6 months if we don't want to rush the hard fork when it's time. And hard fork is such a thing that we don't want to rush it.

It's not that bad though. They can simply put rules in place for the nodes so that the fork only happens when a sufficient number (maybe 90%) has upgraded. Then it's up to the users how fast the hard fork happens. It can happen quickly if the fees become a problem, simply spread the word.

[ArticMine]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

[johnyj]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

About half maybe

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124682

[ArticMine]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

About half maybe

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124682

Thanks. CVE-2012-4682 is dated 14-Sep-2012.  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4682. That is less than six months ago. This means that six months is the barest of minimums if at all. A much more reasonable time frame is 12-18 months or even longer.

[Technomage]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

[theymos]

When Satoshi introduced the backward-incompatible checksum change, he set it to activate after two years. That seems like a reasonable amount of time.

[caveden]

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

A tiny fraction of a bitcoin might represent an ounce of gold (for instance), and so it should NOT be assumed useless or disallowed by the protocol!

I think prioritizing transactions by fees is better than trying to rule out transactions which don't have an immediately obvious purpose.

Of course they shouldn't be "disallowed", but regardless of what they represent elsewhere, these dust transactions may be a "nuisance" to Bitcoin if they are not majorly composed of fees.

I don't understand why using Bitcoin for this inherently centralized use cases (like asset issuing), when there are better suited protocols like Open Transactions, for instance.

[Akka]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

Could it not be simply introduced, that miners with the patch "mark" their blocks somehow and as soon as say at least 80% of all blocks are "marked" a countdown activates (maybe 20,000 Blocks) to give the remaining 20% some time.

[poly]

The current upgrading tendencies are not really an accurate prediction of how it will be with the fork. The fork, when and if it's decided, is a super high profile thing. It would also likely be something that's already felt by the users (higher fees perhaps?), so they would most likely upgrade significantly faster than with regular patches. That being said, they would likely not upgrade super fast regardless, so months are needed at least.

Could it not be simply introduced, that miners with the patch "mark" their blocks somehow and as soon as say at least 80% of all blocks are "marked" a countdown activates (maybe 20,000 Blocks) to give the remaining 20% some time.

That is pretty much what is happening already with block versions now.

There's block version 1 and block version 2. When 950 of the last 1,000 blocks are version 2 or greater, all version 1 blocks will be rejected by those who updated, and will therefore be orphaned.

[solex]

Which is why I started this thread, but have had no useful feedback:

https://bitcointalk.org/index.php?topic=145224.0

[Syke]

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

[Rogue Star]

S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.

what you are really saying here is:

S.Dice are transactions. Increasing the block size to support transactions is absolutely the wrong idea. Bitcoin cannot be built around transactions.

Most people around here are thinking about transactions incorrectly. I'm going to single out Jeff in passing because he is a core-dev that has only gone from one extreme to another. Bitcoin is not built to support micro-transactions and this is evident from the way transactions must propagate and all the economic incentives that support the auditing of transactions. What is not evident is what a "micro" transaction really is in the context of Bitcoin.

I think fundamentally a micro transaction in Bitcoin is a transaction or perhaps a tx out that is not worth propagating or auditing. Technically it is very hard to argue S.Dice is a micro transaction otherwise it would be impossible to propagate or audit. Economically it is not so clear cut, but there is a market for auditing S.Dice transactions, so I would say economically it is not a micro transaction. You can say that S.Dice is subsidized by the block reward, but take the reward away and it almost the only incentive to audit other transactions. Thus, S. Dice will not truly be a micro transaction in the context of Bitcoin until it is impossible to transact on the Bitcoin network. When that will happen will be determined entirely on network management.

Bitcoin never promises to support micro transactions as I've outlined it nor is it built for that. Bitcoin is a payment network. From a network management point of view S.Dice is a problem because of the spammy messaging, but otherwise the transactions are just as valid as any other on the network.

My network management suggestion to S.Dice would be to include the messaging component as part of the bet so the messaging output would be limited to the size of the minimum bet, which should follow whatever the network can support. Integrations with wallets such as blockchain.info could just hide the messaging component of the bet to make it user friendly, done correctly it could even be used to collect any dust it has already created. Perhaps it is also worth considering not using a messaging component for most S.Dice bets as it has already established a reputation and messaging could be implemented as an optional value-added service rather than a default operating mode.

[ArticMine]

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time. 

[solex]

Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;all

Edit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time.  

Yep, and I would really like to see Jeff Garzik explain what his solution is now since he has had 4.5 YEARS to consider it further.

A solution other than do nothing, lets crash into the limit (which he never liked in the first place), and see what happens.

More like this maybe:

We should be able to at least match Paypal's average transaction rate...

Code:

-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+	TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;

[samson]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

[HCLivess]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

hard fork

[_biO_]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

The problem is that you can't react to a large increase immediately, you need at least 6-12 months lead time or you risk a fork. Also, the default blocksize soft-limit is actually 750k, which most miners adhere to. So were are at ~66% of the preconfigured capacity, on average. If usage increases, as it historically does during winter, we might have serious capacity problems next year, and we maybe even see the signs this year. Especially during peak times we might see an substantial increase in confirmation times that may drive users away from bitcoin.

[bitcreditscc]

Fanboys spouting shit should read this thread. The change to larger blocks has been in the works for a long time so buck up and lets do this.

[Morecoin Freeman]

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

[Pecunia non olet]

I have read through this thread (good read!) and I have a question:
Do all of the bitcoin core developers agree on increasing the block size limit?
And if not, what are their arguments against the increase?

That can be read on various places. Please search the web before asking questions that have been answered 100 times already.

[Morecoin Freeman]

Ah excuse me, I guess you are right. I did read something about it just now.
In case someone else has the same question, what I found:

That it could lead to centralization within the mining community, which would favor bigger and richer mining operations.
And that there are too many unknowns about the consequences of increasing the block size to 20 megabytes.

[bitcreditscc]

That is all moot. Just think, your phone can get a 128GB memory card. Your HDD can be up to 4 TB right now. Where does it seem like the average user cannot keep up?

just because we say teh max block size is 20 MB does not mean we will immediatley fill them. likely the'll remain around the same size for a bit longer before they regularly pass the 1 Mb size, they likely wont touch 2 Mb average for another two years.

In terms of storage within a year 10 TB, 20 TB and 50 TB hard drives will be commercially available, so i see no reason to hold back progress over baseless fears.

[bitcreditscc]

People have no problem downloading GTAV or MKX yet they cant spare 50Gb for their money. Let's be serious people.

[Morecoin Freeman]

I am somewhat uneducated on the matter, but I would also opt for the change in block size limit.

[unamis76]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

So just because blocks will not jump overnight makes it not important to think about changing block size?

[samson]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

So just because blocks will not jump overnight makes it not important to think about changing block size?

No, you misread my post.

[slaveforanunnak1]

I wonder if Satoshi ever talk about payment-channels ?

[ammy009]

this patch is included in XT bitcoin wallet ... I guess

[coins101]

I've been sitting on the fence a bit trying to figure out what's what.

Having deployed a payment service intended for mass use inside one of the top 3 global retailers, you do need to plan ahead for optimistic outcomes and always keep the end users experience with your product in your sights.

I have come to the conclusion that while you don't need to update now, or possibly not for another year, the sooner you do it the less of an impact it will be for new adopters.

What is being discussed here is that we should wait until Bitcoin becomes more popular before making a hard fork. That's precisely the wrong time to do it.

Do it in anticipation of more transactions so that people coming to Bitcoin won't be reading news stories about a major upgrade that might cause problems.

We also have to consider that nearly $1bn in VC money is going in to development. That investment will soon see new services pouring out and those firms will all have promotional money. The last thing they would want is to start a promotional push, and then face the same situation of having to tell their users that a major update is needed and the update carries some risks.

I think that a hard fork should be made in line with BIP100. The hard fork should carry 1mb blocks as a starting point, but with some dynamic scaling options using just in time delivery to enable soft forking for increasing blocks sizes when capacity increases are required.

This should be part of a series of moves that seeks to take Bitcoin out of Beta.  Removing the limit means that the protocol can scale to Visa levels and beyond.

The introduction of Sidechains and Lightning networks means that capacity can be co-managed with micro-payment and off chain channels doing some of the heavy lifting. A dynamic model allows for these systems to work alongside Bitcoin block size planning.

Bitcoin is no longer a proof of concept project. The concept has been proven. Bitcoin Core 0.11 should be the last beta release cycle. Sidechains and Lightning type networks should be dovetailed to work with an eventual Bitcoin Core 1.0 production ready release.

edit

https://bitcoin.org/en/alert/2015-07-04-spv-mining

[puck2]

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

Prescient