Anti-fork guys: What is YOUR proposal?

[shulio]

I don't understand why people refuse to the fork,if it is something necessary

everybody refuse but nodoby purpose anything

It is not something necessary for now in some peoples mind, but they dont provide any solution for it, mostly people who are oppose it because they have a fork-o-phobia, forking btc will sometimes leave btc to be worthless and that is their main consent about this .

[fat buddah]

I wonder when these gavin-tards get it that Bitcoin is not broken and running fine. It is a rule of complex system to not change them when they are not broken. There is currently a consensus for 1MB blocks else the network would not be running.

The anti-20MB people have to prove nothing and also have to deliver nothing. All they have to do is tell the reasons for the veto and that's it. There is consensus for Bitcoin as is today else it would not be running. If you want to change it you need consensus. If you get a veto (which you did) then there is no consensus on a change and you need to accept that.

After getting a veto for your proposal you have two options:
1) producing a better proposal which will not get a veto
or
2) leave the group (bitcoin in this case)

that is how consensus principle works if you like it or not. There is even more sophisticated methods of approaching consensus but since you are all behaving like apes i'm not even trying.
It's not like consensus democracies would be something new or something. They are just not as commen and people generally have no idea about it.

[SuperClam]

I don't see much issue here
Satoshi released with 33MB, he said it could be increased later, and Gav seems on the ball.
HD space is still going down in cost.

Storage is not a major bottleneck.

Bandwidth and latency are legitimate concerns from my reading of the material; though the current proposed change doesn't saturate either, depending on your personal situation.

One of the issues-at-hand concerns adopting strategies that can easily become centralization forces now, or in the future.

It is not something necessary for now in some peoples mind...

Given a serious situation, the network has in the past proven it's ability to fork quite quickly.
Further, even given a backlog in the mempool, users who include reasonable transaction fees with their transaction would be more likely to have their transaction included into a block.  Meaning: The network would work fine.

It is a fact that storing and broadcasting your transactions on the chain is not "free". 
You are enjoying the resources of the network of full-nodes.

...but they dont provide any solution for it...

There are a variety of solutions that have been proposed, although there is admitted lack of implementations.  However, development resources would be more likely applied to a problem that was actually imminent.

...forking btc will sometimes leave btc to be worthless and that is their main consent about this .

Not true.
No Bitcoin will be "lost" -
With the exception of someone who receives an incoming transaction on the "losing" chain (that is not posted to the "winning" chain) and that output is then signed to a different address on the "winning" chain.

[Rampion]

My proposal: a slow, progressive and cautious approach. First we increase to 2MB, then to 4MB, then to 8MB and so forth. Doubling the block size seems the sensible approach - increase it in one single step by x20 seems overkill.

The reasons argued by those who defend a cautious and slow growth are solid; on the contrary, those argued by Hearn and his acolytes are reckless BS.

[fairglu]

Let's go back to the blunt technicalities: what happens if the block size does not grow?

• more memory usage (ever growing mempool)
• more network contention (unconfirmed tx keep getting flown around and resubmitted)
• more double spends (from resubmitted tx)
• growing minimal fees (pools trying to deal with the above, and treat any tx without enough fee as spam)

Why? because people with unconfirmed tx would just keep re-submitting and spam, as that's the most effective technique to get *your* transaction through in a congested traffic situation. Just like elbowing is the most effective technique to get through a crowd.

Yes, it would be selfish, but yes it would happen.

So let's face it: limiting block size will NOT reduce network contention or make nodes lighter. Only reduced bitcoin usage would.

Growing fees would achieve reduced bitcoin usage, though, but is that what you really want?

[neoneros]

Thought the increase might be big, how big of a change is it in the core itself? Does a lot depend on the variable that defines the size of the blocks? What is the biggest fear in this?

If you have a room with a lightbulb, and is has to low light for reading, you can change the bulb with a higher intensity so you can read again, no big deal. I cannot think of it that the increase would actually be a big issue for the source and implementation. I could be wrong, not that into the code of the proposed fork itself, but I think the impact and positive outcome are larger than the actual risks that the code would break and be to hasty implemented.

And what if it does fail? It will be tested and tried, then it will slowly be adopted into the chain, if it works we can embrace it, if it fails, we will find out soon enough and we can just all go back a version and learn from it and revise the plans.

[thejaytiesto]

I don't see much issue here

Satoshi released with 33MB, he said it could be increased later, and Gav seems on the ball.

HD space is still going down in cost.

2TB HDDs are so incredibly cheap these days. In 10 years imagine, 2TB will be like what 2GB is for us now, and we will probably have cheap large SSD disks by then too.

[NorrisK]

How about some form of lossless compression? Would that at all be possible in case of blockchain data? Would be interesting..

