Switch to NxtForum

Thank you!

Great work!! 

Mobile App https://bitbucket.org/Jelurida/ardor/downloads/ardor-client-2.2.1.apk
SHA256 784a7159e489418d7b060330ca4d8c8271d5d0076b84b6be1b61a302279beb77

-----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-----

Three contests are active right now!
There is still enough time to secure your spot.
Play now[

1 BTC Players (Wagering) Contest

Players (Wagering) Contest with 1 BTC Prize Pool has already started. Follow the Contests page!


Prizes:

1st Place - 0.30 BTC and 30 Days LEGEND
2nd Place - 0.20 BTC and 30 Days LEGEND
3rd Place - 0.15 BTC and 30 Days LEGEND
4th Place - 0.10 BTC and 30 Days LEGEND
5th Place - 0.08 BTC and 30 Days LEGEND
6th Place - 0.06 BTC and 30 Days LEGEND
7th Place - 0.05 BTC and 30 Days LEGEND
8th Place - 0.03 BTC and 30 Days LEGEND
9th Place - 0.02 BTC and 30 Days LEGEND
10th Place - 0.01 BTC and 30 Days LEGEND





GOOD LUCK TO EVERYONE!


Post your username for additional chance to win up to 0.1 ETH when 1BTC wagering contest finish.