ardor-client-2.2.5, released 2019-06-16:

This is a bugfix release, addressing an issue with the Standby Shuffler add-on.
The recipient public keys were incorrectly generated with an \r character
appended to the user-supplied secret phrases, resulting in actual recipient
accounts different from what was displayed in the UI.

For users of the Standby Shuffler add-on who already had their shuffling
recipient account affected by this issue, a simple RecoverFunds API has been
added. Use that API with the secretPhrase of the intended shuffling recipient
account to automatically transfer your shuffled coins to the correct recipient.

Fixed version update hash validation.


--------------------------------------------------------------------------------
ardor-client-2.2.4, released 2019-06-13:

This release introduces the StandbyShuffler add-on, a new feature intended to
simplify the use of our flagship privacy feature, fully decentralized and
trustless Shuffling.

A StandbyShuffler, as opposed to a regular Shuffler, does not start a new
shuffling immediately, but runs in the background and waits for other users to
start a shuffling which matches the StandbyShuffler parameters - holding (coin,
asset or currency), minimum and maximum amounts, and number of participants.
When such a shuffling is created, the StandbyShuffler joins it automatically. A
StandbyShuffler is configured on start with a number of recipient public keys
to use as recipients in each shuffling it joins, and shuts down once all have
been used.

Running a StandbyShuffler requires a full node, not just a light client.
To enable the StandbyShuffler add-on, add nxt.addons.StandbyShuffling to the
list of enabled add-ons in the nxt.addOns property. This add-on registers three
new APIs:

StartStandbyShuffler - start a StandbyShuffler. The secretPhrase of the
shuffling account must be supplied. The holdingType and holding parameters
define the coin, asset or currency for which to listen for shufflings being
started. The optional minAmount, maxAmount and minParticipants parameters can
be used to limit which shufflings to join. The recipientPublicKeys parameter
holds one or more public keys, used one at a time as a recipient account public
key each time a shuffling is joined. This can be specified either as a multi-
value parameter, or a single text value holding multiple public keys separated
by newlines. The feeRateNQTPerFXT parameter specifies what rate to use when
calculating the child chain fees for each shuffling transaction submitted.
Since the market rate can change between when the StandbyShuffler is started
and an actual shuffling is joined, one should use a high enough rate to make
sure shuffling transactions of the StandbyShuffler account are always bundled.

GetStandbyShufflers - returns a list of all StandbyShufflers running on the
node, optionally filtered using holdingType, holding and account parameters.
If not running locally, a secretPhrase or admin password are required.

StopStandbyShuffler - stops the StandbyShuffler for a specified account and
holding or all StandbyShufflers running on the node if account is not
specified. If not running locally, a secretPhrase or admin password are
required.

An UI for starting, observing, or stopping StandbyShufflers has been added
under Shuffling / My StandbyShufflers.

To automate starting the configured StandbyShufflers when the node is
restarted, a set of StartStandbyShuffling, SaveStandbyShufflingEncrypted, and
StartStandbyShufflingEncrypted add-ons has been provided.

StartStandbyShuffling automatically starts one or more StandbyShufflers as
defined in a file set in the nxt.startStandbyShufflingFile property. The
format of this JSON file is the same as the JSON output of GetStandbyShufflers,
with secretPhrase field added for each StandbyShuffler, thus the simplest way
to generate it is first to setup StandbyShufflers as required and then save
and edit the GetStandbyShufflers response.

Alternatively, to avoid keeping the secretPhrase and recipient public keys in
a plain text file, the SaveStandbyShufflingEncrypted add-on can be used to save
the StandbyShufflers configuration JSON in an encrypted file, and the
StartStandbyShufflingEncrypted add-on to start them by submitting the
decryption password through the API.


Added ChangeNOW as an integrated exchange in the wallet, allowing exchange of
Ignis and Ardor to any coin supported by ChangeNOW.

Permanently disallowed outgoing transactions from the new @ArdorBurnAccount,
see announcement at https://www.jelurida.com/ardor-burn-account

Pause forging if there are not enough connected peers from which to download
the blockchain, as defined in nxt.numberOfForkConfirmations or
nxt.testnetNumberOfForkConfirmations, unless nxt.isOffline=true. This is to
avoid building a fork if the node is temporarily disconnected. To disable this
behavior, set nxt.pauseForgingOnNoConnection=false (default is true).

Do not allow accounts under account control to start a Funding Monitor.

The SaveBundlingEncrypted, SaveForgingEncrypted, SaveFundingMonitorEncrypted
APIs now require admin password when running on a remote node.

Added a list of full transaction hashes with chain ids to the response of the
getUnconfirmedTransactionIds API.

Added a new bundling filter, nxt.addons.TransactionTypeBundler, which bundles
only transactions of the transaction types specified in the filter parameter.
The parameter must be a comma separated list of <type>:<subtype> pairs with
the "type" and "subtype" of the whitelisted transaction types.

Improved propagation of bundler rates between peers and calculation of best
bundler rates. The CalculateFee, GetBundlerRates, and all CreateTransaction
APIs now take both minBundlerBalanceFXT and minBundlerFeeLimitFQT parameters,
with defaults based on the nxt.minBundlerBalanceFXT (default 1000 ARDR) and
nxt.minBundlerFeeLimitFXT (default 10 ARDR) properties.
Bundlers with effective balance lower than minBundlerBalanceFXT, or remaining
fee limit or available ARDR balance lower than minBundlerFeeLimitFQT, are
excluded from the best rates calculation.

Shamir secret sharing passphrases can now be used to sign transaction
vouchers.

Updated Jetty to version 9.4.18. This release fixes a Jetty bug which causes
a server hang after high load, therefore an update is highly recommended.

The Jelurida Public License has been updated to version 1.2, to clarify that
Ardor code is not portable to Nxt clones unless the JPL requirements for Ardor
are also satisfied (article 3.4.2 of the General Conditions), and to require
that airdrops, including the fact that they are done in order to satisfy the
JPL, are announced at least a month before the planned snapshot date (article
2.2 of the Special Conditions).


--------------------------------------------------------------------------------
ardor-client-2.2.3, released 2019-04-23:

This release adds multiple usability enhancements, optimizations and bug fixes.
For users of 2.2.1 or 2.2.2, upgrade is optional but highly recommended.

New feature: Shamir Secret Sharing

Shamir Secret Sharing support is now enabled for both client and server. It
allows splitting a passphrase into N pieces out of which only K are required to
restore the original secret. This technique is useful to protect the full
passphrase from key loggers on the client workstation and from eavesdropping
during transport to a remote node. Shamir Secret Sharing is also useful for the
creation of fragmented backups, by storing each piece in a different physical
place or with a different trusted party, with at least K of them required to
recover the full passphrase.

Secret share splitting and combining is supported both on the server side using
the node APIs, and client side in the wallet, so that secrets split on one side
can be combined on the other.

Client side

When printing a paper wallet, a new dialog enables setting the total number of
secret pieces to generate from a passphrase, and the number of secrets required
to re-combine a passphrase. These secrets are then printed into separate pages
of the paper wallet.

