I prefer to respond to you on here because I don't have an account on either forum. I am not a believer in Bitcoin Unlimited myself, but I do feel that I have a fair understanding of the concepts and intent behind it and they do have some good ideas.


In your example your node is set to accept 1mb + 10%. (1.1mb?) If you were to receive a 2mb block, your node would accept it, but it wouldn't relay it. It would continue to follow the <1.1mb chain but it would also monitor the 2mb fork. BU has a secondary user adjusted parameter for determining max block size. You can set a maximum fork length. Your BU client will continue to accept blocks for both forks, but will only relay transactions and blocks for your <1.1mb chain, so it is not blind to the existence of the fork and will warn you of discrepancies between the two. However, if the 2mb fork gets more than your maximum fork length ahead of your prefered chain, your client will abandon the 1.1mb chain in favor of the longer one. So if your max fork length was set to 24, then you would stick to the 1.1mb fork until another fork becomes more than 24 blocks longer. This ensures that any overriding of your max settings can only come with a majority of the hashing power behind the move. Miners, in theory, don't have complete control either. A miner would need to consider the orphan risk before creating a large block. This orphan risk is intended to be an emergent property of the network created by individual node operators setting their prefered max block size. Maybe creating a 1.3mb block is fairly safe if the included fees are high enough to risk the orphan, but risking it on an 8mb block could be an almost guaranteed orphan. Every time a miner creates a larger block, it is a calculated risk. We may even see varying mining pools emerge based on people's risk/reward tolerance levels, particularly when the block reward is minimal and the miners are relying on cramming in as many transaction fees in as possible to get paid.

It essentially turns the hard blocksize limit into a soft limit that can be overruled with enough sustained hashing power. The idea is rather than fighting to prevent fragmentation and forking by setting a hard limit, it embraces forking and attempts to manage it in an automated fashion while fragmentation exists and eventually converges on a single fork if it has sustained miner support. In theory, a wallet that is aware of multiple forks can ensure that you are not cheated.

As I said before, I don't completely agree with BU. I have some issues with the logic behind it, but it does have its merits. I'm going to reply to my own post here and talk about what I consider the negatives to BU, but I want to list the positives here. I love the concept of monitoring alternate forks and converging on one if it gets to a certain length ahead of the rest. I personally think that this feature could be very useful even in Bitcoin Core. Imagine using this method but with the variables hard coded to 1mb and a hard coded max fork length rather than being user adjustable. You would essentially be turning any future blocksize increase fork into a much less scary thing. In reality, a blocksize fork needs to happen eventually, regardless of if it is forced through by BIP101 or if is planned on and agreed to years from now. If these features could be refined and implemented into Core, it would allow for a smoother transition without all the emergency upgrades and damage control.

My main issue with Bitcoin Unlimited is how will it handle merging into a new fork? Let's say that I'm at 1mb max and a 1.01mb block is made and remains the largest block in the new fork. What does my client set it's max blocksize to? Is it 1.01mb? What if a 1.02mb block is created right after I merge into the new longest fork? Will my client be out of sync again until the fork grows longer? I'll probably be out of sync a lot unless I manually go into my client and raise the limit to give it some buffer area. I feel like it would be too easy for the miners to basically bully the node operators to push the blocksize higher, especially with a majority of the miners in one physical region. The only thing holding miners back would be the orphan risk and I'm not even sure if that can affect them. It would be trivial for mining pools to build there own block relay network (which I think they have already). My other issue with BU is it lacks a way to move the blocksize down, only up.

I personally think that they should be supported in their efforts because their attempts at automated fork management could eventually benefit everyone even if it never succeeded as a method of setting the blocksize limi