Bot releases are hidden (Show)
Published by daira about 5 years ago
v2.0.7-2 contains a shortened EOS halt so that it is in alignment with v2.0.7.
Testnet users needed to upgrade to 2.0.7 before Blossom activated. The amount of notice given to these users was brief, so many were not able to upgrade in time. These users may now be on the wrong branch. v2.0.7-2 adds an "intended rewind" to prevent having to manually reindex when reconnecting to the correct chain.
Fixed an issue where ERROR: spent index not enabled
would be logged unnecessarily.
Published by daira about 5 years ago
Shorter block times are coming to Zcash! In the v2.0.7 release we have implemented ZIP208 which will take effect when Blossom activates. Upon activation, the block times for Zcash will decrease from 150 seconds to 75 seconds, and the block reward will decrease accordingly. This affects at what block height halving events will occur, but should not affect the overall rate at which Zcash is mined. The total founders' reward stays the same, and the total supply of Zcash is decreased only microscopically due to rounding.
The v2.0.7 release includes Blossom activation on testnet, bringing shorter block times. The testnet Blossom activation height is 584000.
Changes needed for the Insight explorer have been incorporated into Zcash. This is an experimental feature and therefore is subject to change. To enable, add the experimentalfeatures=1
, txindex=1
, and insightexplorer=1
flags to zcash.conf
. This feature adds several RPCs to zcashd
which allow the user to run an Insight explorer.
Published by daira over 5 years ago
Zcashd v2.0.6 is a maintenance release, focussing on code clean-ups and minor bug fixes. It precedes v2.0.7 which is planned to include the implementation of the Blossom upgrade for testnet.
This release will be supported until block 617512, expected to arrive around October 9th 2019, at which point the software will end-of-support halt and shut down.
Summary of the changes included in this release:
z_mergetoaddress
, that prevented users sending from ANY_SPROUT
or ANY_SAPLING
when a wallet contained both Sprout and Sapling notes (#3909).zcashd
. v2.0.6 includes the first change to an RPC method.For a more complete list of changes for 2.0.6, see our 2.0.6 milestone.
Published by Eirik0 over 5 years ago
This is a hotfix release that all users are encouraged to upgrade to, especially users who updated to 2.0.5 or 2.0.5-1.
Zcashd v2.0.5-2 will be supported until block 598012, expected to arrive around September 5th 2019, at which point the software will end-of-support halt and shut down.
Summary of the changes included in this release:
For a more complete list of changes for this hotfix and 2.0.5, see our 2.0.5 milestone.
Published by Eirik0 over 5 years ago
This is a hotfix release that all users are encouraged to upgrade to, especially users who updated to 2.0.5.
Zcashd v2.0.5-1 will be supported until block 593762, expected to arrive around 28th August 2019, at which point the software will end-of-support halt and shut down.
Summary of the changes included in this release:
z_getmigrationstatus
while a wallet's migration transactions were in the mempool. (#3987)For a more complete list of changes for this hotfix and 2.0.5, see our 2.0.5 milestone.
Published by Eirik0 over 5 years ago
UPDATE: We are aware of an issue that causes nodes running Sprout->Sapling migrations in v2.0.5 to occasionally crash. Users are advised to upgrade to v2.0.5-1, which fixes the issue.
This release of Zcashd v2.0.5 adds the Sprout to Sapling migration tool, introduces a new consensus rule on mainnet to reject blocks that violate turnstiles, and adds 64-bit ARMv8 support. Zcashd v2.0.5 will be supported until block 592512, expected to arrive around 26th August 2019, at which point the software will end-of-support halt and shut down.
This release includes the addition of a tool that will enable users to migrate shielded funds from the Sprout pool to the Sapling pool while minimizing information leakage.
The migration can be enabled using the RPC z_setmigration
or by including -migration
in the zcash.conf
file. Unless otherwise specified funds will be migrated to the wallet's default Sapling address; it is also possible to set the receiving Sapling address using the -migrationdestaddress
option in zcash.conf
.
See ZIP308 for full details.
In the 2.0.4 release the consensus rules were changed on testnet to enforce a consensus rule which marks blocks as invalid if they would lead to a turnstile violation in the Sprout or Shielded value pools.
This release enforces the consensus rule change on mainnet
The motivations and deployment details can be found in the accompanying ZIP draft and PR 3968.
Developers can use a new experimental feature -developersetpoolsizezero
to test Sprout and Sapling turnstile violations. See PR 3964 for more details.
Added ARMv8 (AArch64) support. This enables users to build zcash on even more devices.
For information on how to build see the User Guide
Users on the Zcash forum have reported successes with both the Pine64 Rock64Pro and Odroid C2 which contain 4GB and 2GB of RAM respectively.
Just released, the Odroid N2 looks like a great solution with 4GB of RAM. The newly released Jetson Nano Developer Kit from Nvidia (also 4GB of RAM) is also worth a look. The NanoPC-T3 Plus is another option but for the simplest/best experience choose a board with 4GB of RAM. Just make sure before purchase thatthe CPU supports the 64-bit ARMv8 architecture.
For a more complete list of changes, please see the 2.0.5 milestone.
Published by bitcartel over 5 years ago
This release of Zcashd v2.0.4 fixes a Sprout wallet security bug, fixes miner address selection behaviour and introduces a new consensus rule on testnet to reject blocks that violate turnstiles. Zcashd v2.0.4 will be supported until block 569112, expected to arrive around 15th July 2019, at which point the software will end-of-support halt and shut down.
We include a fix for a bug in the Zcashd wallet which could result in Sprout z-addresses displaying an incorrect balance. Sapling z-addresses are not impacted by this issue.
This bug would occur if someone sending funds to a Sprout z-address intentionally sent a different amount in the note commitment of a Sprout output than the value provided in the ciphertext (the encrypted message from the sender). A symptom of this bug is the error message "logic error: witness of wrong element for joinsplit input" when attempting to send Sprout funds.
Users should install this update and then rescan the blockchain by invoking “zcashd -rescan”. Sprout address balances shown by the zcashd wallet should then be correct.
Thank you to Alexis Enston for bringing this to our attention.
Security Announcement 2019-03-19
Zcash inherited a bug from upstream Bitcoin Core where both the internal miner and RPC call getblocktemplate
would use a fixed transparent address, until RPC getnewaddress
was called, instead of using a new transparent address for each mined block. This was fixed in Bitcoin 0.12 and we have now merged the change.
Miners who wish to use the same address for every mined block, should use the -mineraddress
option.
Testnet nodes will now enforce a consensus rule which marks blocks as invalid if they would lead to a turnstile violation in the Sprout or Sapling value pools. The motivations and deployment details can be found in the accompanying ZIP draft.
The consensus rule will be enforced on mainnet in a future release.
For a more complete list of changes, please see the 2.0.4 milestone.
Published by mdr0id over 5 years ago
This release is intended to address security issues in libraries used by Zcash and other outstanding tickets that were in our Spring cleaning sprints.
A pointer overflow, with code execution, was discovered in ZeroMQ libzmq (aka 0MQ) 4.2.x and 4.3.x before 4.3.1. A v2_decoder.cpp zmq::v2_decoder_t::size_ready
integer overflow allows an authenticated attacker to overwrite an arbitrary amount of bytes beyond the bounds of a buffer, which can be leveraged to run arbitrary code on the target system. This update addresses the vulnerability when ZeroMQ is enabled, which is not enabled by default.
This change makes sigcache faster, more efficient, and larger. It also reduces the number of database lookups when processing new transactions.
For a more complete list of changes, please see the 2.0.3 milestone.
For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide.
Published by mdr0id almost 6 years ago
This release adds further support for Sapling in the zcashd wallet RPC and mitigates an issue identified by an external auditor. Information on the Sapling network upgrade (which activated on Oct 28th 2018) can be found below:
z_getnewaddress
now returns a Sapling address by defaultPreviously when calling z_getnewaddress
a Sprout shielded address would be returned by default. With this release, a Sapling shielded address will be returned by default.
To address auditor issue ZEC-013 which identified a potential denial-of-service vector related to expiry height, nodes will no longer propagate transactions which are expiring soon, defined as within the next 3 blocks. For example, if the current block height is 99, and the next block to be mined is 100, a transaction with an expiry height of 100, 101, 102 will be considered "expiring soon" and will be rejected by the mempool. A transaction with an expiry height of 103 will be accepted. This does not impact transactions which have disabled expiry height (by setting to 0).
z_mergetoaddress
(#3619)z_getnewaddress
(#3680)zcbenchmark
(#3611)For a more complete list of changes, please see the 2.0.2 milestone.
For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide.
Published by mdr0id about 6 years ago
This release is the first Sapling RPC supported version of the Zcash node software!
This release is consensus-compatible with the Sapling network upgrade and adds significant support in the zcashd wallet RPC. We’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. More information on the upcoming Sapling network upgrade can be found below:
Sapling has activated on the testnet at block 280000. If you are running a v2.0.1 node, you no longer need to specify -experimentalfeatures
and -developersapling
to use Sapling functionality on testnet. If you are running an older v2.0.0 node, please upgrade to version v2.0.1 which introduced a consensus rule change to allow min difficulty blocks to be mined from block 299188, thereby splitting the chain.
This release contains support for Sapling RPC functionality on mainnet, enabling the sending of Sapling shielded funds.
All Sapling addresses will use hierarchical deterministic key generation according to ZIP 32 (keypath m/32'/133'/k'
on mainnet). Transparent and Sprout addresses will still use traditional key generation.
Backups of HD wallets, regardless of when they have been created, can therefore be used to re-generate all possible Sapling private keys, even the ones which haven't already been generated during the time of the backup. Regular backups are still necessary, however, in order to ensure that transparent and Sprout addresses are not lost.
A future release will support the importing and restoration of HD wallets.
In signrawtransaction
we determine the consensus branch ID (which we then later use to construct the transaction) using the chain height. We now also consider the APPROX_RELEASE_HEIGHT
, as this is a better estimation than 0 for the height of the chain if we are unsynced. We have also added an additional parameter to signrawtransaction
to allow manually overriding the consensus branch ID that zcashd determines we are on.
z_shieldcoinbase
(#3518)z_listunspent
(#3510)z_listreceivedbyaddress
(#3499)z_importwallet
and z_exportwallet
(#3491)z_sendmany
(#3489)z_getbalance
and z_gettotalbalance
(#3436)For a more complete list of changes, please see the 2.0.1 milestone.
For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide on using zcashd unmodified .
Published by str4d about 6 years ago
This release is the first Sapling-compatible version of the Zcash node software!
This release is consensus-compatible with the Sapling network upgrade, and so we’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. You can read more about the Sapling network upgrade here or on the Sapling Network Upgrade page.
Sapling will activate on the testnet at block 280000, which is expected about a week after this release. Sapling had previously activated on testnet, but because changes were made to the consensus rules your node will automatically roll back and proceed on the Overwinter testnet branch until Sapling activates again at the new height.
This release contains only experimental support for Sapling RPC functionality. Full support for Sapling RPC functionality will appear in the 2.0.1 release.
Developers must specify -experimentalfeatures
and -developersapling
to use the existing functionality on testnet after activation. Alternatively, developers can use these features in regtest mode.
After Overwinter activation, nodes syncing from a block height prior to the activation height (347500) experienced slow syncing due to a peer banning mechanism that was introduced to mitigate against a class of DoS attacks from Sprout nodes. This fix replaces the use of peer banning with behavior to ignore invalid transactions.
For a more complete list of changes, see the 2.0.0 milestone.
Published by bitcartel over 6 years ago
Hot on the heels of Zcon0 comes a new release of the Zcash node software (Overwinter-compatible). This release focused on implementing internal changes necessary for Sapling, with development progressing in tandem with the librustzcash and sapling-crypto libraries.
Overwinter activated successfully at block 347500 with most of the ecosystem upgrading smoothly. Some common issues we helped third parties with both before and after activation, were:
When using an offline node to sign raw transactions, the offline node needs to be synced past the Overwinter activation block height, so that the correct consensus branch id is used.
With the new Overwinter signature hashing scheme, when passing in the prevtxs
parameter to signrawtransaction
, the amount
field must be specified. Previously this was not mandatory.
When developing custom code to perform the Overwinter signature hashing scheme, a common issue has been mixing up the endianness of fields.
See our previous blog post and the Overwinter Network Upgrade page for more information.
-disabledeprecation
In release 1.0.9 we implemented end-of-support (EOS) halt for zcashd
software
versions made by the Zcash Company. The configuration option
-disabledeprecation
was added as a way for users to specifically choose to
stay on a particular software version. However, it incorrectly implied that
deprecated releases would still be supported.
This release removes the -disabledeprecation
option, so that zcashd
software
versions made by the Zcash Company will always shut down in accordance with the
defined EOS policy (currently 16 weeks after release). Users who wish to
use a different policy must now specifically choose to either:
Either way, it is much clearer that the software they are running is not
supported by the Zcash Company.
hashFinalSaplingRoot
has been added to RPC call getblocktemplate
. (#3299)finalsaplingroot
has been added to RPC calls getblockheader
and getblock
. (#3337)signmessage
has been clarified. (#3259)For a more complete list of changes, see our 1.1.2 milestone.
Published by bitcartel over 6 years ago
This release is an Overwinter-compatible version of the Zcash node software, with initial support for Sapling consensus rules and a Sapling testnet activation height set to block 252500.
The first block of Overwinter will be block 347500, which is expected to be mined on the 25th of June 2018. Please upgrade to this release, or any release from v1.1.0 onwards, in order to follow the Overwinter network upgrade. See our previous blog post and the Overwinter Network Upgrade page for more information.
The consensus code preparations for the Sapling network upgrade, as described
in ZIP 243 and the
Sapling spec
are finished and included in this release. Sapling support in the wallet and
RPC is ongoing, and is expected to land in master over the next few weeks.
The Sapling MPC is currently
working on producing the final Sapling parameters. In the meantime, Sapling will
activate on testnet with dummy Sapling parameters at height 252500. This
activation will be temporary, and the testnet will be rolled back by version
2.0.0 so that both mainnet and testnet will be using the same parameters.
Users who want to continue testing Overwinter should continue to run version
1.1.0 on testnet, and then upgrade to 2.0.0 (which will be released after
Overwinter activates).
Sapling can also be activated at a specific height in regtest mode by
setting the config options -nuparams=5ba81b19:HEIGHT -nuparams=76b809bb:HEIGHT
.
These config options will change when the testnet is rolled back for 2.0.0
(because the branch ID for Sapling will change, due to us following the safe
upgrade conventions we introduced in Overwinter).
Users running testnet or regtest nodes will need to run
./zcutil/fetch-params.sh --testnet
(for users building from source) or
zcash-fetch-params --testnet
(for binary / Debian users).
As a reminder, because the Sapling activation height is not yet specified for
mainnet, version 1.1.1 will behave similarly as other pre-Sapling releases even
after a future activation of Sapling on the network. Upgrading from 1.1.1 will
be required in order to follow the Sapling network upgrade on mainnet.
Once Sapling has activated, transactions must use the new v4 format (including
coinbase transactions). All RPC methods that create new transactions (such as
createrawtransaction
and getblocktemplate
) will create v4 transactions once
the Sapling activation height has been reached.
The RPC command line client gained a new argument, -stdin
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:
$ src/zcash-cli -stdin z_importkey
mysecretzkey
yes
200000
^D (Ctrl-D)
It is recommended to use this for sensitive information such as private keys, as
command-line arguments can usually be read from the process table by any user on
the system.
The asm
property of each scriptSig now contains the decoded signature hash
type for each signature that provides a valid defined hash type.
The following items contain assembly representations of scriptSig signatures
and are affected by this change:
getrawtransaction
decoderawtransaction
/rest/tx/
(JSON format)/rest/block/
(JSON format when including extended tx details)zcash-tx -json
For example, the scriptSig.asm
property of a transaction input that
previously showed an assembly representation of:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001
now shows as:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]
Note that the output of the RPC decodescript
did not change because it is
configured specifically to process scriptPubKey and not scriptSig scripts.
getblock
. (#3179)zcash-cli
, serialization, out-of-memory error reporting and the configuration option uacomment
. (#3086, #3180, #3193, #2813)For a more complete list of changes, see our 1.1.1 milestone.
Published by str4d over 6 years ago
This release is the first Overwinter-compatible version of the Zcash node software! It also includes various bug fixes, improvements for the z_mergetoaddress
RPC method, and the NODE_BLOOM
service bit.
The first block of Overwinter will be block 347500, which is expected to be mined on the 25th of June 2018, just before noon EDT / 16:00 UTC. Please upgrade to this release, or any subsequent release, in order to follow the Overwinter network upgrade. See our previous blog post and the Overwinter Network Upgrade page for more information.
-mempooltxinputlimit
deprecationThe configuration option -mempooltxinputlimit
was added in release 1.0.10 as a short-term fix for the quadratic hashing problem inherited from Bitcoin. At the time, transactions with many inputs were causing performance issues for miners. Since then, several performance improvements have been merged from the Bitcoin Core codebase that significantly reduce these issues.
The Overwinter network upgrade includes changes that solve the quadratic hashing problem. As a result, -mempooltxinputlimit
will no longer be needed. A transaction with 1000 inputs will take just as long to validate as 10 transactions with 100 inputs each. Starting from this release, -mempooltxinputlimit
will be enforced before the Overwinter activation height is reached, but will be ignored once Overwinter activates. The option will be removed entirely in a future release after Overwinter has activated.
NODE_BLOOM
service bitSupport for the NODE_BLOOM
service bit, as described in BIP 111, has been added to the P2P protocol code.
BIP 111 defines a service bit to allow peers to advertise that they support Bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow Bloom filtering of the connection despite lacking the new service bit.
In this version, it is only enforced for peers that send protocol versions >=170004
. For the next major version it is planned that this restriction will be removed. It is recommended to update SPV clients to check for the NODE_BLOOM
service bit for nodes that report version 170004 or newer.
-mempooltxinputlimit
. (#3098)NODE_BLOOM
service bit. (#2814)z_mergetoaddress
when running it several times in parallel. (#3106)For a more complete list of changes, see our 1.1.0 milestone.
Published by str4d over 6 years ago
This release contains the Overwinter consensus rules with a testnet activation height. It also includes various bug fixes, and adds an experimental RPC method for merging UTXOs and notes.
The code preparations for the Overwinter network upgrade, as described in ZIP 200, ZIP 201, ZIP 202, ZIP 203, and ZIP 143 are finished and included in this release. Overwinter will activate on testnet at height 207500, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=5ba81b19:HEIGHT
.
However, because the Overwinter activation height is not yet specified for mainnet, version 1.0.15 will behave similarly as other pre-Overwinter releases even after a future activation of Overwinter on the network. Upgrading from 1.0.15 will be required in order to follow the Overwinter network upgrade on mainnet.
Once Overwinter has activated, transactions must use the new v3 format (including coinbase transactions). All RPC methods that create new transactions (such as createrawtransaction
and getblocktemplate
) will create v3 transactions once the Overwinter activation height has been reached.
Overwinter transactions created by zcashd
will also have a default expiry height set (the block height after which the transaction becomes invalid) of 20 blocks after the height of the next block. This can be configured with the config option -txexpirydelta
.
In order to simplify the process of combining many small UTXOs and notes into a few larger ones, a new RPC method z_mergetoaddress
has been added as an experimental feature. It merges funds from t-addresses, z-addresses, or both, and sends them to a single t-address or z-address. To test it out, set the config option -zmergetoaddress
(as well as enabling experimental features). We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release.
Unlike most other RPC methods, z_mergetoaddress
operates over a particular quantity of UTXOs and notes, instead of a particular amount of ZEC. By default, it will merge 50 UTXOs and 10 notes at a time; these limits can be adjusted with the parameters transparent_limit
and shielded_limit
.
z_mergetoaddress
also returns the number of UTXOs and notes remaining in the given addresses, which can be used to automate the merging process (for example, merging until the number of UTXOs falls below some value).
The default -dbcache
has been changed in this release to 450MiB. Users can set -dbcache
to a higher value (e.g. to keep the UTXO set more fully cached in memory). Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.
Additional information relating to running on low-memory systems can be found here: reducing-memory-usage.md.
Published by str4d almost 7 years ago
This release contains new features, bug fixes, and documentation improvements.
Support for incoming viewing keys, as described in the Zcash protocol spec, has been added to the wallet.
Use the z_exportviewingkey
RPC method to obtain the incoming viewing key for a z-address in a node's wallet. For Sprout z-addresses, these always begin with "ZiVK" (or "ZiVt" for testnet z-addresses). Use z_importviewingkey
to import these into another node.
A node that possesses an incoming viewing key for a z-address can view all past transactions received by that address, as well as all future transactions sent to it, by using z_listreceivedbyaddress
. They cannot spend any funds from the address. This is similar to the behaviour of "watch-only" t-addresses.
z_gettotalbalance
now has an additional boolean parameter for including the balance of "watch-only" addresses (both transparent and shielded), which is set to false
by default. z_getbalance
has also been updated to work with watch-only addresses.
Nodes can now track the total amount of shielded ZEC inside the Sprout circuit. This is measured by adding up the ZEC moving between the Transparent Value Pool and JoinSplits (see Anatomy of a Zcash Transaction). getblockchaininfo
shows the total for the entire chain, while getblock
will show the total as of a specific block.
To enable this monitoring on a specific node, it must be re-indexed. This will take several hours to complete, but otherwise will not affect any other node data.
dumpwallet
and z_exportwallet
to prevent them overwriting existing files. (#2741)For a more complete list of changes, see our 1.0.14 milestone.
Published by str4d almost 7 years ago
This release introduces new features, performance improvements and bug fixes. Our new low memory prover reduces memory usage by 43% when generating a shielded transaction, from 3 GB to 1.7 GB. An experimental feature, payment disclosure, can help services better manage their shielded payments. We also now fully support the z_shieldcoinbase
RPC call to help miners sweep up and shield their coinbase rewards.
Summary of the changes included in this release:
z_getpaymentdisclosure
and z_validatepaymentdisclosure
(#2519). This feature enables a sender to prove that a payment was made to a recipient, which can help services better manage their shielded payments. See the documentation for a full explanation of this new feature.z_shieldcoinbase
is now a fully supported RPC call (#2692). See an explanation of this command here.wallet_protectcoinbase
, which was previously failing on some platforms. (#2698)For a more complete list of changes, see our 1.0.13 milestone.
Published by str4d about 7 years ago
This release includes bug fixes and usability improvements. It also adds a new RPC method z_shieldcoinbase
as an experimental feature, for easily shielding coinbase UTXOs. We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release.
Summary of the changes included in this release:
z_shieldcoinbase
as an experimental feature. (#2615)importprivkey
RPC method to return the public address corresponding to the imported key. (#2616)For a more complete list of changes, see our 1.0.12 milestone.
Published by str4d about 7 years ago
This release includes bug fixes and usability improvements.
Summary of the changes included in this release:
401 Unauthorized
bug encountered when using some JSON-RPC libraries. (#2529)z_sendmany
to fail with an error if the user sets minconf=0
when sending from z-addresses. (#2525, #2526)listunspent
RPC method to specify whether outputs were from a coinbase transaction, to help users identify t-addresses that need to have their contents shielded. (#2522)For a more complete list of changes, see our 1.0.11 milestone.
Published by str4d over 7 years ago
This is a hotfix release that all users are encouraged to upgrade to, especially users who updated to 1.0.10.
Summary of the changes included in this release:
For a more complete list of changes, see our 1.0.10-1 milestone.