Reimplement BU-minimal based on KISS principles
People now desperately want a way to reduce the fee. BU is a good candidate but it is still not mature enough. In addition, the current BU is moving away from the KISS principles, which is ironically a major criticism for the Segwit. It is clear that the two recent major bugs (save few hundred bytes, and faster transfer for nodes) are caused by the aggressive performance improvement. Let’s not forget that the most central principle of BU is the user adjustable block size. Everything else is additional feature, which always come with associated bugs. If those bugs were to be used during hard-fork, it is destined to fail and no people and miners will give another try of any hard-fork.
Since the hard-fork is imminent and things get serious, there are quite handful programmers expressed interest to help to review. However, the commit history is quite long and messy with a thousand commits. It would be easier to get helps this time if the whole process is more standard and transparent. Based on the KISS principle, the simplest implementation should include no thin block, no parallel validation, keep GUI improvement minimal. Even without performance improve, it can still work perfectly for 2MB, or even 4MB, 8MB, or maybe 16MB. Those features are for the future. They are not necessary for a successful hard-fork and user adjustable block size. Right now, the desire of a bug-free implementation is orders of magnitude important than those features.
Here comes to the suggested strategy: BU developers initiate a new branch BU-minimal from the Bitcoin-Core 0.12.1, then add the user adjustable block size options with a hard limit, which means that no block larger than this size will be accepted. Hence, the corresponding signal string is EB16 and AD999999. Developers then cherry-pick the small subset of necessary improvement and confident changes from BU, and bug fix from Core. All commits must follow the industrial standard and must have a pull request. Then people are invited to review all pull requests and developers have to explain the rationale. Preferably it includes previous experience Bitcoin developers. The development model will become a full feature BU client first, then the performance improvement will be eventually ported to a more conservative BU-minimal client when the features become mature. There are no urgent to merge them, say, parallel block validation. It will be a great way to rebuild trust on the code quality.
The benefits are many folds:
1. It is now agreed that the first hard-fork will be manually triggered, so the AD mechanism is not really needed at the moment. However, the trade-off with security is huge. There are doubts on the AD mechanism, which is the reason AD is raised to 12 now. In the real world, it is clear that any blocksize increase without any block signal, discussion, and pre-announcement should be considered as an attack. Recently, there is also discussion of moving toward signaling mechanism to BIP100, so AD is less important now. People can always set a larger block if they believe it is ok.
2. BU-minimal can be considered as an independent implementation from BU. Therefore, it will make the whole network more sophisticated. Miners, exchanges, and merchants should always run both in parallel to take the advantage of both of them. In such environment, the AD mechanism can be tested before fully deployed.
3. It is much easy to invite reviewers to only review the important part. If experience developers can join the review, such as Gavin, they can certainly point out the specific Bitcoin quirk like recent bugs. This can greatly improve the confidence in the whole community.
4. The commit history can serve as a guideline to miners. Mining pools may have their own codes and need time to update, so they may not want to adopt any new client directly. There is good chance that the non-voting miners are still running the Core 0.12 version. BU-minimal allows them to easily patch their current software and give them confidence.
5. It is believable that hackers are now holding a handful of bugs for the future attacks. The re-implementation will invalidate almost all of these weapons. Core 0.12 is also the most reviewed codes which are the base for, say, BitcoinClassic and Namecoin.
6. Since BU-minimal is almost the same as Core, it can minimize the doubt and criticism from neutral people and Core supporters. This will reduce the resistance and be easier for them to accept the block size increase when it happens. This also allows easy backport to Core, if they want. There are no need to create a hostile environment.
BU-minimal should be compatible with BU. Based on KISS principle, the change should small: Few thousands line of codes and completed in a month. With both a bug-free and a future-proof implementation, it should be sufficient to defend again the real world operations and criticism.
Bitcoin is not a toy anymore. Mature codes and confidence are necessary to gain the support from the “economic majority”, and the majority are neutral to any block size increase. They will just leave if the environment gets worse. At this point of time, BU developers initiated BU-minimal based on KISS principle can like ensure a bug-free implementation and regain confidence in the community. I strongly encourage developers to consider all possible way, including the development model, to reduce the risk during hardfork.