As Spring returns the blood to our blushing chops, I'm happy to come to you with news of our latest release. After a couple of weeks in lovely Castello Tesino on our (apparently) annual winter-sports retreat, Parity 1.6 "Morality, Solidarity, and Virtuosity" is officially out and there's a decent amount to see.
For those of you that just want the release, you can find 1.6.2 (we're so fast the two releases were outdated before I managed to finish this post :-P ) over on our releases page, or, if you're running 1.5.x, you can upgrade by clicking the upgrade link at the bottom of Parity Wallet.
For starters, we've been working on improving the multi-sig wallet. Some of its deficiencies have been documented by others in the community, particularly its inability to manage multi signature contract-transactions which do not involve ether. Rather than rewrite from scratch, however, we have elected to tweak the existing Foundation Multisig; the specific improvements are:
We hope to bring in per-token daily limits and a dead man's switch into future iterations of the wallet.
For those of you who are the owners of hardware wallets, we have a nice surprise - Parity Wallet comes with support for the Ledger hardware wallet. Our support is integrated into both Parity Wallet and the Parity Client, meaning that we support wallet usage in headless server operations as well as the more usual Parity Wallet browser-side.
In doing this support, we introduced some important infrastructure into Parity, so hopefully supporting other hardware wallets is not far away.
For the miners out there, I'm happy to report that Parity now has in-built Stratum protocol support. For those of you not familiar, Stratum is a protocol allowing the efficient reporting of new workloads for miners. Simply start parity with
--stratum and it'll be pushing out events on port 8008 by default, ready for use with Genoil's ethminer.
Pushing forward with optimisations, Parity now supports a memory-footprint oriented state pruning model. This allows you to set the target amount of memory to consume in maintaining the pruning history, and means no more dreaded "out of memory" problems should the network again undergo unprecedented amounts of state bloat, while still retaining as large a history as possible in order to avert the issue of "fork-lock" seen on PoW testnets.
The transaction queue was always a bit forgetful - if you ever restarted Parity while it had contents, they'd be gone afterwards. With "normal" transactions this wasn't particularly problematic, however with delayed "alarm-clock" transactions, there may have been important information lost.
Well, no longer! The transaction queue is now entirely persistent between restarts, storing all information in a per-chain database. Lose transactions no more.
Privacy is important; if someone gets hold of your JSON wallet(s), while they may not be able to access your accounts, they are still able to see what addresses you control. Why? Because all of this information is stored, in plain text, in your home directory. While this was never the intent of the original JSON wallet format authors - who explicitly introduced anonymous UUIDs for identification, the practice has since become something of a de facto standard.
While Parity still defaults to this behaviour for compatibility with major clients, we now provide an alternative: vaults. Vaults store all the metadata - address, name and description amongst other information - encrypted. To avoid you having to remember a second password for each wallet, wallets are placed into groups which share the same metadata password. Such a group is a vault. When you open a vault, you get access to this metadata and the accounts contained within are displayed in Parity Wallet. Before you open them, the information - the accounts it describes - are entirely unavailable and thus hidden from view.
Parity now features a "home page". Here you can find news of new Ðapps, active accounts and recent URLs visited. We'll be fleshing this out over the coming months and introducing some APIs to make it more useful for Parity Ðapps.
In addition to this, you'll notice that we have available our Chrome extension. Usage of this is highly recommended; "normal" websites that wish to make use of Ethereum will be able to through this extension in a manner compatible with other "Ethereum browsers". If you use Chrome you'll automatically be prompted to install when you open Parity Wallet.
Finally, I'm happy to announce that our "experimental" Mac installer is no longer experimental! Rather than installing as an invisible process, Parity now lives in the Mac's menubar allowing it to be started and stopped easily. Hurrah for ease of use!
Now that we have pluggable consensus in Parity (and in fact have had for about a year), we'll be quickly iterating on our various offerings of consensus algorithm. For 1.6, we're aiming to take our existing PoA ("proof-of-authority") consensus schemes to make them more flexible modular.
To this aim, we have introduced validator-set contracts; this allows the authority set for signing any given block be able to be specified programmatically via a contract. It makes updating the authority set without a hard fork not only possible but quite trivial and opens the door to a partially generic consensus algorithm where this contract itself can be upgraded through some process, perhaps the agreement of most existing authorities.
That's about all for this time. We're hard at work preparing our Spring release, 1.7, for your pleasure; upcoming we have 2-factor wallets, an enhanced transaction inspection and development environment, HD account chains, the Parity light-client protocol and the various improvements to the Ethereum protocol that will make up Metropolis.
<3, the Parity team.