For all dialogs which accept entry of a passphrase the user can now check the
"Shared Secret" checkbox, then enter or scan the required number of secret
pieces to combine the original passphrase in memory.

Server side

Any API which accepts the "secretPhrase" parameter can now accept instead 
multiple "sharedPiece" parameters which the node will combine into the original
passphrase in memory. A node can keep some of the secrets in its configuration
file while accepting other secrets using API parameters.
To configure this setup for account address X, split your passphrase into 
several pieces then list some of the pieces in a semicolon separated list as the
value of the property nxt.secretPhrasePieces.X. When using the API, submit the
parameter sharedPieceAccount=X where X is the account address, and also submit
the remaining required pieces using multiple sharedPiece parameters. This
configuration enables to start forging, bundling, etc, on a remote node without
ever transmitting the full account passphrase to it over the internet.

New APIs for Shamir Secret Sharing:

Use the splitSecret API to split a passphrase into pieces.

Use the combineSecret API to combine secret pieces to the original passphrase.


Contracts

Due to enhancements to the underlying API caller infrastructure all lightweight
contracts have to be recompiled and redeployed in order for a contract runner
running this version to be able to execute them correctly.

Any other code using the API callers must also be recompiled.


Installation

The Windows and Mac installers now bundle a copy of OpenJDK 11 and Java FX sdk.
OpenJDK is installed into the jdk folder.
Java FX is installed into the javafx-sdk folder.
The jre folder which included the Java distribution in previous releases is no 
longer created by the installation.
Users who created customized scripts relying on the jre folder should adjust 
their scripts to the new structure.
For the linux installation package, the code is compiled with OpenJDK 8, and
can still be run under either Java 8, or Java 11 or 12. For Windows and Mac,
the installation package is compiled using Java 11.


UI improvements

When loading a transaction voucher it is now possible to attach an encrypted
message to yourself, and to recalculate the transaction fee. It is now also
possible to not immediately broadcast voucher transaction, for the purpose of
offline signing.

The coin exchange displays the inverse rate in the "Buy" dialog, and as a 
tooltip when hoovering with the mouse over any price field.
Expected orders and order cancellations (unconfirmed or phased) are displayed
in the order book with a special icon to their left.
Left pane balances are updated with each new block. 
The order of columns was changed so that the "Sum" column displays the coin to 
buy, clicking the "Sum" column updates the amount to buy accordingly.
Red warning is displayed when typing an amount to buy which requires larger 
balance than the available balance. Total field is limited to 8 decimals.

The dashboard transaction view was improved to reduce appearances of duplicate
transactions when the transaction moves from unconfirmed to confirmed status.

Support login by alias and recipient alias for any alias. If not an account
alias, map the alias to the alias owner account. Since any alias owned by an
account can now be used as an alias to the account, this release deprecates
the so-called "account" aliases, and we will remove support for them in the
next release.

Approximate leasing expiration date is displayed in the Account Leasing tab.

A new Account Properties tab has been added to the account info modal,
displaying all properties set on the account.


Networking and performance improvements.

As a result of our extensive load testing efforts, this release includes
several networking stability improvements and performance optimizations.


New add-ons to simplify automated and secure running of tasks on remote nodes:

A set of custom add-ons to automate forging, bundling, and funding monitors
has been include in this release.

The StartForging add-on reads the passphrases stored in a plain text file, as
defined in the property nxt.startForgingFile, one passphrase per line, and
automatically starts forging with each of these accounts when the server is
started. Since passphrases are stored unencrypted, this add-on should only
be used on well secured servers, or with accounts of insignificant value, or
in test environments.

For a secure way of starting forging with multiple accounts on a remote server,
the SaveForgingEncrypted add-on can be used to store the passphrases of forging
accounts in an encrypted file, and the StartForgingEncrypted add-on to start
forging with them by only submitting to the server the password necessary to
decrypt this file. Note that at runtime, the forging account passphrases will
still be kept in server memory, but when using these add-ons will never need to
be stored on disk, and will not need to be re-submitted to the server each time
forging needs to be started. These add-ons are useful when forging on a fully
trusted node, and having to restart forging remotely without a risk of exposing
the passphrases in transit.

The StartBundling add-on reads a list of Bundlers stored in a JSON formatted
file, as defined in the property nxt.startBundlingFile. The exact JSON can be
initially generated by manually starting the bundlers configured as desired,
including any custom bundling rules, and using the GetBundlers API to retrieve
the list of bundlers in JSON format. The only manual modification required is
to add a "secretPhrase" parameter to the JSON for each bundler, with the
corresponding account secret phrase. On server start, the StartBundling add-on
will automatically start all bundlers as configured.

Similarly to the above forging add-ons, the SaveBundlingEncrypted and
StartBundlingEncrypted add-ons can be used to store the JSON configuration of
bundlers in an encrypted instead of plain text file, and start the bundlers
on submitting the decryption password to the server.

Finally, for automating funding monitors, the StartFundingMonitors add-on will
automatically start all funding monitors configured in a JSON formatted file,
as defined in the property nxt.startFundingMonitorsFile. The JSON can be
generated by manually starting the funding monitors as desired, and using the
GetFundingMonitor API to retrieve the list of monitors in JSON format. Again,
the secretPhrase parameter needs to be manually added to the JSON for each
funding monitor.

The SaveFundingMonitorsEncrypted and StartFundingMonitorsEncrypted add-ons
allow storing the JSON configuration of funding monitors in an encrypted
instead of plain text file, and starting the funding monitors by submitting
only the decryption password to the server.


Other improvements:

The CalculateFee API now also returns the required child chain fee based on
the best bundling rate available, as feeNQT.

The JPLSnapshot add-on has been ported to Ardor. It can be used to generate
a JPL-compliant snapshot of Ignis child chain balances.

Starting a funding monitor or shuffler with feeRateNQTPerFXT=0 is now allowed.


Library updates:

Updated Jetty to version 9.4.17, Bouncy Castle to 1.61, and H2 database to
1.4.199. With the new H2 release, using MVStore mode is the default. However,
conversion of existing databases to MVStore format is not automatic. To
migrate to the new storage format, the easiest way is to use the compact.sh
or compact.bat script, which should take a few minutes, and will also improve
the database performance.


--------------------------------------------------------------------------------
ardor-client-2.2.2:

This is a bug fix and usability enhancements release.

Users still using version 2.2.0e or earlier must upgrade immediately as they are
already on a fork, and their nodes are blacklisted by this release.

Anyone who did not upgrade to 2.2.1 prior to block 543000 must manually delete
and re-download the blockchain from scratch, after upgrading.

Users using version 2.2.1 are not required to upgrade.


Contracts:

Added an includeContract parameter to the getContractReferences API to return
metadata about the actual contract being referenced.

The contract runner now removes the last block when started to make sure 
trigger transactions in the last block are processed in case processing stopped 
before processing the contracts for this block.

Contract unit tests now use simpler methods for verifying transactions submitted 
by a contract.

