Bitcoin: Long-term outlook

Bitcoin is an amazing concept that has been around for 8 years and has been a huge success. It is far from perfect though, and there are many issues that need time to be corrected in a friendly and responsible way. I wanted to share my thoughts on the long-term engineering goals for Bitcoin full nodes that guide my priorities, which you can already see in the 1.2 release of the Bitcoin Classic full node last week.

1. Documentation of the protocol

Bitcoin as a whole is often referred to as a protocol. But unlike most protocols, there is little documentation describing Bitcoin in detail, which is like walking a tightrope.

The first goal is to move towards a fully documented Bitcoin. The key point here is that the protocol document is the "leader". Therefore, if there are two different implementations, the protocol document is the standard for judging which one is correct. This avoids some meaningless arguments, such as who has the largest market share, or who has the longest chain, etc. to evaluate who is the real Bitcoin.

2. Backward compatibility of the protocol

The current Bitcoin protocol design often has parts that do not follow the best practices of the software industry. Many of these design parts do not cause big problems, but there are some best practices in the software industry that should be followed. A good example is that the data structures of the Bitcoin protocol are immutable. It is impossible to add a value to Bitcoin's p2p information, and you cannot remove useless values ​​because they are stored in every transaction.

The second goal is to move towards tagged protocol data structures. The idea of ​​tagged data structures dates back decades, to before Bitcoin was created. The key point here is that we know that mistakes have been made, and that they will continue to evolve as we extend and amend Bitcoin. To do this, we need to be able to make backwards-compatible changes cleanly. It is cleaner to add a new field to an existing p2p message than to create a whole new message type with all the same information and one item.

NOTE: The fundamental concepts of Bitcoin are clear and sound, and that is not something we should change!

3. Make blockchain database more convenient to query

Bitcoin as an industry depends on the blockchain being a universal database that is shared and used by everyone. The main property of a database is that it can provide fast access to the information you seek. To give an example of fast access, a normal database would be able to return all transactions since a certain date.

Unfortunately, access to the blockchain in any full node is very primitive and very slow, making the blockchain essentially private data. This means that block explorers end up having to recreate a complete database. The study of usage patterns and many properties is limited to a few very patient people.

The third goal is to make Bitcoin full nodes provide full access, including its database. Simple access to raw data is much faster, and this allows full nodes to have a very large range of features, making running a full node much more useful.

This blog originated as part of the long-term roadmap for Classic, with the second part detailing each of the goals.

Join the Bitcoin Classic community

Do these goals align with what you're looking for in Bitcoin? Please consider joining us. Running the client, sending emails when you find typos, or simply sharing your stories on news sites is a great way to get started. Read the Classic community page to find more ways to join this exciting revolution.