UFO Core 0.10 WIP

Our work continues with UFO Core 0.10 which brings several major improvements to the client. In addition to that, an advanced difficulty adjustment algorithm has been successfully tested on the 0.10 wallet on testnet. We are taking this step in order to mitigate the “greedy miner” effect and create a more fair coin distribution.

Some compatibility issues between the new 0.10 client and the current NeoScrypt miner software are present. As getwork is removed in the 0.10 client, an update of the mining software be necessary for it to work with the newer getblocktemplate RPC call. UFO will be the first of the NeoScrypt coins to move to a codebase where getwork has been fully deprecated.

To make absolutely sure that 0.10 release is going to be 100% compatible with NeoScrypt miners, we decided to wait until we have green light from the NeoScrypt developers to proceed. Meanwhile we are carrying on testing compatibility between 0.8, 0.9 and the new 0.10 clients on testnet.

This is an overview of the upcoming 0.10 improvements:

Faster synchronization

Peers are asked for block headers first and validate those. In a second stage, when the headers have been discovered, the blocks are downloaded. However, they can be downloaded in parallel from all available peers.

Dynamic transaction fees

This release automatically estimates how high a transaction fee (or how high a priority) transactions require to be confirmed quickly. The default settings will create transactions that confirm quickly; see the new ‘txconfirmtarget’ setting to control the tradeoff between fees and confirmation times. Fees are added by default unless the ‘sendfreetransactions’ setting is enabled.

Prior releases used hard-coded fees (and priorities), and would sometimes create transactions that took a very long time to confirm.

Statistics used to estimate fees and priorities are saved in the data directory in the fee_estimates.dat file just before program shutdown, and are read in at startup.

REST interface

A new HTTP API is exposed when running with the -rest flag, which allows unauthenticated access to public node data.

It is served on the same port as RPC, but does not need a password, and uses plain HTTP instead of JSON-RPC.

Improved signing security

For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic.

This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille.

There exist attacks[1] against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it’s a better practice to avoid the exposure.

OpenSSL has code in their source repository for derandomization and reduction in timing leaks that we’ve eagerly wanted to use for a long time, but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we’re aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.

[1] https://eprint.iacr.org/2014/161.pdf

Watch-only support

The wallet can now track transactions to and from wallets for which you know all addresses (or scripts), even without the private keys.

This can be used to track payments without needing the private keys online on a possibly vulnerable system. In addition, it can help for (manual) construction of multisig transactions where you are only one of the signers.

One new RPC, importaddress, is added which functions similarly to importprivkey, but instead takes an address or script (in hexadecimal) as argument. After using it, outputs credited to this address or script are considered to be received, and transactions consuming these outputs will be considered to be sent.

Compared to using getrawtransaction, this mechanism does not require -txindex, scales better, integrates better with the wallet, and is compatible with future block chain pruning functionality. It does mean that all relevant addresses need to added to the wallet before the payment, though.

Consensus library

The purpose of this library is to make the verification functionality available to other applications, e.g. to language bindings such as python-bitcoinlib or alternative node implementations.

This library is called libbitcoinconsensus.so (or, .dll for Windows). Its interface is defined in the C header bitcoinconsensus.h.

In its initial version the API includes two functions:

bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction correctly spends the passed scriptPubKey under additional constraints indicated by flags
bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface for existing methods should remain stable.

Relaxed P2SH address rules

The IsStandard() rules have been almost completely removed for P2SH redemption scripts, allowing applications to make use of any valid script type, such as “n-of-m OR y”, hash-locked oracle addresses, etc. While the Bitcoin protocol has always supported these types of script, actually using them on mainnet has been previously inconvenient as standard Bitcoin Core nodes wouldn’t relay them to miners, nor would most miners include them in blocks they mined.

UFO-tx utility

It has been observed that many of the RPC functions offered by bitcoind are “pure functions”, and operate independently of the bitcoind wallet. This included many of the RPC “raw transaction” API functions, such as createrawtransaction.

This tool may be used for experimenting with new transaction types, signing multi-party transactions, and many other uses. Long term, the goal is to deprecate and remove “pure function” RPC API calls, as those do not require a server round-trip to execute.

Other utilities “bitcoin-key” and “bitcoin-script” have been proposed, making key and script operations easily accessible via command line.