[Buttknuckle]

I'm anti fork an my proposal is to just fire Gavin and be happy thereafter.
And he should take his fanclub with him!

One of the fud mongers speaks.  DO you care to address the fact that the team opposing the fork has a conflict of interest?  Of course not you will just continue to spread fud.

[Fuserleer]

How about some form of lossless compression? Would that at all be possible in case of blockchain data? Would be interesting..

Block data is high entropy, and high entropy data doesn't compress very well, typically it actually increases in size.

For example, search Google for a file called "million random numbers", it is a VERY high entropy file.  Download it and compress it with as many compression tools you can get your hands on, in all cases the "compressed" file will be larger than the source.

Compression of block data in the traditional sense is useless and pointless.

[GenTarkin]

This is the situation and what we know:

To scale further by any decent increase ... would mean full nodes wanting an incentive for anyone to actually run a full node.
Whos gonna build a server farm to just run full node and not get paid anything!? that would be an idiot thing to do.
The protocol should somehow award full nodes....
Dont ask me how tho... LOL .... a portion of the tx fees?

[nutildah]

Bitcoin is nearly all-but-dead to the general public.

If you want to kill its chances of mainstream adoption entirely, then by all means, please proceed with the fork.

[ElectricMucus]

Hahaha, where is the debate about alternative proposals, there have been some, yet nobody in the "pro-fork" camp even bothers to dismiss them.
Instead the thread is filled with the same arguments as everywhere else.

I'm losing more an more opportunities to see this forum as anything else than a laughing stock.

[gentlemand]

Bitcoin is nearly all-but-dead to the general public.

If you want to kill its chances of mainstream adoption entirely, then by all means, please proceed with the fork.

It was never really alive in the first place.

[ArticMine]

Bitcoin is nearly all-but-dead to the general public.

If you want to kill its chances of mainstream adoption entirely, then by all means, please proceed with the fork.

It was never really alive in the first place.

Do you seriously believe that VISA could run its payment network using the punch card and tabulating machine technology of the 1930's and 1940's when credit cards first came out?  Keeping the 1 MB blocksize limit is exactly the same: Assuming the current costs for bandwidth, CPU, memory, computer storage etc. will stay the same for ever.

[ebliever]

Hahaha, where is the debate about alternative proposals, there have been some, yet nobody in the "pro-fork" camp even bothers to dismiss them.
Instead the thread is filled with the same arguments as everywhere else.

I'm losing more an more opportunities to see this forum as anything else than a laughing stock.

+1 Here is where the anti-20 MB crowd had their chance, and blew it.

I like bitcointalk, but it has an atmosphere that is kind of a mix of that Star Wars bar on Tatooine and a giant food fight.

[bitcreditscc]

how about we see these people argue it in this thread :- https://bitcointalk.org/index.php?topic=1347.0 where everything is summed up real quick but the real professionals

[ArticMine]

My proposal: Err on the side of decentralization.

That's not a proposal but a stance, we need more ideas. I think we should do the 8mb fork and use the time before that gets full to figure out and find a new solution to the problem.

The problem with the centralization argument is that that the proponents of keeping the 1 MB blocksize limit are ignoring Nielsen's Law. http://www.nngroup.com/articles/law-of-bandwidth/ Here is that math: Internet bandwidth grows at an annualized rate of 50% a year. Now start with 1MBit/s in 2009 and figure out what the equivalent amount of bandwidth would be in mid 2016 when the proposed hard fork is supposed to take place. The answer is 20.9 MBit/s. So a 1MB blocksize limit at the start of 2009 is equivalent to 20.9 MB blocksize limit in mid 2016.  

Does it now make sense why Gavin picked 20 MB? He did the math, something the proponents of keeping the 1 MB blocksize limit have simply chosen not to do.

[ArticMine]

how about we see these people argue it in this thread :- https://bitcointalk.org/index.php?topic=1347.0 where everything is summed up real quick but the real professionals

I believe jgarzik the OP of the thread is now on the side of keeping the 1 MB limit. He was not happy when I dug up his thread back in 2013.

[nutildah]

Does it now make sense why Gavin picked 20 MB? He did the math, something the proponents of keeping the 1 MB blocksize limit have simply chosen not to do.

Can you do the math on how much bigger the already bloated blockchain will become? Its size is already impractical for a new user who just wants to use BTC to get around having to use PayPal, Western Union etc.

You will be encouraging reliance on centralization if you increase the limit. Lets face it: bitcoin will never come close to being as fast or convenient as a credit or debit card. There are some niches where it will continue to be an improvement upon pre-existing payment methods, but making the blockchain potentially 20x larger in size is just dumb.

Why not a 5-fold increase to 5mb first instead of going straight for the 20x increase?