Topic: [PATCH] increase block size limit (Read 89869 times)

Prescient 

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

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

I wonder if Satoshi ever talk about payment-channels ?

No, you misread my post.

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

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

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

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.

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.

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

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?

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.

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.

hard fork

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.

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:

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. 

what you are really saying here is:

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.

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.