The contract manager now waits until the transactions it submitted are included
in a new block before exiting.

Contracts with an inner interface and an inner class implementing it are now
supported.

The contract processRequest callback now supports initializing a randomness 
source and accessing the last block.

Fail gracefully when a contract submits the messageToEncrypt parameter without a
passphrase. Contract devs should encrypt the message first then submit the
encrypted data.


UI Enhancements:

Contract selection widget and contract parameter specification template were 
added to dialogs which specify a recipient field. This enhancement simplifies 
the task of configuring a contract trigger transaction.

The Contracts page now provides simple runtime statistics about contract 
execution when clicking on any of the invocation types in the Invocation column.

Each chain now has a chain description displayed in the wallet and when 
switching between chains.

Login by account using an Ignis alias is now supported by deleting the ARDOR 
prefix then typing '@' in front of an existing alias name which is mapped to an
account id.

"Fat Finger" warning for amount and fee is now defined and enforced per chain.
Reasonable default values were defined.
Use the account settings page to adjust these values for the current chain.

Dialogs now support more than one warning per form submit. 
For example in case both the amount and the fee are too high, both warnings are 
displayed one after the other.

The wallet no longer warns about assets and currencies with more than 6 
decimals.

The Changelly menu items was moved from a top level menu to the settings menu to
provide more screen real estate for the mobile app.

Increase and delete shares links are displayed in the "My Assets" page only when
these actions are allowed.

Vouchers with unicode parenthesis are now parsed correctly.

The desktop wallet now displays a file chooser dialog before downloading a cloud 
data item or message attachment to the local workstation.

The transaction and block info dialogs now display the raw transaction and block
json in a separate tab.

Coin exchange layout improvements.


Others:

Fixed an initialization issue that could cause some custom add-ons to deadlock
on start. 

Fixed false positive unsigned bytes verification error when cancelling
ARDR buy order.

The getPeers and dumpPeers APIs now also allow filtering by version, optionally
including newer versions.

Added a checkpoint at block 545555.

Updated Jetty to version 9.4.14.


--------------------------------------------------------------------------------
ardor-client-2.2.1:

This release adds support for the new Max Crowdfund (formerly Dominium) child
chain, token name MPG, to be activated at block 543000 expected to be reached on
January 10, 2019.

At the same block, the new Lightweight Contracts and Asset Properties features
will also become enabled on mainnet.

Transactions with asset 6066975351926729052 (old CtC) will be disabled and open
orders cancelled.

Revealing a secret using the ApproveTransaction API will now approve all phased 
by hash transactions which specified the hash of this secret regardless if they
are listed in the phasedTransaction parameter or not.

A new GetHashedSecretPhasedTransactions API will return a list of phased by hash
transactions with phasingHashedSecret and phasingHashedSecretAlgorithm as 
specified.

This is a stable release and a mandatory upgrade for all nodes, with block
543000 (Jan 10) as final deadline.


Lightweight Contracts:

Contract validations now use Java annotations. The following annotations are
available:
@ValidateContractRunnerIsRecipient - checks that the contract runner account is 
the recipient of the trigger transaction.
@ValidateContractRunnerIsSender - checks that the contract runner account is the
sender of the transaction.
@ValidateChain - checks that the chain of the trigger transaction is in the 
accept array and is not in the reject array.
@ValidateTransactionType - checks that the type of the trigger transaction is 
one of the types in the accept array and is not one of the types in the reject
array. A new TransactionTypeEnum class lists all available transaction types and 
sub types.

See the HelloWorldForwarder sample contract for usage example of the validations

The contract runner getSupportedContracts API was enhanced to return more meta-
data about the running contracts including the supported invocation types,
contract invocation parameters, and contract validations. 
This information can be used by clients to provide better user experience by 
analyzing the contract capabilities and helping the user properly trigger the 
contract. 

Contracts can override the built-in duplicate checks for transactions submitted 
by a contract by overriding the isDuplicate() method. 
Oracle contracts should implement this method to make sure they do not submit 
the same transaction more than once with different data. 
See for example the IgnisArdorRates contract.

Added uploadContractRunnerConfiguration API to let contract runner node admin 
upload the contract runner config after starting the node. 
This way contract runner nodes no longer need to store the contract runner 
account passphrase or other sensitive data on the node itself. 
Instead, they can upload it after starting the node from the contracts page in 
the wallet. The format of the uploaded configuration file is the same as the
existing contracts.json format.

To prevent a contract runner from locking user funds permanently in the contract 
runner account in case the contract does not execute, contract transactions can
be submitted with phasing by hashed secret. The contract runner will submit its
own transactions using the same hashed secret and other phasing parameters.
The trigger transaction, and transactions submitted by the contract in response,
are either approved together or rejected together. 
If a transaction is not approved when reaching its finish height, its funds are 
released back to the sender.

To assist with generating secure secrets to hash, a new secret generator wizard
was added to the wallet approval modals dialog. Generated secrets are not saved 
by the client.
A secret can be reproduced by the client in case it was lost, using the account
passphrase used when generating it.

The parameter injection introduced in version 2.2.0e was replaced with a more
robust solution based on an interface. In the new design, invocation, setup and 
runner parameters are defined using an inner interface decorated with the 
@ContractParametersProvider annotation. 
For each contract parameter create a default method which defines its name, 
data type and default value, decorated with a contract parameter annotation:
@ContractInvocationParameter - specified by a trigger transaction or voucher.
@ContractSetupParameter - specified by the contract reference.
@ContractRunnerParameter - specified by the contract runner configuration.
To load the contract parameters from inside your contract code use the following
statement:
Params params = context.getParams(Params.class);
Where Params is the inner interface decorated with @ContractParametersProvider 
annotation.

Due to interface changes introduced by this release, all existing contracts will
have to be redeployed on testnet and contract runners using a previous version
won't be able to run contracts deployed using the current version.


UI Enhancements:

A contracts page was added to the wallet to list the information provided by 
the getSupportedContracts API. This page is available only when the wallet is 
connected to a contract runner node.

Asset properties UI was implemented accessible from the "Asset Properties" link
on the asset exchange page. Users can use it to set, update, and delete asset
properties.

When entering recipient address in the client wallet use the @ prefix to point 
to an existing Ignis alias which stores the account id. In previous versions the
alias was loaded from the current chain.

The contacts button to the right of the recipient field now lists all the 
remembered accounts in addition to the defined contacts.


Updating to this release from 2.2.0e may cause a one time shutdown on first
start in order to fully apply the database changes.


--------------------------------------------------------------------------------
ardor-client-2.2.0e:

This is an experimental release, and a MANDATORY upgrade for all testnet nodes.
It can also be used on mainnet.

Added Asset Properties feature, to be activated at block 455000 on testnet only.

Asset Properties allow attaching metadata to assets, in the form of name/value
pairs. The property name can be up to 32 characters, and property value up to
160 characters in length. Anyone can set a property on an asset. Only the asset
issuer, or the setter of the property, can delete a property. The setter of a
property can edit it by setting a new property with the same name.

