Bitcoin Classic Statement.
Bitcoin Classic is not affected by the remote-crash bug publicly displayed in Bitcoin Unlimited. This clear message is made in response to various people making statements about Bitcoin Classic. Bitcoin Classic is NOT affected by this issue, and has very strict quality procedures. . While I won't say this will never happen, we do as much as we can to maintain our high standards.
The battle for the direction that Bitcoin will take is heating up when SegWit supporting pool BitClub chose to go rogue and instead of protecting Bitcoin with hash power, it has now made moves to attack it.
SegWit is too many changes in one go, one of them is that it tries to fix
A technique that changes a transaction as they were initially created to
still be valid, but the transaction-ID ends up being changed.
The direct effect of this is that some wallets or businesses can get confused for some days. Also financial transactions can get cancelled and need to be re-send.
The effect is not dramatic, the architectural problem has been in Bitcoin from the beginning and has been known for many years.
But today we learned that the BitClub mining pool is actively malleating transactions they mine. changing their transaction-id so the original sender may have problems. This is no accident, you need to write special software to alter those transactions so they don't break. And while the network as a whole will really not be bothered to much by this minor attack, we have to understand what this means.
On one side we have Bitcoin Classic and Bitcoin Unlimited arguing for reasonably sized blocks , and on the other side we have some people argue strongly for SegWit. Up until now the argument was always that the 1.7MB that SegWit offers should be good enough, but the market isn't buying it. The support for bigger blocks is now much larger than the support for SegWit. The SegWit support has been around 23% for months, while the BU blocks get about 32% support, which is just in the middle of a rather larger increase.
Now we have a change in strategy, BitClub is actually trying to cause a problem by actively changing transactions while openly supporting SegWit, which no doubt they will argue is the solution to the problem they just created.
The truth of the matter is that SegWit doesn't solve malleability, and what
it does solve comes at a great price.
What SegWit does instead is it introduces a new transaction type, with many problems at the same time, and only should users choose to upgrade their wallets and then actively use those new type of transactions will their transactions no longer be malleable.
Agreed, it is rather annoying that anyone can change your transactions and I agree we should solve that. For this reason I wrote Flexible Transactions (more here). It is new transaction type which doesn't suffer from the malleability issue.
The beauty of Flexible Transactions is that it doesn't pretend to be a block size increase, but it does solve 100% of all the issues that SegWit solves. And more! Additionally, Flexible Transaction is much safer to use and more future-ready than SegWit. Flexible Transactions has been running on its own testnet for months now and various alt-coins are integrating it.
In short, Flexible Transactions is a next-generation solution for encoding transactions, using a tagged system which is future-proof and allows unlimited future growth of Bitcoin. It generates smaller transactions, it is safe from malleability attacks and quadratic scaling attacks.
I would like to suggest to mining pools like BitClub that they realise they are actually hurting Bitcoin users and their actions are indeed annoying actual users that create Bitcoin transactions. Going forward, we do have a good solution for malleability and it is in the form of Flexible Transactions. Please don't be fooled by aggressive marketing techniques which will want to make you believe SegWit is the only solution. It is not the only one, it is certainly not the best solution.
I am saddened that there are those that hold the misguided belief that attacking your users is a good way to keep control over Bitcoin.
In Bitcoin Classic and Unlimited we support the users, we fight for normal level transaction fees, and we will never attack our user in order to try to prove some solution is needed.
This post will answer what happened in Bitcoin Classic since the last report
In an continuing push to make the Bitcoin Classic client the best one to
use on Linux we have seen some support added some time ago for the
XDG Base Directory Spec for config files.
Continuing in that direction Contributor Stephen McCarthy has been hard at
work with the command-line parser code.
The code we inherited when we started Classic is shared between various projects, in all of those a set of problems are present which make sysadmins and operators life a lot more difficult.
Passing in a not-existing config option or command line argument was silently ignored. So typos would go undetected. The most common problem was that when you added a
-to a config file option you would have your option silently ignored.
Flags usage was very inconsistent and not very predictable. The only solution that consistently worked was '-flag=1', but sometimes -flag works too and the most fun problem was that '-flag=true' would more often than not end up turning off the flag.
Inputs were not validated at all. If you passed something that wasn't numbers to a option that expected numbers, the effect typically was that the option would be set to zero. At best you might get a warning in the logs.
In the last weeks, Bitcoin Classic contributor Stephen McCarthy fixed all those issues and many small ones as well. If any command-line option is passed in that doesn't exist, or is expecting a number and you passed something else, you will get an error and your node won't start. Additionally, yes/no flags become more intuitive and will work properly with any of 0/1, false/true and also with yes/no.
Tom Zander committed a small change to prepare for a world where block-size
is no longer a centralized rule, allowing for a healthier network;
Punish nodes relatively for oversize blocks
In Flexible Transactions we have undefined tokens which are ignored by current software if present. This allows nodes to stay compatible when new tokens are invented. For miners this policy rule should likely be turned on so transactions that use tokens that are not yet defined will be rejected.
Tom Zander imported the "Expedited forwarding" technology to Classic's master branch commit.
Code cleanups / improvements;
Tom Zander created a new class which now becomes responsible for all orphan transaction handling. This is one step towards solving the problem of having no code structure and everything in one big 5000 line sourcefile. This a non-functional change, aimed to making the code better to maintain and easier to understand. commit.
Tom Zander did a refactor of the blocks database handling code. Similar to the orphan code above this is a non-functional change that moves code to be easier to understand and maintain. commit, commit, commit.
Amaury Sechet created a new PR which updates the 3rd party library secp256k1 to a newer version. We also realised that it is confusing for many that imported libraries are placed in the src directory as that makes the fact that they are snapshots and developed elsewhere not very obvious. But no solution has appeared at this time.
A PR by Stephen
McCarthy was merged and had the purpose to
Fix assertion error on
-disablewallet, fixing a regression introduced by another dev just a
couple of days before.
Another PR by Stephen McCarthy was merged and introduced a change that made 'Abort' the default button on the dialog that is very destructive, and a user input mistake there could cause many hours of work to recover from.
Tom Zander created a commit with the subject
Make splashscreen work on
Tom Zander imported the historical release notes on the website; https://bitcoinclassic.com/news/
If you are interested in the Bitcoin Classic project, please look at our community page for how to get involved.
Over the last year we have seen quite a lot of people that get worried about the UTXO growth. Lets find out why.
For those catching up; the UTXO is the Unspent Transaction Output database. The essential database that is needed to find out if a new incoming transaction is actually spending money that exists.
The growth is explained well in this blog from Gavin Andresen, the blog is already older, so the growth has continued.
There are some reasons why people claim this is an issue. Lets address each of them in turn.
The UTXO needs to be in memory completely. It will grow faster than internal memory can.
Answer: The implementation in all Bitcoin full nodes is that the entire database is stored on disk. With a smart memory-cache to speed up lookups. The memory-cache is configurable and the default is 300MB. (it's the
dbcache config option) The entire database is significantly larger than 300MB, as the above blog states.
The claim that it has to be in memory is weird because none of the full node implementations actually do that. Sure, miners can adjust their settings to allow a bigger cache, and be different from everyone else. But this doesn't mean the UTXO should stop growing.
Bigger blocks make the UTXO grow faster!
Answer: The UTXO is a database of where money is stored. With more people using and holding Bitcoin, this will grow. The UTXO will not just grow based on more transactions, the UTXO will grow because we get more customers. Which can only be done when we have bigger blocks.
So the argument isn't directly false, it is misleading. It is missing the fact that UTXO growth is based on more people using Bitcoin. Maybe the people making this accusation are aware that saying they do not want more customers will make them look stupid.
UTXO on disk will make miners lose money because of slow block validation.
Answer: This may have been true in the past, but is no longer true since we introduced xthin blocks. This technology allows any node to communicate a new block with only the header and some meta-data. The receiving node will then use the transactions that are in his memory pool to reconstruct the block.
The direct result of this is that when a new block is mined miners will not validate the vast majority of transactions again because the transactions in their mempool were already validated. This means that there is no bottleneck any more for miners using xthin (available in BU and Classic).
Bottom line is; it's a database. MySql/PostgreSQL/MongoDB etc. have had decades to perfect database technology. Being scared of a database growing on today's hardware is unfounded.
Bitcoin Classic is a typical open source project where individuals come together in order to join forces and create the best solution they can. It can be a bit chaotic to keep track of what is going on and for this reason I want to write a little update on what has been going on in Bitcoin Classic.
A very brief recap for those that have not followed along. Bitcoin Classic got a restart that I introduced with Classic is Back here 2 months ago. We released version 1.2 some weeks ago that introduced various new technologies. The CMF bindings project got its release shorty after.
Last week I spend most of the time in a plane or in the airport going to from the EU to Mexico where the Satoshi Roundtable III was. I very much enjoyed meeting many Bitcoin friendly faces and having discussions about how we can further Bitcoin and Bitcoin Classic. At the same time this is my apology for having much less coding based progress.
We have seen bugfixes in the 1.2 stable branch (to become the 1.2.1 release).
- [QT] Bugfix: ensure tray icon menu is not empty. By Stephen McCarthy.
- Fix failing maxuploadtarget.py QA test from the -extended set. By Stephen McCarthy.
- Make configure fail on old Boost. (1.55 has been the minimum for some time)
On the 'master' line of coding (to become the 1.3 version) we have seen various improvements as well.
- We merged a PR written by Pat O'Brien that sanitises the default permissions of files written by the node on Unix. Adding code to make sure that the wallet.dat is only ever visible to the main user.
- Merge a PR from Søren B.C. to remove some dead code (semicolons) from many files.
- Merge various PRs from Amaury Sechet for backports and to add sublime text project file to gitignore
- Merge a PR from Stephen McCarthy that makes sure that any unrecognised command line arguments or config-file lines will cause a warning on startup. This should make it much easier to configure the application.
- Cleanup the NetworkStyle usage. This makes code less fragile and more coherent.
- Remove duplicate (copy/pasted) code originally imported from the xthin project.
If you are interested in the Bitcoin Classic project, please look at our community page for how to get involved.
Last week I've been at the Satoshi Roundtable III, which was very effective in bringing about 100 Bitcoin interesting people together in a way that makes it very easy to productive to just sit down on one of the many sofas (or even on the beach) and talk with a number of people that share your interests.
To link to someone that is a much better writer than I am, Rick Falkvinge wrote "Overall, my assessment is that bitcoin is lacking project management".
I fully agree on that, in Bitcoin we now have different groups creating their own solutions and then trying to push them to the rest of the world, typically without actually listening to criticism, and then being surprised when the world rejects it.
I re-read a novel last month (Moving Mars) that was a science fiction where some 20 large families live on Mars as separate settlements. They started to create a new, global, government. To my surprise the process to get there was as step 1 to decide on a way to make decisions. And only after that create a constitution.
If we want to have any hope of so many smart people making progress again, we need to stop trying to skip step 1. We need to allow people to talk to each other and start the conversation on how to address the concern Rick formulated on his blog.
In Bitcoin we used to have a solution for that, the bitcoin-dev mailinglist. This has been a failed experiment with many examples of lost opportunities and even a group like Bitcoin Unlimited just refusing to use it because it is not neutral. The secondary effect is that this same group has refused to make BIPs (Bitcoin Improvement Proposal) because of the place where they are proposed and discussed is that same list they won't join.
This week I reached out to the Bitcoin Unlimited team on their slack in order to get their input on starting a new mailinglist under new management that can accomplish the goal of cross-team communication. We had some good ideas, one of them was to call it the 'post-1MB planning' list.
Specifically, what am I thinking about?
If anyone has any changes they want to make to the protocol as that affects all implementations this should have a neutral (not affiliated to any specific implementation) place where this can be discussed.
In Bitcoin we currently are having problems with the blocksize-limit of 1MB. This is a difficult topic because the parameter is part of the protocol. A "Consensus rule". What is interesting is that there currently is no bitcoin-wide document how the consensus rules are actually supposed to be changed to support Bitcoin Classic or Unlimited. This needs to change.
There is no place where people that develop a wallet or other bitcoin infrastructure can talk about consensus changes, and get familiar with what others propose.
Classic recently published its long term (5 year) plan. It would be great to be able to talk about this on a place where multiple implementations can work together so we can all makes sure we work in the same direction and avoid nasty surprises when other groups went a different (maybe better) direction!
With the modern web I've seen people suggest websites like forums to discuss this. The problem with a forum or site is that it excludes people that are not able to reach it, and it opens the risk that the operator of the site may go offline with all the history and the content.
Traditionally the best way to do this has been email lists. Thousands of projects use it successfully. I would like to suggest the best way forward is doing that again. But I'm open to better suggestions if they don't introduce any problems.
This is a question to all the software developers and organisations that want to be involved in the way that Bitcoin evolves over time, what are your requirements and what can you offer for such a platform of coordination to move Bitcoin forward?
Bitcoin: the long view.
Bitcoin is an amazing idea and has been running with great success for 8 years. It is far from perfect, though. Many issues will take time to rectify in a good and responsible manner. I want to share my longer time engineering goals for the Bitcoin full node which direct my priorities and you have been able to see some of these already in the Bitcoin Classic full node which released its 1.2 version last week.
1 Protocol documentation
Bitcoin as a whole is something we often call a protocol. But unlike most protocols, there is preciously little documentation out there that describes in detail what actually goes over the wire.
The first goal is to move towards a Bitcoin that is fully documented. The point here is that the documentation of the protocol is to be 'leading'. So if there are two implementations that disagree, the protocol-documentation is the one that is right. This avoids fluffy arguments like who has the biggest market share or who has been around longest as those somehow being more right.
2 Backwards compatibility of protocol
Parts of the current Bitcoin protocol were designed without keeping in mind industry best practices. For many parts this is not a big deal, but some those best practices were there for a very good reason. A good example is that practically all of the data structures in the Bitcoin protocol are not changeable. It is impossible to add a value to a p2p message, you can't remove an unused variable that is stored in each and every transaction.
The second goal is to move towards tagged protocol data-structures. The idea of tagged data goes back decades, well before Bitcoin was created. The point here is that we know mistakes have been made and will continue to be made by humans extending and fixing Bitcoin. For this reason we need the ability to cleanly make backwards compatible changes. Adding a new field in an existing p2p message is much cleaner than having to create an entire new message-type with all the same info, plus one item.
Note; The basic concepts of Bitcoin are sane and sound, we should not change those!
3 Access to blockchain as a database
Bitcoin as an industry depends on the blockchain as the universal database that everyone shares and uses. The main property of a database is that it can provide fast access to the information you seek. A normal database would be able to return all transactions since a certain date, as a quick example.
Unfortunately the blockchain in any full node has data-access methods that are quite primitive and very very slow, making the blockchain essentially private data. This means that block explorers end up having to re-create a full database. Research of usage patterns and many properties are limited to a few that have plenty of patience.
The third goal is to move towards a full node that provides full access to Bitcoin, including its database. The simple access of the raw data is something that can be made substantially faster and it opens the node to being much more useful for a large range of features.
This blog originated from the classic long term roadmap which has a second section going into more detail on each of those goals.
Join the Bitcoin Classic community
Do these goals align with what you are looking for in Bitcoin? Please consider joining us. Running the client, sending an email when you find a typo or simply sharing your story on reddit are great ways to start. Read the Classic community page for many more ways to join this exciting movement.
Bitcoin Classic is about 1 year old, so let’s take a quick look back.
When Bitcoin Classic was founded, our goal was to work with the established Bitcoin development teams and grow Bitcoin on-chain. The obvious and only factor we were focused on was the limit on the size of blocks. Bitcoin Classic compromised - deeply. We went for the most conservative possible increase in block size. From 1MB to 2MB.
The response we triggered, within days of the release was shocking. Several miners, developers and the BlockStream company president agreed that Bitcoin Classic was not allowed to compete with the bitcoin establishment, and they made their proclamations publicly and openly.
In the following months the implications of this action began to sink in. Those who want Bitcoin to grow to allow more users realised compromise with the establishment was a mistake. After a year of working together, compromises and peace offerings, the establishment didn't just reject all of them, it actually rejected the idea of decentralisation and open discussion.
In the latest version of Bitcoin Classic we no longer compromise. The user is at the forefront and we have listened to the many voices which, today find the system to be slow and expensive.
The solution, included in Bitcoin Classic 1.2, takes the power of setting the maximum block size away from the “establishment”, those who have shown they cannot be trusted to represent the bitcoin community.
They have shown they are not tolerant of open discussions nor educated disagreement, and these established developers have abused their first-mover position, to centralise decision making power in Bitcoin, the first decentralized P2P currency.
Power in Bitcoin is decentralized by design.
Centralized decision making is successful when people trust and support the software organization, without the need for questioning the established group of developers. However, the true power lies with all of the individual participants in the network. Only for as long as individuals keep running centralized software, using centralized services and tolerating centralized solutions will any established group have power over Bitcoin.
The solution for the block size debate is to remove the ability of software developers to set a maximum block size limit. Instead, give the power of this limit to the people. The limit can now be set by the full node operator, the exchanges, the online wallets and the home users.
Because with Bitcoin we can route around centralised decision making. Bitcoin Classic joins Bitcoin Unlimited to give people the tools to do so. People running one of these Bitcoin clients no longer have a block size limit.
But make no mistake - this is not a fight between software groups.
To be clear: because Bitcoin is decentralised in all aspects, we all decide what Bitcoin is, by running code and participating in the system. If we want to change something, we chose different code and when the collective joins you in your choice, Bitcoin changes - for the better.
Every participant makes their own choice following their own self best interest within the collective system. There is nothing in the code or system that prevents this from happening. In fact it is deeply embedded in Bitcoin as a dynamic system that evolves and grows without any centralized decision making.
You have to stand up for your opinion because nobody else can.
People like you can make their voice heard by doing something as simple as running Bitcoin Classic. You can also find other ways to make your voice heard by writing to companies that are undecided and explain your position or simply link to this text.
Bitcoin Classic works for the people, and if people act to maintain Bitcoin as a decentralized project, the best will happen.
As we near the closing of 2016 (year of the Monkey) there is a growing awareness on how we can solve the question of block size limits for many years to come. Please see here for an overview of this.
The idea is that we can move from a centrally dictated limit to one where the various market participants can again set the size in an open manner. The benefit is clear, we remove any chance of non-market participants having control over something as influential as the block size.
A good way to look at this is that the only ones that can now decide on the size are the ones that have invested significant value, believing in an outcome that is best for Bitcoin as a whole.
The credit goes to Andrew Stone for coming up with this concept of building consensus. He also published another, intertwined, idea which is the Acceptable Depth (AD) concept.
If the open market for block sizes is still making people uncomfortable, the AD concept is causing pain. The concept has had many detractors and the way to handle complaints and attack-scenarios has been to add more complexity to it. The introduction of something called the "sticky gate" that was created with no peer feedback is a good example as there is now an official request created by stakeholders which asks for it to be removed again. The result of that request was for the author to not remove it, but suggest yet more complexity.
I really like the initial idea where the market decides on the block size. This is implemented in Bitcoin Classic and I fully support it.
The additional idea of "Acceptable Depth (AD)" was having too many problems so I set out to find a different solution. This part of Andrew's solution is not a consensus parameter. Any client can have their own solution without harming compatibility between clients.
What is the problem?
In the Bitcoin reality where any full node can determine the blocksize limits we expect a slowly growing block size based on how many people are creating fee-paying transactions.
A user running a full node may have left his block size limit a little below the size that miners currently create. If such a larger-than-limit block comes in, it will be rejected. Any blocks extending that chain will also be rejected and this means the node will not recover until the user adjusts the size limits configuration.
It would be preferable to have a slightly more flexible view of consensus where we still punish blocks that are outside one of our limits, but not to the extend that we reject reality if the miners disagree with us. Or, in other words, we honour that the miners decide the block size.
In the original "AD" suggestion this was done by simply suggesting we need 5 blocks on a chain when the first is over our limits. After that amount of blocks has been seen to extend the too-big one, we have to accept that the rest of the world disagrees with our limits.
This causes a number of issues;
- It ignores the actual size of the violating block. It is treated the same if its 1 byte too large or if its various megabytes too large. This opens up attacks from malicious miners.
- There is no history kept of violating blocks. We look at individual violating blocks in isolation, making bypassing the rules easier.
Solving it simpler
Here I propose an much simpler solution that I have been researching for a month and to better understand the effects I wrote a simulation application to see the effect of many different scenarios.
I introduce two rules;
Any block violating local limits needs at least one block on top before it can be added to the chain.
Calculate a punishment-score based on how much this block violates our limits. The more a block goes over our limit, the higher the punishment.
How does this work?
In Bitcoin any block already has a score (GetBockProof()). This score is based on the amount of work that went into the creation of the block. We additionally add all the blocks scores to get a chain-score.
This is how Bitcoin currently decides which chain is the main chain: the one with the highest chain-score.
Should a block come in that is over our block size limit, we calculate a punishment. The punishment is a multiplier against the proof of work of that block. A block that is 10% over the limit gets a punishment score of 1.5. The effect of adding this block to a chain is that it adds the blocks POW, then subtracts 1.5 times that again from the chain. With the result that the addition of this block removes 50% of the latest blocks proof of work value from that chain.
The node will thus take as the 'main' chain-tip the block from before the oversized one was added. But in this example, if a miner appends 1 correct block on top of this oversized one, that will again be the main chain.
Should a block come in that is much more over size limit, the amount of blocks miners have to build on top of it before the large block is accepted is much larger. A 50% over limit block takes additional 6 blocks.
The effect of this idea can be explained simply;
First, we make the system more analogue instead of black/white. A node that has to chose between two blocks that are both oversized means we choose the smallest one.
Second, we can make the system much more responsive where a block that only violates our rules a tiny little bit at height N and then if some other miner adds a block N+1, this means we can continue mining already at block N+2. On the other hand, an excessive block takes various more blocks on top of it to get accepted by us. So its still safe.
Last, we remove any attack vectors where the attacker creates good blocks to mask the bad ones. This is no longer possible because the negative score that a too big block creates will stay with this chain.
This proposal is about a node recovering when consensus has not been reached. So I feel OK about introducing some magic numbers and a curve that practice shows a good result in various use-cases. This can always be changed in a later update because this is a node-local decision.
On the horizontal axis we have the block size. If the size is below our limit, there is no punishment. As soon as it gets over the block limit, there is a jump and we institute a punishment of 50%. This means that it only adds 50% of the proof-of-work score of the new block.
If the block size goes more over limit, this punishment grows very fast taking 6 blocks to accept a block that is 150% of our configured block size limit.
The punishment is based on a percentage of the block size limit itself,
which ensures this scales up nicely when Bitcoin grows its acceptable block
size. For example a 2.2MB block on a 2MB limit is 10% punishment. We add a
factor and an offset making the formula a simple
factor * punishment +
factor shown in the graph is 10, but this is something that
user can override should the network need this.
Using a simple-to-calculate punishment and the knowledge that Bitcoin already calculates a score for the chain based on the proof-of-work of each block, we can create a small and simple way to find out how much the rest of the world disagrees with our local world-view. In analogue, real world measurements.
Nodes can treat the size limits as a soft limit which can be overruled by mining hash power adding more proof of work to a chain. The larger the difference in block size and limit, the more proof of work it takes.
Miners will try to mine more correct chains, inside of the limits, fixing the problem over time, but won't waste too much hash power pushing out one slightly oversized block in a chain.
This is not meant as a permanent solution for nodes, and full node operators are not excused from updating their limits. On the other hand a node that is not maintained regularly will still be following Bitcoin, but it will trail behind the main chain by a block.
Currently we only have block-size as a relevant variable. If we add more variables that are taken out of the consensus rules and made market-set, we can decide or make configurable a proportional system. So, for instance, if we add sigop counts, those violations may only count for 30% of the punishment whereas blocksize overdraft account for 70% of the punishment. The actual punishment is still based on the actual overdraft in an analogue (super) linear fashion.
Bitcoin Classic was started as a response to the market need for bigger blocks and an alternative developer group to provide it, as primary and first way to get Bitcoin to scale to the next million. Since that first release in February we have come a long way. The Bitcoin landscape has changed, and mostly for the better. This is an accomplishment a lot of us can be proud of.
Our two main goals were to have more distributed development and to have bigger blocks. We are a lot closer to both ideals, but there is more work to be done.
I personally started this journey some 3 years ago. I tried the code that was Bitcoin Core and wanted to improve upon some things that annoyed me. Now 3 years later I have seen every file and most of the code of what is in Bitcoin. It is a very rewarding problem to study and can occupie one for years.
My primary role in Bitcoin Classic is one of release manager. This essentially means I take the responsibility to get the highest quality releases. Next to that I love to innovate and write code. I've been doing a lot of that over the last months.
So, why title this blog "Classic is back"? The truth is, it never really went away. I think its fair to say that Classic stepped aside when the 2MB band-aid solution we shipped caused a lot of market response and discussion. But Classic has always been there. Busy, coding, improving things.
One of the changes we have seen in the market is a change in understanding
how all Bitcoin software can work together. This idea has been used many
times before, so has stood the test of time already. It is about how we can
have a limit without setting a limit in the software.
All software, when it is immature and only targets a small amount of users, has limits build in. These limits are really there because the author learned that his software is not good enough to do more and a limit is by far the easiest 'solution'.
This design isn't uncommon, the older ones among us may remember that Ms DOS had a memory size of 640kB. Emails 20 years ago had a maximum size of 1MB.
As part of growing up of that software; better solutions were found that made those limits obsolete. The limits were removed and people were happy.
Removing of the limits in software doesn't make them unlimited. It just makes other costs limit the actual size. You still can't send a DVD sized email. The maximum size now is determined by the market. A basic calculation of cost and benefit.
Lets take a look at some market incentives that a Bitcoin Miner has;
- A miner mining bigger blocks are nice because he gets to pick up more fees.
- On the other hand smaller blocks are nice to keep a bit of scarcity and have people still paying fees.
- Also, bigger blocks cost more time to send and make the chance of orphans higher, both of which are costly.
- And on the other hand, smaller blocks cause a bigger backlog and as a natural result, bad service to paying customers. We want to avoid losing them to the competition.
These are conflicting incentives. There are both reasons for bigger and there are reasons for smaller blocks. The end result will be, that blocks will have a size set based on the market demand for space in those blocks. Simply because that is the most profitable for miners to do. The good thing here is that the best situation for miners is a pretty good situation for everyone else in Bitcoin as well.
What Andrew Stone came up with is that everyone publishes the maximum size they are willing to accept and this makes the market of block sizes become an open market. Now miners can decide what the ideal block size is, without fearing that their blocks will be rejected by other miners for being too large.
A purely market driven block size is a big change for Bitcoin and it may take a bit more time before everyone gets used to it, and in the mean time Classic is working on several next-generation projects.
Network manager / Admin server
In Classic I started a project that is the Network Manager, a replacement network layer which solves many of the problems we have with the p2p code we have inherited from the Satoshi client. On top of this is currently being build an admin server. The admin server will fill the role of remote control. You can create transactions, query the block chain, sign data and ask it to make coffee. All but the last are already present and this admin server just uses that existing functionality from the 'Bitcoin-cli' app.
The place where it shines is that the speed is various magnitudes faster and it allows not just asking questions like a webserver, but the admin server has a live connection and it pushes out data. For instance when a new block comes in.
So it enabled a new set of network enabled tools that can be created with it. Some examples where its going to be used are; * Application management software which monitors any number of nodes under its control for warnings and slowness. But also for operational statistics, like how many mega-bytes have been sent. * Scientific research to query the entire blockchain without having to store it locally. * much faster uploads of big blocks from a miner to the full node.
This project is nearing 80% completion. Is Classic back on track?
Flexible Transactions (BIP134)
In the original Bitcoin 0.1 release Satoshi Nakamoto included a design that is a very good indication of his intentions for the future. He included a version field for transactions. Today, 8 years after the fact, we are still using the exact same format that was introduced as version 1 all those years ago. We are not really using this version field that Satoshi provided.
There are plenty of problems we have in Bitcoins design which would benefit immensely from actually being able to make fixes in the transaction format. And flexible transactions is a protocol upgrade that is meant to make that happen.
The Flexible Transaction proposal has been under development for a couple of months now and we currently solve quite a lot of issues in this first version.
Fixes Bitcoin issues;
- Linear scaling of signature checking
- Hardware wallet support (proofs)
- Very flexible future extensibility
- Double spend proofs
- Makes transactions smaller
- Supports the Lightning Network
- Support future Scripting version increase
Where are we now?
Flexible Transactions is running on a testnet. The functionality is 80% done. We have some more tests to run.
Bitcoin Classic is definitely back.
Bitcoin Classic is based on the 8 years old Satoshi codebase, I myself have been spending more time than expected learning this codebase and I know from other developers I'm definitely not alone. The codebase is not even that large! The most often heard complaint is that that it lacks a modular design.
Hard to understand code leads to lower quality products. This is very simple to understand: programmers are just human and they make mistakes when they have to create clean code in a dirty environment. I think it makes a lot of sense to have a focus on improving the architecture and the code quality of Bitcoin Classic. The goal is to help developers understand the code faster and at the same time help our products to be of higher quality.
Because there is such a lack of modular design, the best way to start fixing this is to introduce this modular design. Basics like an "Application" class as a starting point for application-wide resources have been coded and more is coming.
The various products I mentioned today are also all based on common and reusable technologies. The introduction of a common message-format will be the common layer between the Flexible Transactions and the Network Manager and the Admin Server, as a quick example.
I feel its very important to work on all these improvements together with other teams that are part of Bitcoin. They have their own improvements and in the end we want to reuse each others innovations and, ultimately, code. I have had many good conversations with people like Pedro Pinheiro, Dagur Valberg Johansson (dagurval), Amaury Sechet (deadalNix), Andrea Suisani (sickpig), Freetrader and Justus Ranvier whom are great people to work with and cover the majority of the Bitcoin implementations. There is a lot of overlap in what we do and how we think.
The important part is the differences. Each Bitcoin Client is unique in its own way and this is useful for everyone. This helps to avoid the echo-chamber problem and we avoid killing ideas that are before their time. More people competing on a friendly basis will benefit everyone and that is what it means to have many implementations of Bitcoin.
Bitcoin Classic is back. Bitcoin Classic is working on some pretty exciting things and we have all come a long way.