The truth about the block size issue

[LiteCoinGuy]

The truth about the block size issue

I'm Olivier Janssens, board member of the Bitcoin Foundation. You may remember me from the famous post https://www.reddit.com/r/Bitcoin/comments/31e6jh/the_truth_about_the_bitcoin_foundation/

Today I have something else to share. Me, like many others, failed to understand why so many of the core devs are so resistant to a block size increase. It does not make any sense. Their main argument is that it will lead to more centralization because it will become more expensive to run a node. That argument is completely flawed and the opposite is true. First of all, consumer hardware can and will support 8mb blocks and beyond. Second of all, the risk of centralization is much worse when we don't do the size increase, since it will become prohibitely expensive to get a transaction sent.

https://www.reddit.com/r/Bitcoin/comments/3hixuu/the_truth_about_the_block_size_issue

[desired_username]

I also dislike the apparent conflict of interest when it comes to Blockstream and Bitcoin development.

[zeroday]

I support blocksize increasing idea, but not in a form of fork such as XT, which besides block size has some shady unannounced privacy affecting features such as Tor blacklisting.

IMO, everything must be done inside Core client.

[knight22]

That's why XT is more important that most people would think. It gives an option to the market. Either the market will choose it if it fills its needs or reject it and go bust. There is no in between.  

[RustyNomad]

I support blocksize increasing idea.....

Agree, I also support a blocksize increase but not in the way it's being done now. Initially there weren't any consensus which I believe led to this whole XT thing. Since then however many decent proposals have been made in regards to how the scaling could/should be done.

What we need now is for those in the know to sit down and work through these proposals to take the best of each and get it implemented asap. I hope the planned workshop in September in regards to the scalability issues will get this resolved so that we can move forward.

[LiteCoinGuy]

I also dislike the apparent conflict of interest when it comes to Blockstream and Bitcoin development.

i think that is false but take a look:

https://de.reddit.com/r/Bitcoin/comments/3hk4ce/bitcoindev_bitcoin_xts_tor_ip_blacklist/

[Hazir]

I support blocksize increasing idea, but not in a form of fork such as XT, which besides block size has some shady unannounced privacy affecting features such as Tor blacklisting.

IMO, everything must be done inside Core client.

I thought that changes like block size increasing can be done only with forking. Am I wrong?

[pedrog]

I support blocksize increasing idea, but not in a form of fork such as XT, which besides block size has some shady unannounced privacy affecting features such as Tor blacklisting.

IMO, everything must be done inside Core client.

Introduce the beginnings of anti-DoS resource scheduling.

