Last week an update to Bitcoin Core was released, version 0.16.2 is a minor upgrade that includes a few bug fixes and new translation, some updates include displaying messages as texts rather than HTML and a few RPC bugs.

To upgrade you can download the new client from here. Shut down your current client, run the installer on Windows or copy ‘bitcoind’/‘bitcoin-qt’ on Linux and remember that wallets created in 0.16 and later are not compatible with previous versions, so don’t try to import a new wallet into an old one if you want to downgrade later. You can always register on the BitcoinCore’s website for security and update notifications to keep up!

In a previous article we talked about the Alert key retirement plan, the retirement plan originally included releasing the private key to the public but this was only done recently. Any node running Bitcoin 0.12.x or more should have the alert system disable, while this is an ancient version of Bitcoin, about 4% of the current network is still vulnerable.

This made the Bitcoin Core developers create a final alert that overrides any previous alert and shows a warning message to all vulnerable nodes for wich an update is required. Unfortunately this didn’t turn out to be an optimal solution as this alert itself can be cancelled if another alert was to arrive at the node first. There were also fears that some Altcoins could still have the Alert system integrated into their code as a lot of them are just Bitcoin forks, upon further investigation it was found that only a small amount of altcoins on github are vulnerable, and almost all of them are abandoned anyway. Bitcoin developers also offered Altcoin developers a patch that can fix most issues regarding the Alert System, if they still wish to use it in their coins.

The Bitcoin community has been recently talking about disclosing the Alert Key, a system that was used by Satoshi Nakamoto in the starting days of Bitcoin as a network wide alert for important updates and network events, but as the developer circle of Bitcoin increased it was noticed that this system was a source of centralization as holders of the alert key can use it at any time to send out dangerous alerts that could disrupt the whole network.

The Alert system was deprecated in late 2016 with the release of bitcoin 0.12.1+ but the Alert key was never disclosed, this Alert system may still be used on different Altcoins forked from Bitcoin and so there was a call to all developers to immediately deprecate the system if it wasn’t already.

Decentralizing mining doesn’t always take the form of an algorithm change.

Matt Corallo linked the following Bitcoin Improvement Protocol called BetterHash.

We propose two new mining protocols to rethink the way in which work is generated in the Bitcoin network, potentially drastically increasing effective mining decentralization.

An issue was raised by Andreas Schildbach via bitcoin-dev regarding compatibility issues between segwit and BIP37: Bloom Filtering:

The issue affects only P2WPKH and the special case of transactions without change outputs (such as when emptying a wallet). In this case, neither inputs not outputs contain any data elements that would cause a match for the filter. The public key, which would match, goes to the witness but not to the input.

Read the full thread

Jim Posen proposed the following BIP (Bitcoin Improvement Protocol) via Bitcoin developer mail:

I have been working on a P2P extension that will allow faster header sync mechanisms. The one-sentence summary is that by encoding headers more efficiently (eg. omitting prev_hash) and downloading evenly spaced checkpoints throughout history (say every 1,000th) from all peers first, we could speed up header sync, which would be a huge improvement for light clients.

According to Posen, the “proposed header download protocol reduces bandwidth usage by [approximately] 40%-50% and supports downloading… from multiple peers in parallel”. Currently parallel header synchronization is not supported. Such an improvement could be advantageous during periods of high technical adoption, which could occur as increasingly stable versions of Lighting Network daemons are released.

Luke Dashjr opened a discussion regarding why Bech32 was omitted from previous P2SH² improvements.

For those unfamiliar with the concept, the idea is to have the address include the single SHA256 hash of the public key or script, rather than RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would then perform the second hash to produce the output. Doing this would in the future enable relaying the “middle-hash” as a way to prove the final hash is in fact a hash itself, thereby proving it is not embedded data spam.

Bech32 seems like a huge missed opportunity to add this, since everyone will probably be upgrading to it at some point.