Toms Blog

Where I talk about Bitcoin and Technology

Who Wants SegWit?

In Bitcoin the one thing that is still being discussed quite a lot it is Segregated Witness, the hot technology that the people from Bitcoin Core announced to the world in December 2015.

As the months go by and the realisation starts to set in that there is no way that the 25% miner support it currently has will get turned into the required 95%, we have to take a step back and think. Who wants SegWit?

Talking to companies and people there are a couple of reasons that people want to see SegWit activated, the most important ones are these;

  • SegWit is seen as the "first" step, its activation is required to proceed with Bitcoin innovation.

The question we should ask is; Do we need SegWit for innovative technologies like Schnorr, Lightning and Parallel validation and many others?
And the answer is, no, SegWit is not required for any of those.

  • SegWit fixes various problems in the protocol and those fixes help to scale Bitcoin.

SegWit has a lot of good ideas, but its implementation approach has made it tainted and over-complex. This together with the fact that Flexible Transactions is finished and does all that SegWit does, but much much simpler is the main reason that SegWit will never activate.

This is is not bad for Bitcoin as it will still get its malleability fix, this is only sad for the team that has worked on SegWit project for so long and didn't get much return on investment.

In Bitcoin, like any mature project, we have to prioritise projects one by one and roll them out safely. This means these important issues will get fixed, the question is purely one of priorities.
To be clear, nobody is saying we should not get the malleability issue fixed, it is just not the priority for this year.

And as I have been saying more often recently, the main way to get malleability fixed is to help get the block size issue resolved so we can get to the next item on the priority list.

Read full...

Layout of my blog

Yesterday I finally sat down and gave the blog a small make-over. It is loosely based on a theme made by mattgraham, and all bugs that occurred due to my changes are certainly introduced by me.

This layout has several advantages over the previous one, the main advantage is that the content now is readable on mobile devices as the layout auto-adjusts for different form factors.

Some more Javascript based features were added, which will help usability. For instance the chapters appear to the left of the main column for longer stories. I try to keep the balance that Javascript is never required to view a page as there are still many security conscious people in Bitcoin that browse without it.

Hope you enjoy!

Read full...


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.

Read full...


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.

more on 8btc, translation here.

SegWit is too many changes in one go, one of them is that it tries to fix transaction-malleability. 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.

Read full...

What is new in Bitcoin Classic (2017/02/20)

This post will answer what happened in Bitcoin Classic since the last report

New stuff

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.

Pull requests; 225 226 227 228

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 commit.

Tom Zander added a new feature for Flexible Transactions called -ft-strict. The commit message reads:

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 noticed a potential bug, or at least a bad design in the usage of the assert command. This is better explained in the resulting 'Junior Job' issue. The fix is in 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.

GUI (Qt)

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 hi-DPI displays commit.


New contributor Benjamin Arntzen created a PR to fix some text which ended up being applied. also to the website as well.

Tom Zander imported the historical release notes on the website;

If you are interested in the Bitcoin Classic project, please look at our community page for how to get involved.

Read full...


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.

Read full...

What is new in Bitcoin Classic (2017/01/30)

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.

There have been two similar posts in another forum before: 10-jan & 18-Jan.

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 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.

Read full...

Governance Starts Somewhere

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?

Read full...


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.

Read full...

Bitcoin is Made by People

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.

Read full...