Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability

[tvbcof]

Organizations who are serious in what they do do what are called 'war games' to facilitate effective development.  The excersizes are as realistic as resources allow.  Done correctly, the 'opfor' (opposing forces) team has every method at their disposal that a real opponent might have.

In Bitcoinland this would (or should) take the form of a testnet where opfor has gear installed which can do deep packet analysis, filtering, and packet manipulation.  To be fair, traffic analysis of transit should dictate what types of traffic operations are allowed.  So, say, if real-world traffic is routed through a carrier who could conceivably be subject to legal mandates to perform certain operations, the opfor team would be allowed to employ the same.

As best I can tell there is no ability or desire to include this level of rigor in the development of Bitcoin.  As a holder I must factor this into the confidence I have in the solution.

[Gavin Andresen]

As best I can tell there is no ability or desire to include this level of rigor in the development of Bitcoin.  As a holder I must factor this into the confidence I have in the solution.

You don't seem to have the "jump in and help" mentality needed to participate in a radically open project like Bitcoin.

As I have said repeatedly in the past: you don't have to ask anybody for permission or advice. You are part of the process-- make it happen.

Personally, I don't know nuthin about "opfor teams" ...  (but am the creator of the Bitcoin testnet, so am offended by you saying there is no ability or desire to bring more testing rigor to Bitcoin).

[iluvpie60]

It seems Bitcoin community can't reach consensus on this issue, a lot of people against the proposal.

There seem to be a few people who want some OTHER algorithm for increasing the block size, but I'm hearing very broad consensus that we do need a hard fork to increase the size.

That is progress.

I'll be running some experiments using actual blockchain data to see where the current code breaks; if it can already handle 20MB blocks then I'll work through the details to propose a hard fork (write BIPs, write code, write tests, ...).

Thank you Gavin for responding to this topic!


Your logic on this is very sensible. I feel like anyone who is "going against" a hard fork is right to question it if questioning it intelligently, and it is nice to see your response to those questions. It can be very frustrating to see some of the local clowns chiming in and we agree they can be offensive.



Everyone,

I am not sure of most people's backgrounds here on this forum, but software can almost always be improved upon and is necessary to sometimes change. Any fellow coders here could think about a time they made a program or coded a module, then later learned a different way of going about it that makes it run faster or has less code to complete the same function, or added functionality is coded to deal with other factors or upgrades. They can also think about if something is needed in the business world or a new demand arises how something will fill that demand, once the Iphone was out did they keep making the exact same Iphone or was it constantly changed as time went on? Do companies who always do the same thing always stay in business? Look at the auto industry and how hard they were going to crash unless the government stepped in for some of them. Why did the government step in and give them bail out money? Because they didn't change with the times, they were still making gas guzzling trucks and SUVs while foreign companies were bringing over more fuel efficient smaller cars. Eventually after the bail out they started to change and get their act together.


TL:DR
Do we all want to wait until bitcoin needs a "bail out" before something gets changed in the code? Or do we analyze potential future problems and correct them before something bad happens?


Thanks

[BitUsher]

Good discussion about network scalability concerns :

https://www.youtube.com/watch?v=FEliXGr5Bl8

Peter Todd does have some valid concerns, although I believe he exaggerates a bit by suggesting 10x more transactions might require 10x more centralization, but I also like how he correctly points out that raising the block limit is the easy solution and we need to ultimately create other solutions(Like the lightning network) for Bitcoin to remain sufficiently decentralized.

This being said, I think a 20MB bump while other solutions are tested may be a fine adjustment as long as we don't simply adapt the habit of constantly increasing the block size limit.