Toms Blog

Where I talk about Bitcoin and Technology

I want a 21st century lock

The earliest known usage of a lock and key, such as used to bar entry to buildings, is about 2500 years ago. The idea of locks has been based on a simple idea for all this time. The lock has a secret combination, technique or just positioning of tumblers and the only one allowed access is the one that knows the secret.

There is a fascinating story behind the arms race of the people building safes and the people cracking them leading to heavier and more complex safes. Lots of ingenuity for geeks to find there. But that is a story for someone else to tell. I'll focus just on the locks themselves.

The secret of how to unlock a normal door, in most modern locks, is plainly exposed in the key and as such we see that more secure buildings solve the problem by law. They patented the key and make sure that the key creation is itself a privilege. So you can see the keys design and thus its secret, but you can't open the door because the piece of metal that is the key can't legally be created without permission.

Its been some years since 3D printers became cheap enough to be considered mainstream. People can print any plastic object with zero government oversight and with zero accountability.

The direct consequence is that pretty much all locks can be cracked by just having a smart solution to take a couple of photos of any key and then using some smart software that turns it into a 3d model and prints it.

As such I conclude that most common locks (excluding the safes mentioned above) work on the idea that the owner has a secret, in the form of a specially crafted key, that is the only thing that can unlock the door. The flaw, as such, is that the shape of a key is rather easy to steal. A couple of pictures or a piece of gum can be enough.

Crypto locks

If we look at cryptography, the kind that Bitcoin Cash uses, we see some opportunities for improvement. The basic cryptographic concept of public/private key-pair is used.

The owner of a key can have a private key and the lock has the public key. I can simply sign a message with my private key and the lock can validate this using the public key as proof that I actually own the private key.

The basic advantage of using public/private key cryptography is that the "secret", in the form of the private key, will never be made visible to anyone and even by borrowing the physical key-card attackers can not copy this secret.

In 2009 Satoshi Nakamoto shared the idea of a chain of signatures in his Bitcoin whitepaper and we can reuse this idea to allow users to transfer ownership of a lock. A lock could have a factory set crypto-key installed which can hardly be called secure in a mass production environment. When I buy the lock I then provide my own key-pair of a public-private key.

The current owner (the salesman) creates a signed transfer of ownership record to my key-pair. Since I make my own key-pair, this is completely private and secure. If I were to sell the lock on, I'd be expected to create a signed transfer of ownership record as well that stops me having access and instead gives access to the new owner.

This results in a chain of ownership transactions. Each of them signed by the previous owner and in that transaction a new owner has his data encoded. Exactly like transactions in Bitcoin Cash.

The "key" can be an implementation on a phone, or a specially created card with a chip. The action of authenticating to the lock would then be using something like Bluetooth and NFC.

The "lock" is a very simple computer capable of creating cryptographic challenges and validating the result. It would also store and be able to process the entire chain of transactions from its birth to the current owner.

After the lock is sold to a new owner, the new owner should try to open the lock. The lock poses a challenge (current data/time for instance) to the key and the key detects that the pub-key-hash requested by the lock is old and the key will respond with a transfer of ownership transaction. The lock can validate that one to be proper and correct and then update its internal memory. Effectively changing ownership.

Immediately after the lock did this update it can challenge the key with a new time stamp and the new updated pkh it now thinks is its owner.


As most locks go, the above setup is more than enough security. The lock is very low complexity and does as much with crypto that most existing locks do. It will be significantly more secure than most locks and with some simple API extension you can have multiple keys open a door. All controlled by the owner.

However, for ownership that is not a door-lock, this may not be enough. We may want to actually store the transfer of ownership records on the public global block chain. Many have speculated that this implies that the 'lock' computer needs to be connected to the internet. Spawning an "internet of things" hype that seems to just turn into a consumer-data revealing nightmare. We don't want to make locks or simple household things connect to the internet if we value our privacy.

How do we solve this then?

In the previous part I described how the key is the one that takes the burden of proof to convince the lock of the new world state. The "key" is a smart-card or a phone of some sort.

As long as we are willing to physically go to the lock in question and update it whenever there is a change of ownership we can extend this concept quite simply and avoid the dreaded double-spend problem. Because if I sell the lock to two people at the same time, the one that actually gets it in the default scenario is the one that actually physically gets to the lock first.

