New Wallet UI

v4.0.0 introduces a completely new GUI for the wallet, designed and coded from the ground up by the [Krubit](https://krubit.com/) team.

This new UI, aside from the overall design large implementation, includes user-focused improvements and features such as a brief introduction on first load, a FAQ section, one-click QRCode compatible receiving addresses, masternode creation wizard, dark and light themes, filterable staking charts, and much more.

You can read more details about this extensive work in ([PR #954](https://github.com/PIVX-Project/PIVX/pull/954))

There are some legacy features that have not been included, however, notably the in-wallet block explorer and the governance page. The in-wallet block explorer was sorely outdated, and the governance page was a newer addition that will be seeing a return in a future version.

Cold Staking

A brand new feature is being introduced with the release of v4.0.0: Cold Staking ([PR #955](https://github.com/PIVX-Project/PIVX/pull/955))! This feature allows a coin owner to keep coins in a "cold" (or locked) wallet whilst a "hot" wallet carries out the burden of staking those coins.

This brings added security to coin owners as they are no longer required to use an unlocked or partially unlocked wallet (with the ability to spend coins anywhere) in order to gain staking rewards. Users who have chosen to store their coins on hardware devices such as a Ledger or Trezor¹ can also gain staking rewards with those coins.

A full technical writup is available on the [PIVX Wiki](https://github.com/PIVX-Project/PIVX/wiki/ColdStaking), and an initial video showcase is available on [YouTube](https://www.youtube.com/watch?v=utxB5TzAeXc).

A brief guide to setup cold staking with GUI and RPC is available [here](https://github.com/random-zebra/PIVX-Wiki/blob/master/User-Documentation/Cold-Staking-HowTo.md).

¹ Spending cold stakes from HW wallets currently available only for Ledger devices via [PET4L](https://github.com/PIVX-Project/PET4L) tool.

Multi-Split Stake Splitting

Stake splitting has received a makeover and now supports splitting to more than two (2) outputs. [PR #968](https://github.com/PIVX-Project/PIVX/pull/968) introduced the change, which is controlled by the wallet's `stakesplitthreshold` setting.

The default split threshold remains at 2000 PIV, and can be adjusted in the GUI's Settings page, or via the RPC `setstakesplitthreshold` command.

For a real example, with a stake split threshold of 1500, and a UTXO of 4708.1557; the current stake split algorithm would break that into two outputs of approximately 2355.07785. With this new logic; it will be broken into 3 outputs instead of two; each sized 1570.0519 (4708.1557 input + 2 stake = 4710.1557 / 3 outputs = 1570.0519.

The maximum number of outputs is currently capped at 48. Also, in relation to the new Cold Staking feature described above; the stake split threshold is set by the staker wallet and **NOT** the owner wallet.

New Consensus Rules

The following consensus rule changes will be enforced on or shortly after block `2153200`. Note that **Upgrade Enforcement** (mentioned above) will occur prior to this block height.

Since the discovery of a critical exploit within the libzerocoin library in early 2019, remaining legacy v1 zPIV have been un-spendable. We're happy to say that, once the new consensus rules are in effect, users will once again be able to spend their v1 zPIV with public spends version 4 ([PR #936](https://github.com/PIVX-Project/PIVX/pull/936)).

As with the previous version 3 public spends introduced in core wallet version 3.3.0 (enabling the spending of v2 zPIV), version 4 spends will also be public. A full technical writeup is available on the [PIVX Wiki](https://github.com/PIVX-Project/PIVX/wiki/CoinRandomnessSchnorrSignature).

Cold staking introduces a new opcode, `OP_CHECKCOLDSTAKEVERIFY`, in the scripting language, and a new standard transaction type using it, named `P2CS` (Pay-To-Cold-Staking). A P2CS script is defined as follows:

`OP_CHECKCOLDSTAKEVERIFY` is used to ensure that the staker can only spend the output in a valid coinstake transaction (using the same P2CS script in the new output).

[#PR1002](https://github.com/PIVX-Project/PIVX/pull/1002) introduces a new time protocol for the Proof-Of-Stake consensus mechanism, to ensure better efficiency, fairness and security. The time is now divided in 15-seconds slots and valid blocktimes are at the beginning of each slot (i.e. the block timestamp's seconds can only be `00`, or `15`, or `30` or `45`).<br>

The maximum future time limit is lowered from 3 minutes to 14 seconds and the past limit is set to the previous blocktime (i.e. a block can no longer have a timestamp earlier than its previous block).<br>

This means that, when looking for a valid kernel, each stakeable input can be hashed only once every 15 seconds (once per timeslot), and it is not possible to submit blocks with timestamp higher than the current time slot. This ultimately enables the removal of the "hashdrift" concept.<br>

**NOTE:** Given the much stricter time constraints, a node's clock synchronization is required for P2P connections: the maximum time offset is 15 seconds and peers with a time drift higher than 30 seconds (in absolute value) will be outright disconnected.

For advanced users, we recommend the setup of NTP clients and own servers. This will provide to your node a higher level of time accuracy and the best, time wise, synchronization with the peers in the network.

[#PR1022](https://github.com/PIVX-Project/PIVX/pull/1022) defines Version 7 blocks, which remove the (now-unused) accumulator checkpoint from the block header. This results in an overall data reduction of ~256 bits from each block as well as the in-memory indexes.

Layer 2 network messages (MN, Budget, Spork, etc) are now signed based on the hash of their **binary** content instead of their **string** representation ([#PR1024](https://github.com/PIVX-Project/PIVX/pull/1024)).

Two new SPORKS are introduced, `SPORK_17` ([#PR975](https://github.com/PIVX-Project/PIVX/pull/975)) and `SPORK_18` ([#PR995](https://github.com/PIVX-Project/PIVX/pull/995)).<br>

`SPORK_17` (off by default) is used to activate the [Cold Staking](#cold-staking) protocol. When this spork is off, no cold-staked block is accepted by the network and new delegations are rejected, but coin-owners are still able to spend previously created pay-to-cold-stake delegations.

`SPORK_18` (off by default) is used to switch between Version 3 and [Version 4 Public Spends](#v1-zpiv-spending-public-spends-version-4). When this spork is active, only version 4 spends are accepted by the network. When it's not, only version 3 spends are accepted.

A new (optional) argument, `includeDelegated`, has been added to the following commands that allows these commands to include delegated coins/information in their operation:

- `getbalance` - Boolean (Default: True)

- `sendfrom` - Boolean (Default: False)

- `sendmany` - Boolean (Default: False)

- `listtransactions` - Boolean (Default: True)

Additionally, a new (optional) argument, `includeCold`, has been added to the `listtransactions` command (Boolean - Default: True), which allows for filtering of cold-staker delegated transactions.

The `validateaddress` command now includes an additional response field, `isstaking`, to indicate wither or not the specified address is a cold staking address.

The `getwalletinfo` command now includes two additional response fields:

- `delegated_balance` - PIV balance held in P2CS contracts (delegated amount total).

- `cold_staking_balance` - PIV balance held in cold staking addresses.

- `getnewstakingaddress`

- `delegatestake`

- `rawdelegatestake`

- `getcoldstakingbalance`

- `delegatoradd`

- `delegatorremove`

- `listcoldutxos`

- `liststakingaddresses`

- `listdelegators`

`getnewstakingaddress` generates a new cold staking address:

`delegatestake` sends a cold staking delegation transaction:

`rawdelegatestake` creates a raw cold staking delegation transaction without broadcasting it to the network:

`getcoldstakingbalance` returns the cold balance of the wallet:

`delegatoradd` whitelists a delegated owner address for cold staking:

`delegatorremove` to remove previously whitelisted owner address:

`listcoldutxos` lists all P2CS UTXOs belonging to the wallet (both delegator and cold staker):

`liststakingaddresses` lists all cold staking addresses generated by the wallet:

`listdelegators` lists the whitelisted owner addresses

Snapcraft Packages

For our linux users, in addition to the [Ubuntu PPA](https://launchpad.net/~pivx) repository, we are now offering a [Snap package](https://snapcraft.io/pivx-core) as quick way to install and update a PIVX wallet.

Release versions are available via the `Stable` branch, and (for testing-only purposes) nightly builds are available in the `Beta` branch.

Internal Miner/Staker Change

The wallet's internal miner/staker is no longer prevented from running prior to having synced all the additional layer 2 (MN/Budget) data. Instead, mining/staking uses better logic to allow block creation without fully synced layer 2 data when the full data set wouldn't be required.

In other words, try to stake a new block only if:

- full layer 2 sync is complete

OR

- The spork list is synced and all three sporks (8,9 and 13) are **not** active.

Faster Shutdown During Initial Loading

Previously, if a user wanted to close/quit the wallet before it had finished its initial loading process, they would need to wait until that loading process actually completed before the wallet would fully close.

Now, the new behavior is to gracefully close the wallet once the current step is complete.