Reimplement BU-minimal based on KISS principles

[nfujimoto]

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.

 

[nfujimoto]

Let me emphasis my main concern right now: I am seriously worrying about that bugs may be exploited during the hardfork. Few hours interruption during normal operations may be tolerable. However, few hours interruption during hardfork is more than enough to kill it. Some miners will be forced to stop, or switch back to the Core clients. What will be the backup plan?

 

[CubicEarth]

I don't have an opinion on the exact series of steps you outlined, but I wholeheartedly agree with the concept and your reasoning.

I was thinking of suggesting almost the exact same thing, although perhaps even simpler, with just providing the a slider in the preferences to set the max block size. There wouldn't even be any signalling. The premise of Unlimited, at is most basic, is the user can choose the block size, so a first move that reflects that minimalism seems prudent.

 

[nfujimoto]

The signalling part is very important. It gives confidence to the miners that the whole network is ready to accept the large blocks. There should be some minimum number of nodes, say a 1000, before any changes. The node signalling is complemented by the signalling from exchange/merchant/etc, before anything happen.

 

[CubicEarth]

This is going against the idea of keeping it simple, but what about the Sybil factor? Every day there are examples of problems that I think can be ameliorated by using some form of proof of stake.

Wouldn't the signaling be more significant - more trustworthy - if it was signed by keys that control coins? Or, to preserve security, the signals could be signed by the keys that previously controlled the coins.

Maybe we could call it Signed Signaling. Perhaps that is another discussion.

 

[nfujimoto]

No. Adding signalling is only few lines of code. No bugs will be introduced.

Ideally, you will want all people involved, like a hard fork. Miners vote by embedding message in coinbase. Nodes vote by signalling. PoS voting represents holder's opinion. Exchange/Merchant can vote by publishing statements. Developer can also vote similarly, or by adding a new default value to the new clients. For the blocksize, it is much simpler if only those being impacted votes. Sure the other have veto power.

 

[torusJKL]

@nfujimoto I like your idea.
But it sounds almost like BitcoinEC. (https://github.com/bitcoinec/bitcoinec)

 

[sangaman]

This is a great post and idea. A minimalist BU implementation, with only important and well-tested changes from Core as you described, would make a potential hard fork go much more smoothly I believe. If a change doesn't require a hard fork, it doesn't really need to be packaged with code that implements the hard fork. I do think it would be nice if other hard fork "wish list" items could be gracefully packaged with a block size increase fork - since who knows when there may be another opportunity - but that might be wishful thinking.

 

[nfujimoto]

@nfujimoto I like your idea.
But it sounds almost like BitcoinEC. (https://github.com/bitcoinec/bitcoinec)

I have just discovered the project too. The idea is quite similar, but the main focus here is the development model. It is managed by the same development team, and they only port the confidence change from the BU eventually. One the other hand, the BitcoinEC will follow closely the Core development, which is arguably good and bad. For example, the Core 0.14.0 have a memory bug that is likely also in the BitcoinEC. Well, new features, new bugs, it is normal.