v5.0.0

PIVX Core version v5.0.0 is now available from: https://github.com/pivx-project/pivx/releases

This is a new major version release, including various bug fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github: https://github.com/pivx-project/pivx/issues

Mandatory Update

PIVX Core v5.0.0 is a mandatory update for all users. This release contains a protocol upgrade (to 70920), new consensus rules and improvements that are not backwards compatible with older versions. Users will need to update their clients before enforcement of this update goes into effect.

Update enforcement is currently scheduled to go into effect at the following block height:

Mainnet: 2,700,500

Masternodes will need to be restarted once both the masternode daemon and the controller wallet have been upgraded.

Note: In preparation for the enforcement, upgraded peers will start rejecting non-upgraded peers few hours before the enforcement block height, we recommend everyone to be updated at max a day before the final time.

How to Upgrade

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/PIVX-Qt (on Mac) or pivxd/pivx-qt (on Linux).

Sapling Parameters

In order to run, PIVX Core now requires two files, sapling-output.params and sapling-spend.params (with total size ~50 MB), to be saved in a specific location.

For the following packages, no action is required by the user:

• macOS release dmg binaries will use the params that are bundled into the .app bundle.
• Windows installer .exe will automatically copy the files in the proper location.
• Linux PPA/Snap/Copr installs will automatically copy the files in the proper location.

For the other packages, the user must save the param files in the proper location, before being able to run PIVX v5.0.0:

• macOS/Linux tar.gz tarballs include a bash script (install-params.sh) to copy the parameters in the appropriate location.
• Windows .zip users need to manually copy the files from the share/pivx folder to the %APPDATA%\PIVXParams directory.
• self compilers can run the script from the repository sources (params/install-params.sh), or copy the files directly from the params subdirectory.

Compatibility

PIVX Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Apple released it's last Mountain Lion update August 13, 2015, and officially ended support on December 14, 2015. PIVX Core software starting with v3.2.0 will no longer run on MacOS versions prior to Yosemite (10.10). Please do not report issues about MacOS versions prior to Yosemite to the issue tracker.

PIVX Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable Changes

New SHIELD Protocol Implemented!

Overview

Users will be able to protect their financial information by sending and receiving PIVs privately, as well as sending and receiving encrypted messages attached to the shield transactions.
More visual information about the protocol can be found at https://pivx.org .

GUI features

New set of functionalities for the interaction with the SHIELD protocol:

• Receive screen modified to show, generate and set label of wallet's shield addresses.
• Dashboard transactions list including shield transactions.
• Top bar showing shield PIV balances.
• Send screen modified, implementing shield transaction crafting and broadcast.
• New encrypted memo functionality.
• Transaction detail dialog presenting shield transaction information.
• Spending process moved to a background thread, loading screen connected while the operation is being performed.
• Contacts screen modified to store external shield addresses.

Wallet

A brand new manager encapsulating all Sapling related capabilities inside the wallet has been implemented:

• New address type: shield addresses (using bech32 format).
• New derivation path for Sapling keys: Shield addresses are derived from the same wallet master seed used for the deterministic derivation of all other keys. The same seed, therefore, can be used to restore both transparent and Shield addresses, recovering both transparent and Shield PIV balance.
• Support for Sapling extended full viewing keys, incoming viewing keys, outgoing viewing keys and spending keys.
• Sapling notes management:
  • Notes decryption.
  • Blockchain scanning protocol: handling when and how to store a Sapling output and its related keys. As well as mark used notes.
  • Notes metadata cache: retrieving information without requiring to decrypt notes on-demand.
  • Able to filter available notes for spending.
• Sapling witnesses and nullifiers tracking.
• New transaction building process, crafting and signing shield transactions.

Block Primitive:

