Reddcoin Core version 3.10.1 is now available from:
https://download.reddcoin.com/ or https://github.com/reddcoin-project/reddcoin/releases
This is a new minor version release, bringing bug fixes and security refinements.
Please report bugs using the issue tracker at github:
https://github.com/reddcoin-project/reddcoin/issues
How to Upgrade
————–
While the upgrade process normally does not touch the “wallet.dat” file, it is good practice to make a backup of your wallet file prior to any upgrade or downgrade operations. A simple backup can be performed using the File -> Backup… option to export a copy of the wallet file to a safe location.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Reddcoin-Qt (on Mac) or reddcoind/reddcoin-qt (on Linux).
Downgrade warning
———————
If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 3.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes
===============
3.10.1 Change log
=================
Misc:
– `fefad63` update translations
– `a0d9c7b` update chainparamsseeds.h with latest dnsseed data
– `c7f0216` update makeseeds python script
– `4532fa3` fix fee calculation for dust transactions
– `231471f` update checkpoints
– `764e1d1` update checkpoint python script
– `79bfe7e` stakinglabel improvements
– `e214afb` Set zero fee default true
Fix buffer overflow in bundled upnp
————————————
Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow inthe XML parser during initial network discovery.
Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/
This applies to the distributed executables only, not when building from source or using distribution provided packages.
Additionally, upnp has been disabled by default. This may result in a lower number of reachable nodes on IPv4, however this prevents future libupnpc vulnerabilities from being a structural risk to the network (see https://github.com/bitcoin/bitcoin/pull/6795).
Test for LowS signatures before relaying
—————————————–
Make the node require the canonical ‘low-s’ encoding for ECDSA signatures when relaying or mining. This removes a nuisance malleability vector.
Consensus behavior is unchanged.
If widely deployed this change would eliminate the last remaining known vector for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side it will block most transactions made by sufficiently out of date software. Unlike the other avenues to change txids on transactions this one was randomly violated by all deployed reddcoin software prior to its discovery. So, while other malleability vectors where made non-standard as soon as they were discovered, this one has remained permitted. Even BIP62 did not propose applying this rule to old version transactions, but conforming implementations have become much more common since BIP62 was initially written.
Reddcoin Core has produced compatible signatures since a28fb70e in January 2014, but this didn’t make it into a release until 2.0 in September 2015; Bitcoinj has done so for a similar span of time. Bitcoinjs and electrum have been more recently updated.
This does not replace the need for BIP62 or similar, as miners can still cooperate to break transactions. Nor does it replace the need for wallet software to handle malleability sanely[1]. This only eliminates the cheap and irritating DOS attack.
[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf
Transaction fee changes
———————–
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.
New command line options for transaction fee changes:
– `-txconfirmtarget=n` : create transactions that have enough fees (or priority) so they are likely to begin confirmation within n blocks (default: 1). This setting is over-ridden by the -paytxfee option.
– `-sendfreetransactions` : Send transactions as zero-fee transactions if possible (default: 1)
New RPC commands for fee estimation:
– `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for a transaction to begin confirmation within nblocks. Returns -1 if not enough transactions have been observed to compute a good estimate.
– `estimatepriority nblocks` : Returns approximate priority needed for a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good estimate.
RPC access control changes
————————–
Subnet matching for the purpose of access control is now done by matching the binary network address, instead of with string wildcard matching.
For the user this means that `-rpcallowip` takes a subnet specification, which can be
– a single IP address (e.g. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
– a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
– a network/netmask (e.g. `1.2.3.4/255.255.255.0` or `fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`)
An arbitrary number of `-rpcallow` arguments can be given. An incoming connection will be accepted if its origin address matches one of them.
For example:
| 0.9.x and before | 3.10.x |
|——————————————–|—————————————|
| `-rpcallowip=192.168.1.1` | `-rpcallowip=192.168.1.1` (unchanged) |
| `-rpcallowip=192.168.1.*` | `-rpcallowip=192.168.1.0/24` |
| `-rpcallowip=192.168.*` | `-rpcallowip=192.168.0.0/16` |
| `-rpcallowip=*` (dangerous!) | `-rpcallowip=::/0` (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
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.
Assuming a local RPC server running on port 45443, it is possible to request:
– Blocks: http://localhost:45443/rest/block/*HASH*.*EXT*
– Blocks without transactions: http://localhost:45443/rest/block/notxdetails/*HASH*.*EXT*
– Transactions (requires `-txindex`): http://localhost:45443/rest/tx/*HASH*.*EXT*
In every case, *EXT* can be `bin` (for raw binary data), `hex` (for hex-encoded binary) or `json`.
For more details, see the `doc/REST-interface.md` document in the repository.
RPC Server “Warm-Up” Mode
————————-
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
————————-
For 3.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 wallet 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.
The following RPCs have optional support for watch-only: `getbalance`, `listreceivedbyaddress`, `listreceivedbyaccount`, `listtransactions`, `listaccounts`, `listsinceblock`, `gettransaction`. See the RPC documentation for those methods for more information.
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
—————–
Starting from 3.10.0, the Reddcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is critical to Reddcoin’s consensus available to other applications, e.g. to language bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/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](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h). In its initial version the API includes two functions:
reddcoind
– `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.
Standard script rules relaxed for P2SH addresses
————————————————
The IsStandard() rules have been almost completely removed for P2SHredemption 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 Reddcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as standard Reddcoin Core nodes wouldn’t relay them to miners, nor would
most miners include them in blocks they mined.
reddcoin-tx
———-
It has been observed that many of the RPC functions offered by reddcoind are “pure functions”, and operate independently of the reddcoind wallet. This included many of the RPC “raw transaction” API functions, such as createrawtransaction.
reddcoin-tx is a newly introduced command line utility designed to enable easy manipulation of reddcoin transactions. A summary of its operation may be obtained via “reddcoin-tx –help” Transactions may be created or signed in a manner similar to the RPC raw tx API. Transactions may be updated, deleting inputs or outputs, or appending new inputs and outputs. Custom scripts may be easily composed using a simple text notation, borrowed from the reddcoin test suite.
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 “reddcoin-key” and “reddcoin-script” have been proposed, making key and script operations easily accessible via command line.
Staking and relay policy enhancements
—————————–
The `prioritisetransaction` RPC method has been added to enable stakers to manipulate the priority of transactions on an individual basis.
Reddcoin Core now supports BIP 22 long polling (redundant in staking wallets), so mining software can be notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Reddcoin Core’s `getblocktemplate` method. This enables miners to check the basic validity of their next block before expending work on it, reducing risks of accidental hardforks or mining invalid blocks.
Two new options to control staking policy:
– `-datacarrier=0/1` : Relay and mine “data carrier” (OP_RETURN) transactions
if this is 1.
– `-datacarriersize=n` : Maximum size, in bytes, we consider acceptable for
“data carrier” outputs.
The relay policy has changed to more properly implement the desired behavior of not relaying free (or very low fee) transactions unless they have a priority above the AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
——————————————
Reddcoin Core 3.10 implements BIP 66, which introduces block version 4, and a new consensus rule, which prohibits non-DER signatures. Such transactions have been non-standard since Reddcoin v1.4.0 (released in February 2014), but were technically still permitted inside blocks.
This change breaks the dependency on OpenSSL’s signature parsing, and is required if implementations would want to remove all of OpenSSL from the consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 6120 out of a sequence of 7200 blocks have version number 3 or higher, the new consensus rule becomes active for those blocks. When 6120 out of a sequence of 6120 blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current staking software is NOT provided, thus stakers should read the first paragraph of “Mining and relay policy enhancements” above.
3.10.1 Change log
=================
Misc:
– `fefad63` update translations
– `a0d9c7b` update chainparamsseeds.h with latest dnsseed data
– `c7f0216` update makeseeds python script
– `4532fa3` fix fee calculation for dust transactions
– `231471f` update checkpoints
– `764e1d1` update checkpoint python script
– `79bfe7e` stakinglabel improvements
– `e214afb` Set zero fee default true
Detailed prior changelog incorporating 3.10.0 and earlier, with all attributions and credits available in [Reddcoin Github readme.md](https://github.com/reddcoin-project/reddcoin/blob/3.10/doc/release-notes.md)
Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates.
Commits added and applied are numbered and documented in release-notes.md but incorporate modifications in the following functional and technical areas: RPC, Command-line options, Block (database) and transaction handling, P2P protocol and network code, Build system, Target sanity check fix, Wallet, GUI, Tests, Miscellaneous.
Credits (Reddcoin)
=================
– John Nash
– TechAdept
– cryptoBUZE
– Randy Vice
– Yavuz_Selim
– Harmonyq
– Roni Toni
– Tim Musick
– Doug Chandler
– Ball0r
– ReddheadJK
– luxiliod
– SYAR
– Dimal
– George DGB
Credits (Bitcoin)
=================
Thanks to everyone who contributed to this release: (full list of contributors on github readme.md document;)
And all those who contributed additional code review and/or security research:
– timothy on IRC for reporting the issue
– Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/reddcoin/).
