Feed for category: core
Bitcoin Core 0.17.0 release candidate 3 available

This is a release candidate for a new minor release and the preliminary release notes can be found here. Users are welcome to make tests and report problems to ensure the quality of the final release.

The following changes have been made since rc2.

  • Add descriptor reference documentation.
  • test: Add test for config file parsing errors.
  • util: Report parse errors in configuration file
  • docx: Change documentation form =0 for non-boolean options
  • fix walletcreatefundedpsbt derive paths, add test
  • Use assert when running from multithreaded code as BOOST_CHECK_* are not thread safe
  • qa: Stop txindex thread before calling destructor
  • docx: Fix help message typo options -> optional

The binaries for Bitcoin Core version 0.17.0rc3 is now available here. The source code can also be found on Github.

Testnet3 Reset

A Testnet is an alternative Bitcoin Blockchain that is mostly used by developers to test their code, test edge case transactions and other development related subjects, the testnet is currently 1412193 blocks long and takes about 2 days to fully sync.

This caused some conversation on the bitcoin-dev mailing list calling for a reset of the testnet to make it sync faster and use less disk data, while some developers called for this, others actually called for a larger blockchain compared to the mainnet to find size-related errors. Developers like Jimmy Song and Johnson lau called for the existence of two testnets, one small and one large.

A Change to the MERKLEBLOCK command to protect from Leaf-Node weakness

We covered recently the Leaf-Node weakness and the different proposals that were discussed to address it.

Sergio Demian Lerner, from the RSK team and one of the participants in the discussion, went on presenting his idea for a new fix on his blog.

Recently a fix to the Bitcoin Merkle tree design weakness in the RSK’s bridge was built by making invalid SPV proofs whose internal hashes are valid Bitcoin transaction. While this solves the problem, it is by no means a “clean” solution: it creates false-negative cases (with very low probability) and it reduces verification efficiency.

Claiming an OP_RETURN prefix

OP_RETURN code has some interesting, but highly controversial, applications. It’s used to mark a transaction output as invalid, allowing users to burn bitcoin, its also used to add some data to a transaction or store data on the blockchain, which you shouldn’t do.

Some use OP_RETURN prefixes as a way of confirming that they are behind this transaction, using colored coins or storing data.

Recently there were discussions on how to claim these OP prefixes but some members of the community thought it was a bad idea as it would allow censorship and reduce anonymity.

This relates to an old BIP from 2016, but work on this BIP is still in progress.

Bitcoin Core 0.16.2 released

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!

URI scheme with optional bech32 address

Bitcoin’s URI scheme is a way to encode addresses, amount of Bitcoin to send, label and message, it is used to make handling wallets easier for the user as all you need to know is a URI that you’ll input into a wallet and just hit the send button!

A new suggestion came to light on the Bitcoin-dev mailing list about optional bech32 address support in the Bitcoin URI scheme, bech32 is a segwit address format that starts with “bc” and was recently supported by Bitcoin’s network, the suggestion is still early but may lead to a single URI scheme that works both on legacy and segwit wallets. We’ll keep an eye on it!

Alert key

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.