-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Release 2.0.4e https://www.jelurida.com/ sha256 checksums: f39b89bf90c5db0429d4829c629caf95992eed67f95973d677b397f84c358a1a ardor-client-2.0.4e.zip ae638b6dcc4a5cd03722f855c603c112540cb74997c09468e1b270c6d864f57d ardor-client-2.0.4e.sh The exe and dmg packages must have a digital signature by "Stichting NXT". This is an experimental release for testing only. Source code is not provided. Change log: 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", 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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/rsOAAoJEAz5x0ctgLi5ZEQP/0me1QMgflRc7thU2v6wxmdw +8KFRg9TI51oo8cTe3peQ/q35RkqvoOcY46MAp79WRtRvnXAyG7GKujJmAH9pvhM QBnOlhC2yN7dw6+MU0rQFM2ug3+v1qyfE21u0zNVzb1RGSxeVDRjFrY8Pe8KU0MB dh6OmcVlV9WsyQfhhIHJ0XHp9YnnMKE3memEim/f2AcDIM7O5tvQw/tIfPgSPmEy dAXulvKeazg6QENSql2P7xHVetOfoxG6Dl21BAXHy7fo5lnJ9x29wRUye9k/XQn/ v9IbSbSDlfd+EkEon7MIcISsqhh+7GRwQYqoMFrWbjkplNn9y1en+ghHQjjMEEvI 0kkeRlf0wYEuB76cK93Yhh7H4jjgq9ZlkBJ1FC0FSdBAaDZ4zKJ/SmXOTKaSVjjn W84W1A7WUqSoplhajXYQEDeb4RxqQGo9pBChNg1yhhuTL2hEUMimEiBP+Hpv+FWh 29B68Mg+KBPu1aZADeBMjPxskyHyMlEZKfFqJf9g5efjnC9S8wDU6p+zvWfudlte OUapgUaNVgG4XyJBFQMvXJ3tYklD06lwYhdAEEfENCamWwFpboj54A8EQZEDuJ0A DSMrdfM0XhSN94GdB+/6HOFR/Mo3V00S9D5KHvTAC1l5qCw0Ke31j0m4XFcY+sgn MwkoIgLoDnjlIwiNOPxI =QJKU -----END PGP SIGNATURE-----