• Block version bumped to 8.
• Starting from block v8, the block header includes an additional uint256 field, hashFinalSaplingRoot (which adds 32 bytes to the end of the serialized block header) storing the root of the Sapling note commitment tree, corresponding to the final Sapling treestate of this block.
• Each block index now is tracking the network total value entering and exiting the shield pool.

Transaction Primitive:

• The "transaction type" concept was introduced, dividing the version field (4 bytes) in version (first 2 bytes) and type (second 2 bytes).
• For transactions with nVersion >= 3, a new optional field sapData has been included, comprising:
  • valueBalance: the net value of Sapling spend transfers minus output transfers
  • vShieldedSpend: a sequence of Sapling spend descriptions
  • vShieldedOutput: a sequence of Sapling output descriptions
  • bindingSig: the Sapling binding signature
• Transactions with nVersion >= 3 and nType != 0(not enabled by consensus at the moment), are defined "special transactions" and must include an extra payload serialized according to the definition imposed by the relative type.
• A new signature hash for Sapling and Special transactions has been implemented (as defined in ZIP-243).

Additional Consensus Rules

• Transactions with version >= 3 must have the new serialization (including a zero byte for empty Optional, if missing sapData or extraPayload).
• Shield transactions cannot be coinbase or coinstake transactions.
• Transactions containing empty vin must have non-empty vShieldedSpend.
• Transactions containing empty vout must have non-empty vShieldedOutput.
• Transactions with version >= 4 are not accepted
• The maximum size of a single Shield transaction is 400 kB.
• The sum of the sizes of all Shield transactions in a block cannot be greater than 750 kB.

Fee Policy

The minRelayTxFee startup argument is multiplied by a fixed factor K = 100 for Shield transactions. This makes the fee required to relay Shield transactions (and "dust" threshold value) 100 times higher than a transparent transaction of the same size.

Build System

In order to support the protocol, the following dependencies are introduced in the build system:

• Sodium https://github.com/jedisct1/libsodium
• Rust/Cargohttps://www.rust-lang.org/

HD Wallet upgrade

In order to support the Shield features, the wallet must be upgraded to SAPLING_VERSION.

How do I check my wallet version?

• Check the output of getinfo or getwalletinfo.
  The "walletversion" field must be equal to 170000 (SAPLING_VERSION)

How do I upgrade my HD wallet to SAPLING_VERSION?

• Newly created wallets have already the latest version
• If the wallet is unlocked, use the -upgradewallet init flag to automatically update at startup.
  Otherwise use the GUI or RPC (see below) to unlock and upgrade the wallet.
• GUI:
  • A dialog will appear on every wallet startup notifying you that you are running a pre-Sapling wallet and letting you upgrade it from there.
  • If you haven't upgraded your wallet, the topbar (bar with icons that appears at the top of your wallet) will have an "HD" icon. Click it and the upgrade dialog will be launched.
• RPC:
  • use the upgradewallet after unlocking the wallet (if locked)

Tier Two Network

A large number of performance and stability improvements over the complete tier two network and masternodes sources have been performed. Re-writing, encapsulating and decoupling workflows, cleaning up an extensive number of redundancies and misalignment.
Plus, tier two and masternodes capabilities have been introduced to regtest, enabling the local testing environment setup and the creation of a functional testing framework for the area.
This work is directly correlated with a substantial efficiency improvement for the entire software, not only for masternodes, and is one of the building blocks for the new tier two network and sync protocol that will be continued post-v5.

Instant Proposal Removal:
The threshold was increased to 30% of negative votes.
The proposal will never be removed before its first superblock.

Maximum Pr...

v4.9.99tr4 - Testing Release for v5

PIVX Core version 4.9.99tr4