This adds code that takes effect if a node gets completely full (this should never happen unless there's an attack or the number of nodes falls dangerously low).

Peers now have a priority that attempts to estimate their importance. Currently it is just based on IP address. The default score is zero. In future it may take into account things like how many blocks were relayed, etc. When a node reaches its max connection slots, it will attempt to find a peer with a lower priority than the one trying to connect and disconnect it, to stay below the max connection limit.

Peer priorities are based on matching the connecting IP against a set of IP groups. For now, the only IP group is one that gives Tor exits a score of -10. This is to address DoS attacks that are being reported on the main network in which an attacker builds many connections via Tor to use up all the connection slots and jam the node for clearnet users. It's a more robust approach than simply banning abused proxies altogether.

The code has both a static list and a list that's downloaded when the node starts.

Other anonymizing proxy networks that are attractive to DoS attackers may also be added as alternative IP groups, as a quick fix. Eventually peer priority can be calculated in a more free floating and dynamic manner and the hardcoded IP approach may become unneeded.

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

Seems reasonable, if this is what you're talking about...

[zeroday]

I thought that changes like block size increasing can be done only with forking. Am I wrong?

Forking means that both versions continue development which creates conflict.
Updating Core with bigger block size will be just version update. After that we would need to wait until obsolete versions leave the network.

[knight22]

I thought that changes like block size increasing can be done only with forking. Am I wrong?

Forking means that both versions continue development which creates conflict.
Updating Core with bigger block size will be just version update. After that we would need to wait until obsolete versions leave the network.

In fact, it is also creating a fork. Old Core nodes will become incompatible with the latest version.

[Luqman]

I do supporting increasing block size idea but not for XT 

[meono]

I support blocksize increasing idea, but not in a form of fork such as XT, which besides block size has some shady unannounced privacy affecting features such as Tor blacklisting.

IMO, everything must be done inside Core client.

what the hell? Zero, i dont think you understand what shady means

The damn changes log clearly says it all. Yet ppl still dont read it or intentionally spread FUD.

The code is opensource, if you're naive enough to believe Mike would assume noone read his code.

Lastly, spend 10 mins to read and verify the info b4 jumping on the bandwagon.

[croTek4]

I thought that changes like block size increasing can be done only with forking. Am I wrong?

Forking means that both versions continue development which creates conflict.
Updating Core with bigger block size will be just version update. After that we would need to wait until obsolete versions leave the network.

In fact, it is also creating a fork. Old Core nodes will become incompatible with the latest version.

Correct, whether the block size limit increase is executed in core or xt, it will be a fork.

[Lauda]

That's why XT is more important that most people would think. It gives an option to the market. Either the market will choose it if it fills its needs or reject it and go bust. There is no in between.  

No.
Anyone could have started their own fork and only increased the block size. Actually if someone had done that, we wouldn't be in this mess. XT wouldn't be such a issue if it wasn't lead by Hearn and didn't contain controversial patches.

I'm Olivier Janssens, board member of the Bitcoin Foundation

This gives him no credibility to say:"That argument is completely flawed and the opposite is true" without evidence. Just because they are involved with Blockstream it doesn't mean that it is the reason, or only reason.
Also, he should have no problem posting a decrypted version of that email (if it was true).

[LiteCoinGuy]

I do supporting increasing block size idea but not for XT 

That means there will be no increase buddy.

I think Gavin tried to compromise and has compromised. Remember this started with 20mb and 50% growth, now it is 8mb.

Really, if this was a sort of negotiation which is what a compromise would entail, one side started with 1mb, Gavin with 20, the other side moves to 2, Gavin to 8, they go to 3, Gavin to 6 and they meet somewhere in the middle 4 or 5mb. Gavin would probably think this is a bit too low, the other side a bit too high, but both would find it acceptable considering that a compromise is necessary.

Same with % increase. I do not think we would want another fork over this debate again seeing how it has developed. So one side would start with 0%, Gavin with 50%, the other side 5, Gavin 40, the other side 10, Gavin 30, and meet somewhere in the middle of 15 - 20%.

4mb with 15-20% is the compromise solution really. I wouldn't compromise any further on that and I think that almost everyone would be happy for it except for a fringe hardcore tiny minority and unfortunately there will always be a hardcore tiny minority with any change either due to ideological or financial reasons.

Unfortunately the other side did not want to compromise. I hear for example that Gregory Maxwell is against intentional hard forks in general and as long as he says nack then there can be no "consensus" and there would be a "contentious" hard fork. Pieter was willing to compromise, after a 4 months debate, but instead of going to 2mb to start with some % increase, he suggested 1.04mb in two years! We can't be debating forever seeing as this matter has been going on for years and, as they are unwilling to compromise then Gavin is right to go with his original proposal which has been modified to take miner's concerns into account.

If we don't move ahead then we basically give one man or two, that being nullc or pieter, veto powers which would be quite a dangerous precedent.

Finally, BitcoinXT is not set in stone. If miners or the community has any concerns with the size or the %increase, then they can raise them and their concerns can be addressed as they did for example by saying a jump to 20mb was too much, but 8mb was acceptable.

[meono]

I do supporting increasing block size idea but not for XT  

That means there will be no increase buddy.

I think Gavin tried to compromise and has compromised. Remember this started with 20mb and 50% growth, now it is 8mb.

Really, if this was a sort of negotiation which is what a compromise would entail, one side started with 1mb, Gavin with 20, the other side moves to 2, Gavin to 8, they go to 3, Gavin to 6 and they meet somewhere in the middle 4 or 5mb. Gavin would probably think this is a bit too low, the other side a bit too high, but both would find it acceptable considering that a compromise is necessary.

Same with % increase. I do not think we would want another fork over this debate again seeing how it has developed. So one side would start with 0%, Gavin with 50%, the other side 5, Gavin 40, the other side 10, Gavin 30, and meet somewhere in the middle of 15 - 20%.

4mb with 15-20% is the compromise solution really. I wouldn't compromise any further on that and I think that almost everyone would be happy for it except for a fringe hardcore tiny minority and unfortunately there will always be a hardcore tiny minority with any change either due to ideological or financial reasons.

Unfortunately the other side did not want to compromise. I hear for example that Gregory Maxwell is against intentional hard forks in general and as long as he says nack then there can be no "consensus" and there would be a "contentious" hard fork. Pieter was willing to compromise, after a 4 months debate, but instead of going to 2mb to start with some % increase, he suggested 1.04mb in two years! We can't be debating forever seeing as this matter has been going on for years and, as they are unwilling to compromise then Gavin is right to go with his original proposal which has been modified to take miner's concerns into account.

If we don't move ahead then we basically give one man or two, that being nullc or pieter, veto powers which would be quite a dangerous precedent.

Finally, BitcoinXT is not set in stone. If miners or the community has any concerns with the size or the %increase, then they can raise them and their concerns can be addressed as they did for example by saying a jump to 20mb was too much, but 8mb was acceptable.

From Satoshi's view,

20mb was a compromise

8mb was another compromise

The majority agreed with 8mb. YET bitcoin core devs still refused to work with Gavin.

Now we have to beg them? Bitcoin isnt about trust or authoritative figure. Its about choice and freedoom. If the fork happens, thats the direction bitcoin community choose. Dont blame anyone else.

[Luqman]

-snip-

Great, I just a noob, there's no other way to increasing block size without "moving" to Bitcoin XT ?

[LiteCoinGuy]

No because there is no consensus possible at the Bitcoin Core Side.

Core = 1 MB
XT = 8 MB

make your choice.

you dont have to do something actually. you will keep your BTC one way or the other.

[meono]

I do supporting increasing block size idea but not for XT  

That means there will be no increase buddy.

I think Gavin tried to compromise and has compromised. Remember this started with 20mb and 50% growth, now it is 8mb.

Really, if this was a sort of negotiation which is what a compromise would entail, one side started with 1mb, Gavin with 20, the other side moves to 2, Gavin to 8, they go to 3, Gavin to 6 and they meet somewhere in the middle 4 or 5mb. Gavin would probably think this is a bit too low, the other side a bit too high, but both would find it acceptable considering that a compromise is necessary.

Same with % increase. I do not think we would want another fork over this debate again seeing how it has developed. So one side would start with 0%, Gavin with 50%, the other side 5, Gavin 40, the other side 10, Gavin 30, and meet somewhere in the middle of 15 - 20%.

4mb with 15-20% is the compromise solution really. I wouldn't compromise any further on that and I think that almost everyone would be happy for it except for a fringe hardcore tiny minority and unfortunately there will always be a hardcore tiny minority with any change either due to ideological or financial reasons.

Unfortunately the other side did not want to compromise. I hear for example that Gregory Maxwell is against intentional hard forks in general and as long as he says nack then there can be no "consensus" and there would be a "contentious" hard fork. Pieter was willing to compromise, after a 4 months debate, but instead of going to 2mb to start with some % increase, he suggested 1.04mb in two years! We can't be debating forever seeing as this matter has been going on for years and, as they are unwilling to compromise then Gavin is right to go with his original proposal which has been modified to take miner's concerns into account.

If we don't move ahead then we basically give one man or two, that being nullc or pieter, veto powers which would be quite a dangerous precedent.

Finally, BitcoinXT is not set in stone. If miners or the community has any concerns with the size or the %increase, then they can raise them and their concerns can be addressed as they did for example by saying a jump to 20mb was too much, but 8mb was acceptable.

From Satoshi's view,

20mb was a compromise

8mb was another compromise

The majority agreed with 8mb. YET bitcoin core devs still refused to work with Gavin.

Now we have to beg them? Bitcoin isnt about trust or authoritative figure. Its about choice and freedoom. If the fork happens, thats the direction bitcoin community choose. Dont blame anyone else.

Great, I just a noob, there's no other way to increasing block size without "moving" to Bitcoin XT ?

Blocksize increase require a hard folk. So sadly you cant do it on your own. You need the majority of the network to agree to use your chain.

For a noob, i think this is an impossible task.

Even Gavin who has helped building bitcoin since Satoshi left is still stuggling convince the community, some even goes as far as trashing him with conspiracy.

[ummina]

 While having a high-capacity set of full nodes increases the on-blockchain transaction rate, the requirement of full nodes to be high capacity has a centralizing effect. Scalability solutions that don't require high capacity full nodes include sidechains and the Lightning Network.