Again, this is likely good enough for the vast majority of locks, but for things like cars or houses this may not be enough. A good solution for such special locks is to enforce the transfer of lock ownership to be mined on the Bitcoin Cash Blockchain. Bitcoin mining exists primarily to solve the double-spend problem, how about we just hitch a ride and get the same benefit?

To execute this sale the car owner creates a Bitcoin transaction paying a tiny fee from the private-key that is currently the owner of the lock and it also sends a large sum of money he wants as payment for his car to a bitcoin address he owns. He signs it as "anyone-can-pay". This transaction itself is not valid as it spends more than he pays.

The buyer of the car receives the transaction and adds his own money to it as a way to pay the seller and most importantly he transfers a small amount to an address that is to represent the new owner. This last address will be the one the lock on the car will accept to open it. After signing the transaction it can be mined on the Bitcoin Cash blockchain.

The new owner needs to download a couple of things on his smartphone or smartkey before he can open the car lock. He needs to download the missing block-headers (at 80 bytes each) and indeed the actual transaction that transferred the ownership. Last he needs to download the merkle-proof that proves the transaction was actually in the block. If that sounds too technical, just skip over it or google for details, it is a well known way to provide proofs.

In our futuristic story the car is self driving and after the sale succeeded the old owner tells it to drive to the new owner. As the car arrives it parks itself in the driveway of the new owner and at this point the car is not yet aware of the sale and it would only start for the old owner.

The new owner simply holds his smart card "key" to the car door and the car will not just receive the transaction of car ownership, it will also request from the key-card, and validate, the entire list of block-headers since the last header it knew about. Which is likely when it last got sold.

Validating the new ownership is then essentially the same as any Simplified Payment Verification (SPV) Bitcoin Cash wallet does. With the big difference that it only needs to do it once when there actually is a new owner and the burden of proof is on the new owner.

Additional access and associated features

The first thing that came up when I explained this to others is how you would allow 3rd parties to open the door. Or how you rent out a car and thus give access for a day or a week.

The ideas described in this article are only talking about ownership, specifically how one specific private key can be used to proof ownership.

It is rather easy to imagine a protocol of signed messages send by the owner to the lock to allow additional private keys to be allowed to open the door, without transferring ownership. None of this has to be mined on a blockchain, none of these messages even have to be properly formatted Bitcoin transactions. It is just a simple API where the instructions are signed by the owner using his private key.


The technology for doing this properly has been around for a long time. Unfortunately Cryptography is something that seems to scare people and the TV isn't doing us any favours where many popular programs make anything computer based sound less secure than our current situation. This is double unfortunate as the reality is exactly the opposite. Big government 3 letter agencies don't like cryptography because they can't break it.

The idea is likely to be much more friendly and secure when designed properly. For instance I can grant access to visitors of my house without fearing they will make a copy of the key and thus I have no risk of them getting access again after the timeout expired.

This idea is based on basic cryptographic concepts, public/private keys and hashes. No blockchain is needed for the vast majority (95%+) of the cases.

I personally have no resources to build this, but I've been talking about this approach for a long time, as anyone close to me knows, and at least on the software side this approach is sane. I would be very happy to support a kickstarter that makes this a reality.

Read full...

Dear Bitcoin Cash: Good news, Fees Will not Rise

In a recent unparalleled action, Blockstream employee and thus Bitcoin core dev Rusty Russel admitted that in their strategy Bitcoin fees, unlike Bitcoin Cash fees, will continue to rise.

Bitcoin Cash, or to be more honest, Bitcoin-as-originally-designed is a decentralised system. To really know if a transaction is valid you need to know every transaction that fed into it is valid. You can always retrace a chain of transactions to the point where the coins were originally mined.
To know if the system is working you need to know nobody is faking money out of thin air, and that nobody is simply stealing money from others. To get this level of confidence, you need your own computer to check everything, and so it needs to see everything. This sounds scary, but it actually scales amazingly well.

We see that the software already today can scale to 100 million transactions per day, on a modern machine that any business can own. The capacity of Bitcoin Cash is mostly limited by blocksize, a shackle we shook off just this month and we can see many more ways to help scaling on its way. We will need more serious scaling to on-board more users, and we will see this being added over the next few years as the network of Bitcoin Cash-using people grows. The capacity will scale based on need. Much like it has in all major innovations in the past.

