Bitcoin Classic, the Bitcoin expansion solution, is back, with three highlights worth noting

Bitcoin Classic was created in response to market demand for larger blocks. It is offered by a competing (and Core) group of developers as the primary way to scale Bitcoin to the next million users. We have come a long way since the first announcement in February. The Bitcoin landscape has changed, mostly for the better. This is an achievement we can be proud of.

Our two main goals are: more distributed development and larger blocks. We are very close to both of these goals now, but there is still more work to do.

I started this journey 3 years ago. I tried to use the Bitcoin Core code to improve some annoying things. Now, 3 years later, I have looked at every file and most of the code in Bitcoin. This is a very worthy research problem and will take years.

My main role at Bitcoin Classic is version management. This basically means that I am responsible for releasing the highest quality releases. I love inventing and writing code. I have been doing a lot of that over the past few months.

So why is this blog titled "Classis is back"? Actually, it never really went away. I think Classis was put aside when we released the 2MB remediation solution which caused a lot of market reaction and discussion. But Classis has always been our released solution, we were just busy coding and improving it.

One of the changes we are seeing in the market is a change in the understanding of how all the Bitcoin software works together. This idea has been used many times before, so it has stood the test of time. It is about how we can have a limit without putting a limit on the software.

All software, when it is immature and targeted at a small number of users, has limitations built in. These limitations exist because the developers know that their software can't be good enough, and limitations are by far the easiest "solution".

This design is not uncommon. Older people may remember that the memory size of DOS was once 640KB. 20 years ago, the maximum size of an email was 1MB.

Part of software growth: finding better solutions makes those limitations obsolete. Limitations are removed, and people are happy.

Removing the limit in software does not make it unlimited. It just makes other costs limit the actual size. You still can't send a DVD sized email. The maximum size right now is determined by the market and is a basic calculation of cost and benefit.

Let’s look at some of the market incentives for Bitcoin miners:

1. It is good for a miner to mine bigger blocks because he gets more fees.

2. On the other hand, smaller blocks are nice, keep a little scarcity, and still have people paying the fees.

3. Additionally, larger blocks take more time to send, which increases the chances of computers being obsolete, both of which are expensive.

4. On the other hand, smaller blocks will lead to larger backlogs. As a result, paying users will be poorly served. In the competition, we want to avoid losing their support.

5. These are conflicting incentives. There are reasons for wanting larger blocks, and there are reasons for wanting smaller blocks. The end result will be that block size is determined by the market demand for block space. Simply because that is the most profitable for miners. The flip side of good here is that the best case scenario for miners is also a good case scenario for everyone else in Bitcoin.

Andrew Stone proposed that everyone publish the maximum size they are willing to accept, making the market for block sizes an open market. Now miners can decide on the ideal block size without having to worry about their blocks being rejected by other miners because they are too large.

A purely market-driven block size is a big change for Bitcoin. It may take a little time before everyone gets used to it. In the meantime, Classic is working on several next-generation projects.

Network Manager/Admin Server

In Classic I started a project:网络管理器. It is a replacement network layer that solves many problems with the p2p code we inherited from the Satoshi client. In addition to this, an admin server is currently being built. The admin server will fill the role of remote control. You can create transactions, query the blockchain, sign data and ask it to make coffee. Except for the last one, all are already implemented, this admin server just uses the existing functionality of the "Bitcoin-cli" application.

It shines in that it is faster to varying degrees, and it not only allows you to ask questions like a web server, but the management server has a live connection and can push out data, such as when a new block is added.

As a result, it enables a new set of network-enabling tools that can be created with it. Some examples of where this is used are: * Application management software that monitors any number of nodes under its control due to warnings and slowness. But also for operational statistics, such as how many megabytes have been sent. * Scientific research that queries the entire blockchain without the need for local storage. * Much faster uploads of large blocks from miners to full nodes.

The project is nearly 80% complete. Is Classic back on track?

Flexible Transactions (BIP134)

In the Bitcoin 0.1 version released by Satoshi Nakamoto, he gave a very good indication of his future intentions. He included a field for the transaction version number. Today, 8 years later, the fact is that we are still using the transaction format of version 1. We have not taken advantage of the version number field provided by Satoshi Nakamoto.

There are a lot of issues with Bitcoin’s design that could actually benefit from fixing them in the transaction format. Resilient Transactions is a protocol upgrade that is meant to make this possible.

The弹性交易proposal has been in development for several months, and we have addressed many of the issues with the first version.

Fixed Bitcoin issues:

1. Fix scalability bug

2. Linear scalability of hash operations in signatures

3. Support for hardware wallets (also known as fraud proofs)

4. Very flexible for future expandability

5. Double Spending Proof

6. Make transactions smaller

7. Lightning Network Support

8. Support for adding script versions in the future

9. Where are we now?

Elastic Transactions has been tested on the test network and has achieved 80% of its functionality. We still have more testing to do.

Bitcoin Classic will absolutely be back.

Developer-friendly

Bitcoin Classic is based on Satoshi's codebase from 8 years ago, and I myself have been spending more time than expected learning this codebase. I've learned from other developers that I'm definitely not alone. The codebase isn't even that big! The most commonly heard complaint is its lack of modularity.

Hard to understand code leads to low-quality products. This is easy to understand: programmers are human too, and when they have to create clean code in a dirty environment, they make mistakes. I think it is important to focus on improving the architecture and code quality of Bitcoin Classic. The goal is to help developers understand the code faster while making our product of higher quality.

The best way to start fixing this problem, because of the lack of modular design, is to introduce this modular design. Basic coding, such as "Application" class as a starting point for application-wide resources, and more coding will follow.

The various products I mentioned today are also based on common, reusable technologies. As a quick example, adopting a common message format would be a common layer between elastic transactions and network managers and management servers.

I feel like it’s really important to work on these improvements together with the other teams that are part of Bitcoin. They have their own improvements, and we end up reusing each other’s inventions and the final code. I had a lot of great conversations with people like Pedro Pinheiro, Dagur Valberg Johansson (dagurval), Amaury Sechet ( deadalNix ), Andrea Suisani ( sickpig ), Freetrader, and Justus Ranvier . They are great people to work with and have been involved in a large part of Bitcoin’s implementation. There are a lot of similarities in our approaches and ideas.

It’s the differences that matter. Each Bitcoin client is unique in its own way. This is useful to everyone and helps avoid the echo chamber problem where we avoid stifling ideas before they come. More people competing on a friendly basis benefits everyone and means there are many possibilities for Bitcoin.

Bitcoin Classic is back. There are some very exciting things being developed at Bitcoin Classic, and we have all come a long way.

Tags: Bitcoin Community Life

© Copyright 2016 Tom Zander <[email protected]>

Content licensed under CC by-sa