New APIs: SetAssetProperty, DeleteAssetProperty, GetAssetProperties.

Implemented freezing of assets and currencies, to be used for tokens that are
scheduled to become child chains, or need to be deactivated for other reasons.

Freezing of arbitrary assets or currencies is not (and will not be) supported.
The freezing of a particular holding must first be enabled in a new release,
and is then triggered at a predefined height, optionally specified as asset
property for assets, or account property for currencies.

After the freeze height, no further transactions with the frozen holding are
possible (with the exception of setting or deleting asset properties). Freezing
is not reversible.

Implemented migration of a frozen asset or currency to a new child chain. The
migration of a particular holding must first be enabled in a new release, and
is then triggered at a predefined height, optionally specified as asset property
for assets, or account property for currencies.

Implemented loading of account balances for new child chains. The Dominium child
chain will be launched on testnet at or after block 455000, with testnet
balances allocated to developer accounts only.

Fixed loading transaction voucher which contains attached encrypted message.

Node log file name changed from nxt.log to ardor.{n}.log where {n} is the log
file number. The current log file is always named ardor.0.log. Up to 10 log
files are kept.

The windows startup script run.bat no longer relies on the windows registry
when looking up the Java version.

Lightweight Contracts:

The contract runner now executes contracts in their own sandbox which restricts
the contract permissions based on a standard Java policy file named ardor.policy
By default contracts allowed to connect to any address, and read, write and 
delete files in the temp folder of the contract runner workstation. Direct 
access to the local workstation, or the local blockchain not through the APIs
is blocked by default. The contract runner operator can grant additional 
permissions per contract or for all contracts submitted by a specific account. 
See examples in ardor.policy file.

Added support for deployment and verification of single source file contract 
which compiles into multiple class files. The contract classes are automatically 
packaged into a Jar file when deployed to the blockchain. Similarly verification
of the contract unpacks the Jar and compares individual class files.

Parameter injection is now supported using the ContractInvocationParameter,
ContractSetupParameter and ContractRunnerParameter annotations. This reduces
contract boiler plate code for reading parameters. 

Contract class selector was added to the contract manager plugin. Users 
upgrading from a previous release will need to redeploy the IntelliJ plugin 
after installing this version. The plugin version should be 2.2.0.

Contract runner parameters can be specified in the nxt.properties file using
the addon.contractRunner. prefix. The contracts.json configuration file is now
only used when specifying secret contract runner parameters so can be ignored
in most configuration.

It is no longer required to define contracts which do not setup parameters in 
the contract.uploader.json file.

See: https://ardordocs.jelurida.com/Lightweight_Contracts for more details and 
examples.

Due to interface changes introduced by this release, all existing contracts will
have to be redeployed on testnet and contract runners using a previous version
won't be able to run contracts deployed using the current version.

On testnet only, after block 455000 the average block time will be reduced to
10 seconds. This is to allow faster testing and development, and to test the
feasibility of reducing block time should the need arise on mainnet.


--------------------------------------------------------------------------------
ardor-client-2.1.2:

This is a critical bugfix release. IMMEDIATE update is mandatory for everyone.

Fixed validation of string fields length in transaction attachments.

This is a stable release and should be used for mainnet nodes too, however
lightweight contracts are still available only on testnet.

Changelly exchange integration is now available in the Ardor wallet:

https://nxtwiki.org/wiki/Changelly_Integration

Javadoc is now available for sample contracts and API callers.


--------------------------------------------------------------------------------
ardor-client-2.1.1e:

This is an experimental release. It is a mandatory upgrade only for testnet
nodes, but can also be run on mainnet.

Contract Manager IntelliJ Plugin is now available to enable contract 
deployment and management from inside the IntelliJ Java Development IDE.

The Contract Manager utility now supports contract verification which, given
a hash of existing contract deployed as cloud data and a Java source file, 
compiles the source file and verifies that the resulting class file is 
identical to the contract class file. 

API callers are objects which enable simple integration of Java programs with
the Ardor APIs. Multiple code samples are provided under
./addons/src/java/com/jelurida/ardor/client/api to demonstrate tasks such as
local signing, fee calculation, message encryption and decryption, and waiting
for a new block.

Transaction voucher loading is now supported when logging in using remembered
passphrase.

Fixed coin exchange between parent and child chain.

Fixed decimal calculations for MS currency reserve and claim dialogs.


--------------------------------------------------------------------------------
ardor-client-2.1.0e:

This is an experimental release. It is a mandatory upgrade only for testnet
nodes, but can also be run on mainnet. On testnet, a hardfork to enable the
lightweight contracts feature has been scheduled at height 341500.

First release of lightweight contracts and transaction vouchers.
Refer to the nxt wiki for official documentation.

The bundling of transactions has been significantly enhanced to support more
flexible bundling filters and fee calculations rules. Multiple bundling filter
classes can be defined in the nxt.availableBundlingFilters property.

The following predefined bundling filters are available by default:

nxt.addons.PersonalBundler - bundles only the transactions of the bundler
account.

nxt.addons.AccountPropertyBundler - bundles only transactions sent by accounts
which have the "bundling" property set on them by the bundler account.

nxt.addons.AssetBundler - bundles only transactions involving the specified
asset.

nxt.addons.CurrencyBundler - bundles only transactions involving the specified
MS currency.

nxt.addons.PurchaseBundler - bundles only purchases of digital goods sold by
the specified account.

nxt.addons.QuotaBundler - bundles transactions until reaching a quota per
sender and transaction type.


The startBundler API has been modified to accept an optional "bundlingRulesJSON"
parameter, in which the list of bundling rules can be defined in JSON format.
Alternatively, a single bundling rule can be defined using a "feeCalculatorName"
and one or more "filter" parameters.

A new addBundlingRule API has been added to allow clients without JSON support
to run bundlers with more than one rule, by adding rules to an already started
bundler.

More than one filter is allowed per rule. The rule is executed only if all
filters allow the transaction.

The lists of available bundling filters and fee calculators can be retrieved
using the new getBundlingOptions API.

The Bundlers page has been enhanced to support the new bundling rules and
filters features in the client UI.

Account property with name "nrs_recipient_ui_options", set by the recipient on
itself is now used to configure the modal when sending funds to that account.
This can be used instead of the "#merchant:" account description and allows
control over the message encryption, such as disabling it for exchange accounts.
The value of the nrs_recipient_ui_options property is a JSON object with fields:
- message_format: same as the format specifier in the #merchant account
description
- encrypt_message: default value for the encrypt message box
- encrypt_message_disabled: if true, the encrypt message box is disabled

Don't show permanent message option on ARDR chain since permanent messages are
disabled there. Fixed verification of prunable messages on ARDR.

IGNIS is now the default chain when loading the wallet for the first time.

Support compilation with Java 10 and language level 9.

Updated translation resources and removed old translations.

Added a checkpoint at height 221000.

Renamed the BITSWIFT child chain to BITS.