We currently have a blockchain of 0.1TB, which represents 8 years of history. It can be validated on a simple machine in about 2 hours. Hard drives come in 4TB or larger. So the 2.5% you need for the blockchain won't even get noticed.

  • Bitcoin Cash fees will stay the same, or go down from now on. Count on it.

  • Zero-fee transactions will make a comeback.

  • Zero-confirmation transactions that we need to do standard merchant payments will again reach the levels of risk low enough to allow stores to accept in-person Bitcoin Cash payments.

  • We are free of the over complex SegWit that Rusty admits doesn't actually help scaling. To not have it speeds up development and increases reliability of the network.

  • Block size of Bitcoin Cash is limited at 8MB. We will work to make it safe to scale up higher without affecting decentralisation.

  • Features like Schnorr are nice, but they don't have any relation to scaling. We will see them on Bitcoin Cash soon enough.

Back then Satoshi stated that there is no limit to the growth. Transactions are tiny and a modern computer can process tens of thousands a second. We are seeing that the number of what we can process increases exponentially. Bitcoin Cash scales, it really does.

Read full...

Bitcoin Cash Migration Strategy

The last week has been very wild, very long days and great code being churned out. Sometimes the unit tests objected to that latter part, but all is fine again today.

After shipping Bitcoin Classic 1.3.0 and 1.3.1 with substantial changes in each, please notice the 1.3.2 release is just out.

This finalizes the features needed in the short term for migrating people from the current state to the state where there are two coins.

side note; I use "BCC", "Bitcoin Cash", "UAHF" all to mean the same thing in this post.

In Bitcoin Classic I added the following features;

dual network-magic

Bitcoin identifies other nodes based on a big number we call "magic". If a node doesn't agree on this magic number, we refuse to talk to it. The idea originally came from deadalnix, and the ABC client will soon ship this too. The idea is that if a node is on the BCC chain, it uses a different magic number for communication. That way we will make it much easier to avoid talking to nodes that are not actually following the same chain.

For now clients are flexible and accept either the old or the new magic number. In other words, they talk to anyone. In days or weeks we may have enough nodes that support this new magic number and it may be more useful to stop accepting connections from old nodes. As that saves network traffic.

In Classic I added -flexiblehandshake, which defaults to true. Set it to false and we stop accepting old nodes connecting to us.
Reversely, I added -initiatecashconnections which uses the new magic, set this to true if you want to avoid talking to old node.


When running BItcoin Classic on the BCC chain, and blocks come in, this would update the unspent transaction database (UTXO). And you would no longer be able to use that database to follow the segWit2x chain.

The obvious solution is that you need two data-directories. One for each chain. And many people do exactly that.

The problem with this is the 120GB or so of historical blocks. It would be really nice if we could avoid duplicating that.

In Bitcoin Classic I introduced an argument you can add to your config file called blocksdatadir. What that allows is you can lists one (or more) directories Classic will look for historical-blocks. (more).

Automated migration.

In Bitcoin Classic 1.3.3 (not yet released) the first time you start your UAHF (aka Bitcoin Cash) version of Classic it will automate this separation. Allowing you to install two versions of Classic and thus access two chains without issues.


The most commonly asked question is if people can run two clients at the same time on the same machine. And the answer is yes. Yes you can.

The only thing is that you need to pick one that is listening for incoming connections. Because two listening on the same port is not possible. As such, you can open your bitcoin.conf (location) file and add listen=0 on the segwit one and you will be able to start two at the same time.

Happy Bitcoining!

Read full...

Bitcoin Classic and the User-Activated-Hardfork (UAHF)

中文 (Chinese translation)

Over the last month we have seen an accelerated amount of effort being put into finally fixing the problems that have been bothering real users for months now. As the dust is not nearly ready to settle, we can at least make out the terrain and the big players.

What many have been expecting is playing out before our eyes. We are going to see a divorce and two chains will continue their own ways. It does not help anyone to go over the history of how we got here, it just matters that there is too much fighting and sleepless nights on all sides. The end result has been becoming more and more clear to everyone close enough, Bitcoin as a whole will lose everything if we can't move forward.

When the developers and self-appointed experts can't decide on which product to put in the market, we should not stall all progress but instead bring both of them on the market and let the people vote with their money. Let the market decide. In the long term the open market always is the wisest of us all.

For me the math is simple, if we get 5x the amount of paying customers in a year, then the SegWit chain can't support them, which will be a horrible experience due to long waiting times again. So the greatest growth, and the highest prices, are going to be on the chain that has its ducks in a row and allows for scaling in the short term.

