Topic: Coalition For 8MB - page 2. (Read 3163 times)

That might be another good candidate, especially if it comes from a respected member, like Adam Back.

The perception I got recently that people were rushing to choose between two extremes (XT-exponent and Core-1MB-forever), that's why I thought there must be a better way. This 8MB initiative, therefore, may refer to any reasonable approach that caps at 8MB for the next several years.

But there is one important thing.

If we don't have a trusted client at hand that represents a balanced approach, then when the next stress-test comes and people feel uneasy transacting, they might head for the only other eXTreme that exists out there, which eventually may as well become their (e)X(i)T from the ecosystem.

We mustn't underestimate the gravity and the inertia of the processes at hand.
Hence this thread.

I like Adam Back's 2-4-8 proposal better, as it provides a gradual transition. Note that Bitfury's support for BIP 100 was based on their assessment that increasing the limit to 8MB right now is too fast. Mark Friedenbach has also warned that while 8MB is likely safe with current networking hardware, it hasn't been sufficiently tested.

I wouldn't mind accelerating Adam's schedule so that 8MB is reached in 3 years, not 6.

When the road ahead is unclear, that's the best we can do.


Thanks! I'll look into that.

So kick the can down the road, but a little farther than the other proposal like it.

Just write up a BIP and ask people to contribute code for it.

After lurking enough on these forums and reading recent arguments,
I figured that raising the limit to 8MB is a our best chance at reaching consensus.

Pros:
1) Easy to implement in the situation when most of the developers disagree. Good for SW decentralization.
2) Static limit will stay the same over time while technology continues to improve. Reduces the risk of network instability.
3) Good for robustness of the system as the limit is known at any given moment and can be easily verified. Less obscurity.
4) Big enough to not let the competition gain momentum, but safe enough to not let the network fall apart.
5) What seems like big blocks today will become small blocks in the future. Should satisfy both camps.

Cons:
1) Will have to be adjusted down the road. However, a good precedent now will make it much easier than the first time.
2) Big blocks are currently untested. However, an occasional big block will likely get orphaned for any foreseeable future.

This thread is for those who are interested in contributing to the creation of the client,
which will have the new limit built in together with the activation code that enables it after a certain block (somewhere around year's end).

In the situation when development team is split into supporting two radical approaches neither of which represents the idea of original Bitcoin,
we need to form a small contingency group to help Bitcoin get through this uncertainty with the most simple and robust solution.

We need a few members in good standing who can built the software, cross check it and share it with the community.
The best coders that join this initiative will begin shaping up what can be called a Future Crew of Bitcoin.

I personally have never built the client, but will be interested in setting up the environment and doing it myself in the upcoming days and weeks.
However, me alone doing it will not solve the problem as it would require trust from the community, so we need some members with reputation here.

Related topic in the main forum is here.
You are welcome!