Updated Jetty to version 9.3.24 and Bouncy Castle to 1.60. Delete the old lib
folder if installing on top.


--------------------------------------------------------------------------------
ardor-client-2.0.14:

Multiple client UI bugfixes and enhancements:

Correct coin order cancellation fee calculations when the exchange coin is ARDR
and correct fee coin label in the buy and cancel modals.

Format amount and fee according to chain decimals in transactions tables.

Fixed server calculated exchange rate to display according to locale numeric
formatting.

Added the buy orders side to the coin exchange, improved layout of the coin
exchange page.

Fixed update of account balances per chain.

Fixed alias offer to any account. Fixed decryption of DGS goods.

Added Ardorgate EULA and privacy policy checkboxes and links.

Improved the "not enough funds" error message.

Fixed sending of transactions when running as light client.

Added UI for blacklisting bundlers.

Do not process or propagate bundler rates when running as light client.

Do not load genesis block json when running as light client, for faster initial
startup.


--------------------------------------------------------------------------------
ardor-client-2.0.13:

Bundlers page UI improvements and bugfixes.

Added AccountPropertyBundler add-on, which only bundles transactions sent by
accounts having the "bundling" property set on them by the bundler. To enable,
set nxt.bundlingFilter=nxt.addons.AccountPropertyBundler. This will apply to
all bundlers started on this node.

Added minimumFeeFQT field to the response for all Create Transaction APIs,
indicating the minimum required fee in ARDR, regardless of the actual fee
specified by the sender.

Desktop wallet performance optimizations to reduce excessive load.

Local signing and validation bugfixes, other minor code improvements.


--------------------------------------------------------------------------------
ardor-client-2.0.12:

Fixed setting the ecBlock parameter used when doing local signing for remote
nodes, light clients, and mobile clients.

Coin exchange totals are now trimmed according to the chain decimals.


--------------------------------------------------------------------------------
ardor-client-2.0.11:

This release blacklists peers older than 2.0.10, and adds a checkpoint at
height 6000.

Changed Open Coin Orders to My Coin Orders in the Coin Exchange, sort orders
per chain then per rate descending, added pagination.

Always make prunable messages prunable regardless of their length, if the
"message is never deleted" checkbox is not checked.

Added Mistertango withdrawal UI to the AEUR child chain, not yet functional.

Increased default number of fork confirmations to 5.

Other minor bugfixes and improvements.

This release will perform a database rescan.


--------------------------------------------------------------------------------
ardor-client-2.0.10:

This is a bugfix release, mandatory update for all nodes.

Fixed an issue with block pop-off handling, which can result in a node unable
to continue downloading the blockchain after encountering an error condition.

Fixed processing of alias transfer transactions.

Fixed exchange price handling affecting some coin exchange trades.

Show correct total coin amounts for each chain.

Other minor bugfixes and improvements.

This release will perform a database rescan.


--------------------------------------------------------------------------------
ardor-client-2.0.9:

First production release of the Ardor Blockchain Platform.

The Ardor Genesis Snapshot has been taken at Nxt blockchain height of 1636363.

The Genesis timestamp is set to 00:00:00 UTC, Jan 1st 2018. Everyone with ARDR
balance >= 1000 is invited to setup a node and start forging. Block generation
will start automatically when the Genesis timestamp is reached. In the meantime,
please check your balances and report any discrepancies from what you expected.

To simplify processing of phased transactions, the getExecutedTransactions API
now returns the transactions ordered by the height at which they were executed,
not at which they were included in the blockchain.


--------------------------------------------------------------------------------
ardor-client-2.0.8e:

This release is a mandatory upgrade for all Ardor testnet nodes. It involves a
reset of the existing testnet and starts from a new genesis block.

The new testnet genesis block is based on a snapshot of the Nxt blockchain at
height 1631000. Forging on testnet is set to start at 14:00 UTC, Dec 26.

The number of decimals for the AEUR child chain has been changed to 4.

Login UI bugfixes and improvements. Increased initial heap size to 256M.

As this release requires a full reset of testnet, the nxt_test_db folder must
be deleted before installation.


--------------------------------------------------------------------------------
ardor-client-2.0.7e:

This release is a mandatory upgrade for all Ardor testnet nodes. It involves a
reset of the existing testnet and starts from a new genesis block.

The new testnet genesis block is based on a snapshot of the Nxt blockchain at
height 1624000. Forging on testnet is set to start at midnight UTC, Dec 22.

The BTC and USD testnet child chains have been removed, for consistency with
the expected production child chains. The EUR child chain has been renamed to
AEUR, with 2 decimals. Child chain ids for AEUR and Bitswift have changed to 3
and 4 respectively.

The child chain transaction types that affect only global platform entities and
do not involve pricing or transfer of value are now allowed only on the IGNIS
child chain. Such transactions currently are: asset issuance, setting account
info, setting account properties, asset share increase, setting asset control,
setting account control.

All fees have been reviewed and updated. Most fees have been decreased
significantly, with the default Ardor chain fee set to 1 ARDR, and the default
child chain fee to 0.01 ARDR.

Node JS module bugfixes.

Updated Lucene to version 7.1.0.

As this release requires a full reset of testnet, the nxt_test_db and the lib
folders must be deleted before installation.


--------------------------------------------------------------------------------
ardor-client-2.0.6e:

This is a feature-freeze release for the Ardor testnet. No more API changes or
feature additions are planned before launch, only bug fixes.

The source code is now included in the package, for a public review, under a
temporary evaluation license only.

Added getExecutedTransactions API. This new API accepts parameters: "chain",
"height", "numberOfConfirmations", "type", "subtype", "sender", "recipient",
"firstIndex", "lastIndex", and returns the transactions from the specified
chain executed at this height, or executed with at least that many number of
confirmations.
Both non-phased and phased transactions are returned. For phased transactions,
only those approved and executed at the specified height, or approved with at
least that many confirmations of the final approval transaction, are returned.
If height is specified, sender or recipient parameters are optional, otherwise
at least one of them is required.

Fixed UI bugs - base target calculation, missing asset control setup, asset
control local signing, calculation of deadline when doing manual transaction
bundling.


--------------------------------------------------------------------------------
ardor-client-2.0.5e:

This release is a mandatory update for all Ardor testnet nodes. It will perform
a rescan on first start.

Client UI improvements for the new asset control, composite phasing, and asset
increase features.

The default transaction deadline has been reduced to 15 min instead of 24 h.

Mobile app now connects to ardor.jelurida.com by default.

Use ARDOR as default account prefix. Using NXT or any other prefix continues to
be supported for logging in.

Allow whitelisting of specific bundler accounts using the property
nxt.bestBundlerRateWhitelist. If set, only bundler rates announced by the
whitelisted accounts will be used.

Fixed bugs in peer networking, parsing genesis block json, by-property voting.


--------------------------------------------------------------------------------
ardor-client-2.0.4e:

This Ardor platform release introduces several important new features.
It is for testnet only, and involves a reset of the existing testnet and
starting from a new Genesis block.


Major new features:

- Asset Control.

Similar to Account Control which once set requires all transactions of an
account to be subject to approval (i.e. to use phasing), the new Asset Control
feature allows imposing such restriction to all transactions involving a given
asset - such as placing bid and ask orders, transfers, share deletions, and
dividend payments that use the asset as a dividend.
This feature enables for example a private company to issue its shares on the
Ardor blockchain, yet to impose control over who can purchase or sell them, for
example requiring asset transactions to be approved by its board of directors,
or a shareholder voting.
It also allows asset issuers to be KYC compliant, by only allowing verified
accounts to transact with their assets.

- Composite Phasing

The Composite Phasing ("Smart Phasing") is a very powerful new feature that
allows approval models for conditional transactions to be defined in terms of a
Boolean combination of other approval models, i.e. allows joining the current
primitive approval models such as by whitelist, by asset balance, by hash, etc,
using the AND, OR, and NOT operators.
This allows the new Asset Control feature to be used in combination with the
Account Control feature when required, the transaction execution being made
conditional on satisfying both the Asset Control and Account Control settings.
It also allows for example combining the existing by hash or by transaction
approval models with by whitelist, by balance, etc, approvals, which enables
doing atomic coupling of transactions (including cross-blockchain) even for
multisignature accounts (i.e. subject to Account Control), or with assets
subject to Asset Control.
The NOT operator allows for dead-man-switch type conditions, where a
transaction is executed only if some condition (e.g. revealing a secret) is not
satisfied.

- By-Property phasing

The new by-property approval model allows the transaction execution to be made
conditional on the sender account or the recipient account having a specific
account property set. If this property is set, the transaction will be executed
immediately, else, a second check whether the property is set is performed at
the finish height defined. This allows for example enforcing KYC by asset
issuers, who can define in their Asset Control settings that only KYC-verified
accounts, labelled with a predefined account property by a trusted authority
(or the asset issuer itself), to perform transactions with their assets.

- Asset share increase

A new transaction type has been added, allowing the asset issuer to increase
the total number of asset shares in existence. The new shares are allocated to
the asset issuer account, but can be then distributed to shareholders using
a separate dividend payment transaction. This allows corporate actions such as
capital increases or stock splits to be performed.


Imports from Nxt blockchain:

To test the snapshot process planned for the production Ardor release, this
testnet release is based on a Genesis block created from a snapshot of the
production Nxt blockchain as of block height 1558030. The following records
have been imported:

- Accounts public keys

- Account balances. ARDOR chain balances are based on ARDR asset balances, and
IGNIS chain balances are based on NXT balances divided by 2, plus JLRDA asset
balances. Each of those has been additionally divided by 2, in order to
allocate 50% of the testnet coins to developer accounts for testing purposes.
BITSWIFT chain balances are based on Bitswift asset balances, plus a 10%
airdrop distributed proportionately to all IGNIS holders.

- Account info (name and description)

- Account properties

- Account control settings, but only for account control by whitelist with no
minimum balance. Other types of account control will not be imported.

- Account aliases have been imported to the IGNIS child chain.

- Assets. Only the Janus, JanusXT, and ComJNSXT assets have been imported, with
their asset ids preserved.

- Monetary system currencies have been imported to the IGNIS child chain, but
only the currency code and name, in order to reserve those. It would be up to
each currency issuer to re-issue the currency with the appropriate properties
and re-distribute it to users.


Modified APIs:

GetAssetDeletes has been replaced with GetAssetHistory, with "deletesOnly", and
"increasesOnly" optional parameters to retrieve only share delete or share
increase history events.

ApproveTransaction now takes multivalued revealedSecret parameter, to allow
revealing multiple secrets for transactions using composite phasing.

SetPhasingOnlyControl now optionally also accepts the account control phasing
parameters in a JSON format, as a single "controlPhasing" parameter.

All CreateTransaction API now optionally also accept the transaction phasing
parameters in a JSON format as "phasingParams" and "phasingSubPolls" parameters.

For by-property phasing, the following new parameters have been added:
"phasingSenderPropertySetter", "phasingSenderPropertyName",
"phasingSenderPropertyValue", "phasingRecipientPropertySetter",
"phasingRecipientPropertyName", "phasingRecipientPropertyValue".

For composite phasing, the boolean expression can be supplied in Disjunctive
Normal Form as "phasingExpression" parameter, with no parentheses, variables
in format [a-zA-Z][a-zA-Z0-9]* and operators "&" (AND), "|" (OR), "!" (NOT).

For each variable appearing in the boolean expression, the phasing parameters
of its sub-poll can be specified as separate parameter with prefix
"phasing<variable name>", or as JSON in the "phasingSubPolls" parameter.


New APIs:

IncreaseAssetShares - create new asset shares. Only the asset issuer can submit
a share increase transaction.

EvaluateExpression - evaluates a Boolean expression, for use in composite
phasing.

ParsePhasingParams - converts phasing parameters, submitted as HTTP request
parameters, to a JSON format.

GetPhasingAssetControl - returns the phasing control for a given asset, if set.

SetPhasingAssetControl - set or unset phasing control for an asset. Only the
asset issuer can change asset control settings. If an asset is not under asset
control, a new asset control can only be set if all shares are currently owned
by the asset issuer.


Ported various bugfixes and improvements from Nxt up to version 1.11.9.

Updated jetty to version 9.3.22, bouncycastle to 1.58, and the izpack installer
to version 5.1.2.

Since this release requires a full reset of testnet starting from a new Genesis
block, if upgrading from 2.0.3e or earlier, in addition to the lib folder the
nxt_test_db folder must also be deleted. The import of snapshot balances on
first start may take a few minutes and should not be interrupted.

The testnet Genesis block timestamp has been set to 00:00 (midnight) UTC time
on Monday, Nov 6th, in order to allow time for users to setup nodes check their
balances, and start forging.
Block generation will commence automatically once that time has been reached,
and only then it will become possible to create and send new transactions.


--------------------------------------------------------------------------------
ardor-client-2.0.3e:

Minor unconfirmed transaction processing improvements.

Coin Exchange UI improvements and bugfixes.

Updated jetty to version 9.3.17.


--------------------------------------------------------------------------------
ardor-client-2.0.2e:

This release introduces an incompatible networking change in bundler rates
propagation and is therefore a mandatory update for all Ardor testnet nodes.

Improvements in bundler rates handling and APIs:

The GetBundlerRates API now also returns the bundler account and the remaining
fee limit for each bundler as currentFeeLimitFQT.

The new GetAllBundlerRates API returns all bundler rates known to the node, for
all child chains, subject to optional minBundlerBalanceFXT limit on the bundler
effective Ardor balance.

The new BlacklistBundler API allows manual blacklisting of bundler accounts.
Rates advertised by such accounts will not be added to the local list of known
rates each node maintains. Blacklisting of bundler accounts is also possible
using the new nxt.blacklistedBundlerAccounts property.

Bundler rates are now broadcasted every 30 min instead of once an hour.