Based on this, the most interesting solution we observed is the UAHF. Which is short for User-Activated Hardfork. I want to share my findings on how this one works here;

The chain-fork activates on a specified date. Set to 2017-08-01 12:20:00 GMT

Miners that switched to mining this will follow the current chain up until that point, but diverge after this time.

Major features are;

  • First block (one block) has to be larger than 1 MB.
    This definitively marks the chain-split and old clients won't follow it so we cause minimal disruption. Similarly, we avoid many problems with regards to attacks by other hashpower. Once this block is mined, we are following the updated rules, nothing can be done to change that.

  • Block-size limit is enlarged.
    We get a large breath of fresh air. The limit of 1 MB is removed and miners will mine up to 2 MB blocks. We allow for future growth without additional protocol upgrades until 8 MB.

  • Optional Bi-directional Replay protection.
    When the chain-split happens normal transactions created on one chain will be valid on "the other chain". This is an issue for people that want to trade between those chains or simply want to avoid a transaction on one chain to be valid on another.
    Software will need to be updated to support sending and receiving those special transactions. Normal transactions work fine in all existing chains.

  • Transactions can opt-in to use a more secure way to sign transactions. Without making transactions larger, more information is being used in the creation of the signature which will allow a number of new features immediately. These include malleability fixes, hardware wallet security and replay-protection.

Bitcoin Classic will support the UAHF chain with a special release soon.

Read full...

Quadratic Hashing

Quadratic scaling of hashing time


In Bitcoin a transaction moves money from one address to another and in order to only allow the actual owner of money the ability to move this, we use cryptographic signatures.

An owner of a Bitcoin address can only spend money by adding a cryptographic signature to a transaction that spends it. The act of adding a cryptographic signature includes the hashing of the entire transaction. As such the size of the transaction matters to the speed of this signing, as well as the validation of said signature.

There is a design flaw in Transactions v1, as Satoshi created it, which can lead to the validation of signatures taking longer than expected.

The problem we see is the basic choice Satoshi made about what it means to sign a transaction. The problem is that each signature signs a slightly different version of the entire transaction. And this means that should you have 10 signatures, this means you need to hash the entire transaction 10 times to sign it. People validating those transactions similarly need to hash the entire transaction 10 times, with minor differences between each run.

A natural consequence of this is that adding another input and associated signatures will cause another read and hashing of the transaction. But at the same time it will make the transaction larger and as such make all the existing signature checks take longer.
This makes the amount of work validation takes grow quadratic.


The actual checking of signatures is incredibly fast. The largest transaction ever mined on mainnet was in block 364292 as reported on reddit.

This will most likely stay the largest transaction based on the protocol limit of 1MB for transactions. Even if we change the block size limits, the transaction size limits (at least for old style transactions) stays.

As such we can conclude this flaw in the design is not really an issue that can be exploited to cripple or somehow cause problems with the network. This is illustrated by the fact that this huge transaction on today's hardware takes 5.5 seconds to validate. On future hardware this will be even faster, and software will likely speed up as well.

Worst case scenario

Some years ago Bitcoin researcher Sergio Demian Lerner posted about the worst case scenario. This setup is 100% meant to exploit the flaw. In a normal usage of Bitcoin this construction has no meaning. The post describes that with the maximum of a 1MB transaction we can end up hashing that one megabyte 19,100 times.

Larger transactions are not allowed, even with larger blocks. This is about the maximum validation time we can reach under attack circumstances.

A simple solution to this worst case scenario is to cache the output of the hashing function. With that the amount of times we actually hash the transaction goes down to less than 100 times.

How does Flexible Transactions solve this?

To be clear, the issue is something we may call solved for all regular purposes. Specifically, there is no danger of people abusing the system to cause a slow down. And this is what most people care about.

It is however still important to address the underlying cause and fix this. We currently have a 1MB transaction limit, and we may want to lift that limit in the future without having to worry about the scaling issue again.

The solution in Flexible Transactions is rather simple and elegant, we replaced repeated hashing of the entire transaction with using the transaction-ID as the basis of signing.
This means that the size of the transaction no longer is relevant and we only need to calculate the transaction-ID (txid) once, regardless of the amount of inputs.

Using the method of hashing against a fixed TXID permanently solves both issues of quadratic hashing attacks and transaction malleability.

Read full...

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