-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Release 2.2.1 https://www.jelurida.com/ sha256 checksums: 4e6a3075141847252724e13a49d3e8110694a49a08fc22dfd986b53a39f3770d ardor-client-2.2.1.zip a85546d0e51b58fb9de02f2d3ac0381111c8b739e2798b632825516c61167c2c ardor-client-2.2.1.sh The exe and dmg packages must have a digital signature by "Jelurida Swiss SA". Change log: 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. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvs/qm2srO/+g27NEDPnHRy2AuLkFAlwSZ4UACgkQDPnHRy2A uLlssRAAhFXNsIeGpwgoO0zInyfc+gpf9eWBBvB+S0ww+0Jh69k0zyaxKMPNI/9r rjAVnCvawi10DnA6V6AVUL58XlWBAH+rGNz3FJi7JxYz7AXNToO1WOAHDI4db/vv Rr8dfdoMljNMrkUrTHG609qV0O8ZnavThSHcsCbHXyjVUaHInnVqL1+2fxVVOWIQ /FrzdZiLVvfMHHVkkhZfC0V5BJmlaPzQe7bU5zx+CYIGv4vCQKiJxup2LjowByyl 2p+7sibeYvQxh0hzVaNDYKeznFKiq8ZGZpm5m4WVyPlCyICH8dTs/0ZI7jEI6wAU vEYSSudCcRmThbhAEPlYwch6hdfPJl18blKcl0yYf4sbGVu1nmrX8E98cP6NBlYU 525NApoJ8KyJjvVCZ0H2ZpGLPbtNGqAWZKFyDxDzIcW0YPmP+T/e869Tjiv5OUz1 JKAGMk9nnYOpaopcZIM2di/40R3zzBTl+cKOe0sbqkZG+Y8IaBbGeF/JP9JZo/Hc Yd41nPBjGz+WZm2lqERRUc7xbuNJ2KLcdNVIDl4Uo8mkRw9qFhLdM+7alhGecx8Y i4AGXbNyLvGLB80xx2LOVWIrlN1VAOlSmTJx1Z7BByMrnS1m6alP73WCc2tUjK2d AsMTnYLIAIKrt7gJkHqsS3TiawGhTH2Y5g+5bVJX1ML9vfwiVuY= =C1IY -----END PGP SIGNATURE-----