The new nxt.minBundlerFeeLimitFXT property allows skipping bundler rates that
are announced by bundlers with lower remaining current fee limit, default 10
Ardor.

Added peer authentication and encryption framework for the peer networking, to
be used for permissioned blockchains.

Added Bundle action for child chain transactions in the UI. Added visual
representation of transaction bundling and confirmation status.

Client UI and peer networking bugfixes and improvements.

Updated H2 to version 1.4.194.


--------------------------------------------------------------------------------
ardor-client-2.0.1e:

This is a bugfix release, for testnet only.

Added Node JS module, see html/www/js/README.

Multiple bugs fixed and improvements added in client UI, peer networking,
blockchain download.

Removed obsolete news page, added About modal.

This release will force a rescan, deleting blocks after height 11619.


--------------------------------------------------------------------------------
ardor-client-2.0.0e:

This is the first release of the Ardor software, for testnet only. It represents
the first milestone in the building of the Ardor platform.


== New Features ==

The main new user-visible feature is the existence of a single forging chain,
using the ARDR token, and multiple child chains, each with its own token.


== Forging Chain ==

The Ardor chain is used to establish the proof-of-stake consensus, using ARDR
balances only. It supports only a few transaction types: ordinary payments,
balance leasing, and coin exchange. Prunable plain or encrypted message
attachments are also supported, but not permanent or standalone arbitrary
message transactions.


== Child Chains ==

The child chains support all transaction types as previously implemented on the
Nxt platform, with the exception of balance leasing which is only available on
the Ardor chain, and tagged data extend transaction which has been removed as
unnecessary. A child chain can optionally be configured to disable certain
transaction types, which has been done for testing purposes on the EUR child
chain, disabling the Asset Exchange and Digital Marketplace.


== Coin Exchange ==

To allow trading of child chain coins to each other, and also between child
chains and the Ardor chain, a new Coin Exchange module has been implemented.

For trading between child chain coins, the coin exchange transactions are
submitted on the child chain of the coin being sold. For trading between a child
chain coin and Ardor, the transaction is submitted on the Ardor chain regardless
of whether it is a buy or sell, and the fees for such transactions are higher.


== Bundling ==

The bundling process is used to group child chain transactions from a child
chain into a transaction on the Ardor chain. Bundlers accept the fees from
those child chain transactions, in the corresponding child chain coin, and
pay fees in ARDR to the parent chain forgers. Bundlers can be started from
the cogwheel/bundlers menu, defining the coin to ARDR exchange rate they accept,
a limit on the total fees in ARDR a bundler will pay, and an optional overpay
amount.

When a bundler is running, it checks the unconfirmed transactions pool every
time a new transaction from the child chain being bundled arrives. If the
transaction fee included by the transaction sender, in child chain coins, when
converted to Ardor using the exchange rate accepted by the bundler is at least
equal to the minimum Ardor fee required for this transaction, the bundler will
generate a ChildBlock transaction, including in it this and all other currently
unconfirmed child chain transactions satisfying this requirement. The Ardor fee
the bundler will include for the ChildBlock transaction is equal to the sum of
the minimum required Ardor fees for each, plus the calculated overpay amount, if
any. Such overpay amount is optional, and may be used by bundlers willing to pay
more in order to have their transactions included in block instead of those of
competing bundlers.
The new ChildBlock transaction will displace from the unconfirmed pool any
ChildBlock transactions of the same child chain that include only a subset of
the same child transactions.
When propagating through the network, ChildBlock transactions will only be
accepted by peers if they either include child transactions not already included
in other ChildBlock transactions the peer already has in its pool, or offer to
pay a higher fee for the same transactions. This ensures the network is not
flooded with ChildBlock transactions even if every node is running a bundler,
and allows bundlers to compete for propagating their transactions through the
network by offering to pay higher fees.

It is now possible for child transactions to be submitted with zero fees, in
child chain coins. If a bundler is willing to pay the Ardor fees for those,
they will be included in the blockchain in the ChildBlock created by such
bundler.

To prevent the unconfirmed pool from being overfilled with such zero-fees child
chain transactions, once the maxUnconfirmedTransactions limit (configured in
nxt.properties, default 2000) has been exceeded, child chain transactions will
be dropped unless a bundler has already submitted a ChildBlock transaction which
includes them.

Bundlers advertise their accepted bundling rates to other peers, signing such
rates announcements with the private key of the bundler's account. To prevent
fake rates announcements, they can be filtered based on this account effective
balance (default set in nxt.minBundlerBalanceFXT is 1000 ARDR).
The GetBundlerRates API can be used to retrieve known bundlers rates, again
with optional filtering by minimum bundler effective balance.


== Peer Networking ==

The peer networking has been fully re-written and optimized to use socket
connections and binary messages instead of http and JSON.

Block and transaction propagation through the network has been optimized, by
sharing with peers the inventory of transaction IDs in the unconfirmed pool or
in recent blocks, and only propagating the missing ones, if any, when a new
block is generated, or a child block is bundled.

The hallmark feature has been removed as it is not needed anymore, hallmarks are
no longer supported.


== New APIs ==

APIs of the new Coin Exchange feature:
ExchangeCoins, CancelCoinExchange, GetCoinExchangeOrder, GetCoinExchangeOrders,
GetCoinExchangeOrderIds, GetCoinExchangeTrade, GetCoinExchangeTrades,
GetExpectedCoinExchangeOrderCancellations, GetExpectedCoinExchangeOrders,
GetLastCoinExchangeTrade.

Bundling related APIs:
BundleTransactions, GetBundlers, GetBundlerRates, StartBundler, StopBundler.

Other new APIs:
GetBalances, GetEffectiveBalance, GetFxtTransaction.


== API changes ==

All APIs that are now chain specific accept a new chain parameter. Either the
chain name or the chain ID can be used.

Transaction IDs are no longer 64-bit longs but 256-bit hashes, necessitating
changes in all APIs that accept transaction ID parameters or return such in the
JSON fields. For transactions on the Ardor chain, 64-bit long IDs can still be
used with the getFxtTransaction API, as those are enforced to be unique. For
child chain transactions, the getTransaction API now requires a fullHash
parameter, in addition to specifying the chain.

Prices and rates are now defined relative to a whole unit of the holding being
bought or sold (asset, currency, coin), not to a QNT indivisible unit.

All priceNQT and rateNQT parameters and JSON fields have been renamed where
appropriate to priceNQTPerCoin, priceNQTPerShare, rateNQTPerUnit, etc., to
reflect their changed meaning of price per whole unit of each holding rather
than per QNT.

All "units" parameters in the Monetary System APIs have been renamed to
unitsQNT.

DividendPayment API accepts holding and holdingType parameters to allow paying
dividends in another asset or MS currency. The amountNQTPerQNT parameter has
been renamed to amountNQTPerShare and now refers to dividend amount in NQT per
a whole share of the asset rather than per QNT.

The GetAccount API no longer returns balanceNQT and unconfirmedBalanceNQT, as
balances are now chain specific. The GetBalance API should be used to get chain
balances instead, or GetBalances for querying multiple chains.