This is a new testing release, which includes more fixes and improvements on top of v4.9.99tr3 (the list of PRs merged between tr3 and tr4 can be found in #2107).

Compatibility

This release must be tested on the testnet chain testnet5 (same as with the previous testing release tr3).
Explorer and faucet:
https://testnet.pivx.link
https://faucet.pivx.link

How to Upgrade

Testers should download the appropriate file for their system and extract it to a SEPARATE location from any release versions. Running the included pivx-qt or pivx-qt.exe files will NOT automatically use the testnet5 subdirectory, so you need to add -testnet to any execution command (or add the line testnet=1 in the pivx.conf file).

Additionally, these binaries were compiled using the upcoming sapling params. Linux and MacOS users can run the included install-params.sh terminal script. Windows users can manually copy the two params files included in the zip (share/pivx) to the appropriate AppData directory (%APPDATA%\PIVXParams).

Note: Windows installer packages, and macOS .dmg binaries, are NOT included here so as to avoid potentially overwriting a pre-existing production release version installation. Use the Windows zip or osx64 files instead.

v4.9.99tr3 - Testing Release for v5

PIVX Core version 4.9.99tr3

This is a new testing release, which includes various bug fixes, performance improvements and consensus changes from its predecessor v4.9.99tr2. (The list of PRs merged between tr2 and tr3 can be found in #2078)

Compatibility

A new testnet has been deployed. testnet5 is fully available and ready for public use. As the network is brand new, users with tPIVs on testnet4 (previous releases) will not have them on this new network.
A new wallet will automatically be created running this new version. To watch the network stats and get tPIVs, can find the new explorer and faucet in the following links:
https://blockbook-testnet.pivx.link
https://faucet.pivx.link

How to Upgrade

Testers should download the appropriate file for their system and extract it to a SEPARATE location from any release versions. Running the included pivx-qt or pivx-qt.exe files will NOT automatically use the testnet5 subdirectory, so you need to add -testnet to any execution command (or add the line testnet=1 in the pivx.conf file).

Additionally, these binaries were compiled using the upcoming sapling params. Linux and MacOS users can run the included install-params.sh terminal script. Windows users can manually copy the two params files included in the zip (share/pivx) to the appropriate AppData directory (%APPDATA%\PIVXParams).

Note: Windows installer packages, and macOS .dmg binaries, are NOT included here so as to avoid potentially overwriting a pre-existing production release version installation. Use the Windows zip or osx64 files instead.

v4.9.99tr2 - Testing Release for v5

Only for testnet
Testers should download the appropriate file for their system and extract it to a SEPARATE location from any release versions. Running the included pivx-qt or pivx-qt.exe files will NOT automatically use the testnet4 subdirectory, so you need to add -testnet to any execution command (or add the line testnet=1 in the pivx.conf file).

Additionally, these binaries were compiled using the upcoming sapling params. Linux and MacOS users can run the included install-params.sh terminal script. Windows users can manually copy the two params files included in the zip (share/pivx) to the appropriate AppData directory (%APPDATA%\PIVXParams).

Note: Windows installer packages, and macOS .dmg binaries, are NOT included here so as to avoid potentially overwriting a pre-existing release version installation. Use the Windows zip or osx64 files instead.

v4.3.0

PIVX Core version 4.3.0 is now available from: https://github.com/pivx-project/pivx/releases

This is a new major version release, including various bug fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github: https://github.com/pivx-project/pivx/issues

Recommended Update

This version is an optional, but recommended, update for all users and services.

How to Upgrade

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/PIVX-Qt (on Mac) or pivxd/pivx-qt (on Linux).

Downgrading warning

The chainstate database for this release is not compatible with previous releases, so if you run 4.3.0 and then decide to switch back to any older version, you will need to run the old release with the -reindex option to rebuild the chainstate data structures in the old format.

Compatibility

PIVX Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Apple released it's last Mountain Lion update August 13, 2015, and officially ended support on December 14, 2015. PIVX Core software starting with v3.2.0 will no longer run on MacOS versions prior to Yosemite (10.10). Please do not report issues about MacOS versions prior to Yosemite to the issue tracker.

PIVX Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable Changes

Performance Improvements

Version 4.3.0 contains a number of significant performance improvements, which make Initial Block Download, startup, transaction and block validation much faster:

• The chainstate database (which is used for tracking UTXOs) has been changed from a per-transaction model to a per-output model (See PR 1801). Advantages of this model are that it:

  • avoids the CPU overhead of deserializing and serializing the unused outputs;
  • has more predictable memory usage;
  • uses simpler code;
  • is adaptable to various future cache flushing strategies.

  As a result, validating the blockchain during Initial Block Download (IBD) and reindex is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently. The only downside is that the on-disk database is 15% larger. During the conversion from the previous format a few extra gigabytes may be used.

• LevelDB has been upgraded to version 1.22 (See PR 1738). This version contains hardware acceleration for CRC on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.

Removal of Priority Estimation

Estimation of "priority" needed for a transaction to be included within a target number of blocks has been removed. The rpc calls are deprecated and will either return -1 or 1e24 appropriately.

The format for fee_estimates.dat has also changed to no longer save these priority estimates. It will automatically be converted to the new format which is not readable by prior versions of the software.

Dedicated mnping logging category

mnping related debug log messages have been moved to their own category of the same name. This is to reduce log spam when debugging with the masternode category enabled.

RPC Changes

Modified input/output for existing commands

• The new database model no longer stores information about transaction
  versions of unspent outputs. This means that:
  • The gettxout RPC no longer has a version field in the response.
  • The gettxoutsetinfo RPC reports hash_serialized_2 instead of hash_serialized,
    which does not commit to the transaction versions of unspent outputs, but does
    commit to the height and coinbase/coinstake information.
  • The getutxos REST path no longer reports the txvers field in JSON format,
    and always reports 0 for transaction versions in the binary format
• Three filtering options for the getbalance command have been reinstated:
  • minconf (numeric) Only include transactions confirmed at least this many times.
  • includeWatchonly (bool) Also include balance in watchonly addresses.
  • includeDelegated (bool) Also include balance delegated to cold stakers.
• estimatefee is now deprecated and replaced by estimatesmartfee:
  • Input argument is the same for estimatesmartfee.
  • Output is now a JSON object with 2 fields: feerate and blocks
• The getrawmempool RPC command now includes an additional output field:
  • modifiedfee (numeric) transaction fee with fee deltas used for mining priority.::ZZZZexit

Removed commands

The following commands have been removed from the interface:

• estimatepriority

4.3.0 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

Core Features

• #1666 5a092159f6 [Core] Base work for the Sapling signatureHash (furszy)
• #1746 128978d45b [Core] Only include undo.h from main.cpp (random-zebra)
• #1768 6881e1063f [Core] Use SipHash-2-4 for various non-cryptographic hashes (Pieter Wuille)
• #1771 bda654c5f3 [Core] Use SipHash for node eviction (Pieter Wuille)
• #1773 90ffc6683b [Core] per-txout model preparation (random-zebra)
• #1774 68df9a7d5b [Core] Alter assumptions in CCoinsViewCache::BatchWrite (random-zebra)
• #1775 85b5f2eb83 [Core] Remove BIP30 check (random-zebra)
• #1777 3c767c46b5 [Core] ModifyNewCoins saves database lookups (random-zebra)
• #1788 823ba8e334 [Core] Remove priority estimation (random-zebra)
• #1793 af793b7bb9 [Core] Safer modify new coins (Russell Yanofsky)
• #1795 afafd7f6a9 [Core] Use unordered_map for CCoinsMap and fix empty vectors in streams (Pieter Wuille)
• #1799 fcb546ad05 [Core] Remove UTXO cache entries when the tx they were added for is removed (Pieter Wuille)
• #1801 30d353edab [Core] Per-txout model for chainstate database (random-zebra)
• #1804 5c8b992033 [Core] Use std::unordered_{map,set} (C++11) instead of boost::unordered_* (random-zebra)

GUI

• #1754 93d574170d [Model] Wallet interface refactor + code cleanup. (furszy)
• #1776 2ad27b1407 [Model] TransactionRecord decomposeTransaction refactoring (furszy)
• #1782 ada4462782 [GUI] Start masternodes polling timer only when is needed. (furszy)
• #1805 f0cc6fcc38 [BUG][GUI] Don't append cold-stake records twice (random-zebra)
• #1863 ad15bce2f5 [Trivial][GUI] Fix init messages (random-zebra)

Wallet

• #1752 2e32285a70 [Wallet] Simple unused methods cleanup. (furszy)
• #1755 eeb129b477 [wallet] List COutput solvability + wallet_ismine refactoring. (furszy)
• #1757 e2cc4aa411 [Wallet] add cacheable amounts for caching credit/debit values (furszy)
• #1759 dcc92f8157 [Wallet] AvailableCoins remove duplicated watchonly config argument. (furszy)
• #1760 3b030f9978 [Wallet] AvailableCoins code readability improved (furszy)
• #1764 6847d0d648 [Wallet] Securely erase potentially sensitive keys/values (Thomas Snider)
• #1767 8ab63d3e5b [Wallet] Ignore MarkConflict if block hash is not known (random-zebra)
• #1781 4715915d4c [Wallet] Acquire cs_main lock before cs_wallet during wallet initialization (random-zebra)
• #1783 abf7c62934 [Wallet] Do not try to resend transactions if the node is importing or in IBD (furszy)
• #1787 4b1f3eb792 [Wallet] Improve usage of fee estimation code (random-zebra)
• #1802 7db7724cff [Wallet] Make nWalletDBUpdated atomic to avoid a potential race (furszy)
• #1810 49bd99929d [Wallet] wtx cached balances test coverage + getAvailableCredit problem fix. (furszy)
• #1811 e89e20eca1 [Wallet][Refactoring] wallet/init refactoring backports (random-zebra)
• #1817 6480c7d9bf [Wallet] Speedup coinstake creation removing redundancies. (furszy)
• #1832 c14d130b48 [Wallet] Cleanup getbalance methods that are not fulfilling any purpose. (furszy)

P2P Protocol and Network Code

• #1769 1e334200bb [Net] Remove bogus assert on number of oubound connections. (Matt Corallo)
• #1780 5fcad0c139 [Net] cs_vSend-cs_main deadlock detection fixed. (furszy)
• #1800 616b102f8b [P2P] Improve AlreadyHave (Alex Morcos)
• #1812 777638e7bc [P2P] Begin Network Encapsulation (random-zebra)
• #1835 cbd9271afb [Net] Massive network refactoring and speedup (Fuzzbawls)

RPC/REST

• #1753 e288a4508b [Trivial] [RPC] Fix listcoldutxos help text (JSKitty)
• #1828 4fc36b59ee [RPC][BUG] Fix ActivateBestChain calls in reconsider(invalidate)block (random-zebra)
• #1831 28509bf9e8 [RPC] re introducing filtering args in getbalance (furszy)

Build Systems

• #1553 fddf765132 [Build] Sapling Foundations (Build System + ZIP32) (furszy)
• #1703 2e11030e8b [Build] Require minimum boost version 1.57.0 (Fuzzbawls)
• #1738 21c467b1eb [Build] Update leveldb to 1.22+ (Fuzzbawls)
• #17...

v4.3.0rc1

First release candidate for the upcoming 4.3.0 release.

Full, finalized release notes will be available with the final release version.

v4.2.1rc1

First release candidate for the upcoming 4.2.1 release.

Full, finalized release notes will be available with the final release version.

v4.2.0

PIVX Core version 4.2.0 is now available from: https://github.com/pivx-project/pivx/releases

This is a new major version release, including various bug fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github: https://github.com/pivx-project/pivx/issues

Recommended Update

This version is an optional, but recommended, update for all users and services.

How to Upgrade

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/PIVX-Qt (on Mac) or pivxd/pivx-qt (on Linux).

Compatibility

PIVX Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Apple released it's last Mountain Lion update August 13, 2015, and officially ended support on December 14, 2015. PIVX Core software starting with v3.2.0 will no longer run on MacOS versions prior to Yosemite (10.10). Please do not report issues about MacOS versions prior to Yosemite to the issue tracker.

PIVX Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable Changes

Removed zerocoin GUI

Spending zPIV and getting zPIV balance information is no longer available in the graphical interface (#1549). The feature remains accessible through the RPC interface: getzerocoinbalance, listmintedzerocoins, listzerocoinamounts, spendzerocoin, spendzerocoinmints.

Memory pool limiting

Previous versions of PIVX Core had their mempool limited by checking a transaction's fees against the node's minimum relay fee. There was no upper bound on the size of the mempool and attackers could send a large number of transactions paying just slighly more than the default minimum relay fee to crash nodes with relatively low RAM.

PIVX Core 4.2.0 will have a strict maximum size on the mempool. The default value is 300 MB and can be configured with the -maxmempool parameter. Whenever a transaction would cause the mempool to exceed its maximum size, the transaction that (along with in-mempool descendants) has the lowest total feerate (as a package) will be evicted and the node's effective minimum relay feerate will be increased to match this feerate plus the initial minimum relay feerate. The initial minimum relay feerate is set to 1000 satoshis per kB.

PIVX Core 4.2.0 also introduces new default policy limits on the length and size of unconfirmed transaction chains that are allowed in the mempool (generally limiting the length of unconfirmed chains to 25 transactions, with a total size of 101 KB). These limits can be overridden using command line arguments (#1645, #1647).

Benchmarking Framework

PIVX Core 4.2.0 backports the internal benchmarking framework from Bitcoin Core, which can be used to benchmark cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160, Poly1305, ChaCha20), Base58 encoding and decoding and thread queue. More tests are needed for script validation, coin selection and coins database, cuckoo cache, p2p throughtput (#1650).

The binary file is compiled with pivx-core, unless configured with --disable-bench.

After compiling pivx-core, the benchmarks can be run with:

src/bench/bench_pivx

The output will be similar to:

#Benchmark,count,min(ns),max(ns),average(ns),min_cycles,max_cycles,average_cycles
Base58CheckEncode,131072,7697,8065,7785,20015,20971,20242

'label' and 'account' APIs for wallet

A new 'label' API has been introduced for the wallet. This is intended as a
replacement for the deprecated 'account' API. The 'account' can continue to
be used in v4.2 by starting pivxd with the '-deprecatedrpc=accounts'
argument, and will be fully removed in v5.0.

The label RPC methods mirror the account functionality, with the following functional differences:

• Labels can be set on any address, not just receiving addresses. This functionality was previously only available through the GUI.
• Labels can be deleted by reassigning all addresses using the setlabel RPC method.
• There isn't support for sending transactions from a label, or for determining which label a transaction was sent from.
• Labels do not have a balance.

Here are the changes to RPC methods:

Deprecated Method	New Method	Notes
getaccount	getaddressinfo	getaddressinfo returns a json object with address information instead of just the name of the account as a string.
getaccountaddress	n/a	There is no replacement for getaccountaddress since labels do not have an associated receive address.
getaddressesbyaccount	getaddressesbylabel	getaddressesbylabel returns a json object with the addresses as keys, instead of a list of strings.
getreceivedbyaccount	getreceivedbylabel	no change in behavior
listaccounts	listlabels	listlabels does not return a balance or accept minconf and watchonly arguments.
listreceivedbyaccount	listreceivedbylabel	Both methods return new label fields, along with account fields for backward compatibility.
move	n/a	no replacement
sendfrom	n/a	no replacement
setaccount	setlabel	Both methods now: allow assigning labels to any address, instead of raising an error if the address is not receiving address. delete the previous label associated with an address when the final address using that label is reassigned to a different label, instead of making an implicit getaccountaddress call to ensure the previous label still has a receiving address.

Changed Method	Notes
listunspent	Returns new label fields, along with account fields for backward compatibility if running with the -deprecatedrpc=accounts argument
sendmany	The first parameter has been renamed to dummy, and must be set to an empty string, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
listtransactions	The first parameter has been renamed to dummy, and must be set to the string *, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
getbalance	account, minconf and include_watchonly parameters are deprecated, and can only be used if running with the -deprecatedrpc=accounts argument
getcoldstakingbalance	The account parameter is deprecated, and can only be used if running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged)
getdelegatedbalance	The account parameter is deprecated, and can only be used if running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged)

GUI Changes

Topbar navigation

• The "sync" button in the GUI topbar can be clicked to go directly to the Settings --> Information panel (where the current block number and hash is shown).

• The "connections" button in the GUI topbar can be clicked to open the network monitor dialog (#1688).

Functional Changes

Stake-Split threshold

If the stake split is active (threshold > 0), then stake split threshold value must be greater than a minimum, set by default at 100 PIV. The minimum value can be changed using the -minstakesplit startup flag (#1586). A value 0 is still allowed, regardless of the minimum set, and, as before, can be used to disable the stake splitting functionality.

Changed command-line options

• new command -minstakesplit to modify the minimum allowed for the stake split threshold (#1586).

• new commands -maxmempool, to customize the memory pool size limit, and -checkmempool=N, to customize the frequency of the mempool check (#1647).

• new commands -limitancestorcount=N and limitancestorsize=N, to limit the number and total size of all in-mempool ancestors for a transaction (#1647).

• new commands -limitdescendantcount=N and limitdescendantsize=N, to limit the number and total size of all in-mempool descendants for a transaction (#1647).

RPC Changes

In addition to the afore mentioned 'label' and 'account' API changes, other RPC changes are as follows:

Low-level API changes

• The asm property of each scriptSig now contains the decoded signature hash type for each signature that provides a valid defined hash type ([#1633](https...

v4.2.0rc1

First release candidate for the upcoming 4.2.0 release.

Full, finalized release notes will be available with the final release version, until then, you can view the draft, in-progress release notes at https://github.com/PIVX-Project/PIVX/blob/4.2/doc/release-notes.md

v4.1.1

PIVX Core version 4.1.1 is now available from: https://github.com/pivx-project/pivx/releases

This is a new minor version release, including various bug fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github: https://github.com/pivx-project/pivx/issues

Mandatory Update

PIVX Core v4.1.1 is a mandatory update for all users. This release contains new consensus rules and improvements that are not backwards compatible with older versions. Users will need to update their clients before enforcement of this update goes into effect.

Update enforcement is currently scheduled to go into effect at the following time:

Mainnet: Friday, June 5, 2020 9:00:00 PM GMT

Masternodes will need to be restarted once both the masternode daemon and the controller wallet have been upgraded.

How to Upgrade

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/PIVX-Qt (on Mac) or pivxd/pivx-qt (on Linux).

Compatibility

PIVX Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Apple released it's last Mountain Lion update August 13, 2015, and officially ended support on December 14, 2015. PIVX Core software starting with v3.2.0 will no longer run on MacOS versions prior to Yosemite (10.10). Please do not report issues about MacOS versions prior to Yosemite to the issue tracker.

PIVX Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable Changes

We have identified and fixed Layer 2 check that was causing some nodes to disagree on Masternode winners list and thus resulted in these nodes forking.

Credits

Thanks to everyone who directly contributed to this release:

• Fuzzbawls
• furszy
• random-zebra

As well as everyone that helped translating on Transifex, the QA team during Testing and the Node hosts supporting our Testnet.