Recently there is rumor that Bitmain will support this BUIP. And Peter has pinged me in Slack. So I decided to give some comments on this BUIP.First of all, hard fork is not purely technical but also political. The censorship, troll army like Dragonsden and privately paid news reporters are direct evidence that the hard fork is political. And the obsession with letting RPi be able to run full node is also another kind of politic. Any decision about a hard fork will need to consider both. Here I will not comment on the political side of this proposal but just the technical side.This is a hard fork, which is a kind of changing in the consensus rules. Bitcoin protocol consensus rule changing has evolved a lot and has its best practice by now. In the early days, Satoshi N. was God. He could introduce consensus rule change arbitrarily. 1MB block size limited was introduced by adding the code without anyone else knowing about it, and today we are still in this trouble. Later, the community used coinbase voting. Gavin's and Luke's two different scheme of multi-sig were voted by coinbase. The most recently process of changing consensus is BIP9 . It is the most reliable way to introduce a consensus rule change. So we would better to use such kind of process rather than going back to coinbase signalling methods. BIP135 is an improvement of BIP9, which eliminated the 95% magical number. However, it is lack of reviewing and testing. I believe it worth the community the effort. After the BIP135 is mature, we can use BIP135 to introduce consensus rule change.Flag day activation is dangerous. Human cannot predict the future. Human changes their minds constantly. Once such code released, miners may avoid running it at all, because miners are not sure about the readiness of other players.We should use BIP9/135 to determine the forking block height. The signalling and the activation are both pre-coded and there is a higher confidence of the trustworthy of the signalling and the activation.There is still re-org risk in such BUIP055. Bitcoin Unlimited follows the longest PoW accumulated chain. So if the big block chain happen first because majority of the hashing power support it, and then there will be two chains. (I will not comment whether it is good or bad to have two Bitcoin chains, or which chain is the better Bitcoin.) And if the small block chain is more profitable to mine due to either reducing in difficulty or higher exchange rate, and then there might be a risk that small block chain will have higher PoW accumulated, then BU will have to have to have a very large re-org. (Sorry, I have to add a political points here: the existence of such possibility will bring pressure on the exchange rate of the big block Bitcoin. If BU uses some very arbitrary methods to invalidate certain block, it will be very ugly.)Since it is a very significant consensus rule change which has been debated for 4 years, we can add another consensus rule at and ONLY at the forking height, the size of the block HAS TO be bigger than 1,000,000 Byte. It is a very simple and straight forward way to protect re-org.Conclusion: Bitmain has not decided to support this BUIP or not, but we have give some comments based on technical merits. We should use BIP9/BIP135 to signal and decide the forking height, and we should add a rule that at and only at the forking block, the size of that block HAS TO be larger than 1MB to prevent re-org. The technical comments should not be seen as an offer of supporting such BUIP.Edit on May 12th, 2017What if there is not enough transaction in the mempool and bigger than 1MB block cannot be built?Yes, there is such probability. And the getblocktemplate will just find it cannot generate a valid block. Then we should just wait, until there is enough tx. It has been four years and we can afford to wait a few minutes, even 1 hour. And there is already a very good profitable transaction you can put into the block. " Save the chain ".