APIs which accept holding and holdingType parameters now require holding to be
set to the chain ID when holdingType=0 (coin).

Since 0 is now a valid fee value for child chains, all CreateTransaction APIs
will accept it, instead of using it as a request for the server to calculate
and use the minimum fee. To let the server calculate the child transaction fee,
a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must
be supplied, to indicate the exchange rate to use when calculating the fee
(since minimum fees can only be calculated in ARDR). If feeRateNQTPerFXT is
also set to -1, the server will query the currently known bundlers rates for
this child chain, also subject to the minBundlerBalanceFXT limit on effective
bundler account balance, and use the best one for the fee calculation. As
bundlers rates cannot be trusted blindly, the transaction will not be
broadcasted in this case, the returned transaction JSON including the fees
calculated should be reviewed by the user. The bundler rate used will be
returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for
the chain.

The following APIs have been removed: ExtendTaggedData, GetPhasingPolls,
GetTaggedDataExtendTransactions, GetInboundPeers, MarkHost, DecodeHallmark.


== Transaction types and bytes format ==

The numbering of some transaction types has changed, due to the internal
reorganizations of the TransactionType classes. Transaction types on the Ardor
chain use negative numbers, e.g. -1 for ChildChainBlock, -2 for Ardor ordinary
payment. Some transaction subtypes have been moved to a separate type, e.g.
voting and phasing related transactions have been moved out of Messaging to a
new Voting transaction type. The output of getConstants should be consulted for
a full list of the current transaction types and subtypes.

The transaction bytes format has also changed, adding a chain ID, reorganizing
the ordering of attachment and appendix bytes, and allowing prunable attachment
parts to also optionally be represented in the bytes format, for the purpose of
sending them more efficiently over the peer to peer network.

The JSON transaction representation is still supported, even though it is no
longer used in the peer networking. Some attachment fields have been renamed
for consistency with the API changes - units to unitsQNT, priceNQT to
priceNQTPerShare, rateNQT to rateNQTPerUnit, amountNQT for dividend payments to
amountNQTPerShare, etc.


== Entity IDs ==

As part of designing child chain transactions to be prunable, it is no longer
possible to enforce uniqueness of the 64-bit transaction IDs for child chains.
This affects the IDs of derived entities such as Assets, MS Currencies, Polls,
Digital Goods, Shufflings, etc.

For global derived entities such as Assets or Currencies, the 64-bit long IDs
are still unique and used in the corresponding APIs. Note however that this
uniqueness is now only within the same object type, i.e. it is not guaranteed
that an Asset and a Currency will not happen to have the same 64-bit long ID.

For child chain local entities, such as Polls and Digital Goods, the 64-bit IDs
are still unique, but within the same child chain only, and still used in their
APIs. Again, there is no uniqueness guarantee across different entity types
anymore.

For entities that are prunable, such as prunable messages, tagged data, and
shufflings, the full 256-bit hash must be used as an ID now, and the appropriate
APIs have been changed.


== Phasing and Account control ==

Only child chain transactions can be phased. Therefore, when account control
is set for an account, it can no longer submit Ardor chain transactions.
Phasing parameters which refer to transaction IDs must now use transaction
full hashes instead, prefixed with the chain ID separated with ':'.
It is possible to refer to transactions on other chains when approving a phased
transaction, or setting up a by-transaction phasing voting model.
The controlMaxFees parameter when setting mandatory approval now accepts
multiple values, each fee being prefixed with the child chain ID and ':', to
indicate which child chain the limit applies to. If no max fee has been set for
a child chain, there is no phasing transactions fees total limit on it for the
controlled account.


== Transaction selection, sorting, limits and fees ==

An Ardor chain block can contain up to 10 (ten) transactions, this including
both native Ardor transactions and ChildBlock transactions. There is no total
payload size limit.

A ChildBlock can contain up to 100 (one hundred) child transactions, subject
to a total payload limit of 128 kbytes. Prunable child transaction parts are
also counted towards the payload size limit.

There is a limit of one ChildBlock per Ardor block for each child chain.

As in Nxt, it is up to a block forger which transactions to include in a block
and how to sort them. The default forger behaviour is to select transactions
ordered by Ardor fee (not fee per byte as in Nxt, since there is no block
payload limit), and then sort them based on arrival timestamp.

It is also up to the ChildBlock bundler which child transactions to include in
a ChildBlock, and this selection can be customized by defining a custom filter
in the nxt.bundlingFilter property. The default bundler behaviour is to select
child transactions ordered by fee per byte, up to the count and payload limits
of a child block, creating several child blocks if necessary. Within a child
block, child transactions are sorted based on their full hash, but executed
based on sorting them after adding the block hash to the child transaction hash,
i.e. the execution order of child transactions within a block is deterministic
but not predictable and not controllable by the bundler or by the forger. This
is in order to prevent front-running of asset exchange and other trading orders.

Ardor fees from ChildBlock transactions paid to the block forger are shared with
the previous three block forgers in 1:1:1:1 ratio. Other Ardor chain fees are
fully kept by the block forger, and child block transaction fees (in child chain
coins) are fully kept by the ChildBlock bundler.

The back fees sharing which was applied in Nxt for some other transactions types
such as currency or asset issuance has been removed, however the limitations of
one such transaction per block for scarce blockchain resources are preserved.

Default fee for Ardor chain transactions is 10 ARDR. Default fee for child chain
transactions is 0.1 ARDR. A ChildBlock must contain at least one child chain
transaction, but there is no minimum ChildBlock fee requirement, i.e. such a
ChildBlock with a single transaction in it would require only 0.1 ARDR fee if
this is the minimum fee for the child transaction it contains.

Fees for child chain transaction types have been scaled depending on their
impact on the blockchain, e.g. asset issuance fees are still 1000 ARDR as assets
are global and kept permanently. There is a 1 ARDR extra fee added to
transactions that create a new account.

The above fees and limits are set for the current testnet only and are subject
to change before the production mainnet release.


== Testnet accounts ==

The testnet genesis block has been created based on account balances from the
Nxt testnet, as of 2017/01/01 (block height 1061208). Users who had testnet
accounts as of that height should find their ARDR and NXT testnet balances
imported into this testnet, to ARDR and IGNIS tokens respectively, plus an
approximately equivalent amount of BTC, USD, and EUR child chain coins for
testing. To allow for developers testing and running forging and bundling nodes,
account holdings have been reduced by 50% which have been allocated to
developers accounts.


== Upgrading from Nxt ==

The Ardor release is not an upgrade and does not in any way affect your existing
Nxt account or client installation. Both Ardor and Nxt should be possible to run
simultaneously on the same machine, as long as the hardware capacity allows it.

The included ArdorNxtComparison.pdf document summarizes the major differences
between the Nxt and Ardor platforms, for those deciding which one is a better
fit for their use case, or considering a migration from Nxt to Ardor. More
documentation should be added as Ardor development and features mature and
stabilize.


--------------------------------------------------------------------------------
