assembly
assembly
Ardor v2.2.3
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Ardor Client: Ardor 2.2.5

Author Topic: Ardor v2.2.3  (Read 3682 times)

Jelurida

  • Board Moderator
  • Jr. Member
  • ****
  • Karma: +30/-0
  • Offline Offline
  • Posts: 52
    • View Profile
Ardor v2.2.3
« on: April 23, 2019, 12:36:33 pm »

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 2.2.3

https://www.jelurida.com/

sha256 checksums:

93ae873e406d405490baf6e26816509282e8c92a505798168a914ede1d2c704e  ardor-client-2.2.3.zip

f414a71a656bdc0e97ff71ad1b65b7bd182d8b80216bc285e4e59f9cf63e0371  ardor-client-2.2.3.sh

The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".


Change log:

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.


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvs/qm2srO/+g27NEDPnHRy2AuLkFAly+8jAACgkQDPnHRy2A
uLnRiA//TXgWWzbkM6TC48faknX0JT93hfsbJs0DSndHpVz22CFnvDBBgrFONVHN
1pLQt8KIW8lWawGqkhMKWsWydzAYpgWqldzBRhkJd7mqO+JDE3gGUNOVr0bWQ47a
y4yFNI8kONLuNbHalyiszcKUg8Y6FJG2+XcQmJCDjap0YVifxwoL0z0Kh+Tr7JiX
7mYH5eTg19nXMc9e1Pu0HqFc1cA84nVhrgihtyTesMYNEmMDfM40+eakJxFmLYr8
vx+8se4qLUhaJJIOxHSdoTAq/DDcRcq2ri2nHfjJxPCHufe2rZB9BvZ0mBR22lYO
5YTPdSiEn8z1kWauw5yRLKiQKEQ8BjJ8cLpKTJPL/zDik4dCVxLiFTi26m5kBYF4
rvSXOVk3MzLe4gHW2yjyqsSv90FqEG5wgaSzGrN97YTRgUzKFzl4fDsqe9xPY1P2
ZE3KvUVSyftY9reVrj1jFcLEDd/NTC+ioRtgu51j9V2gxSNYp7Vm6WKFtZzmf3WS
klUGwbuAuBvB9lqsVMc1LZvJ3xBoriy8jkSS1FQZs1L6vORiF0iWIlowJ1B5gc0I
QCI//VqIxQGK659Qj/5ZIXn+9xqHn5UHWa1Ruhgpyo6tgDQmE+76Q0JKOlRLr2bX
JEWDc7niabKfcm3wHG/iut3SaYjNJqazfb13WAme19oL9wHKZO0=
=Io2V
-----END PGP SIGNATURE-----
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +439/-42
  • Offline Offline
  • Posts: 1794
    • View Profile
Re: Ardor v2.2.3
« Reply #1 on: April 23, 2019, 02:07:58 pm »

Mobile app https://bitbucket.org/Jelurida/ardor/downloads/ardor-client-2.2.3.apk
SHA256 3e627bc2e83c6da2d5183bc2d30a3517490bac5c2d51e1315e7b395059f3fafa
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

MrV777

  • Hero Member
  • *****
  • Karma: +115/-4
  • Offline Offline
  • Posts: 988
    • View Profile
Re: Ardor v2.2.3
« Reply #2 on: April 26, 2019, 10:39:14 pm »

Great release!!  Thank you for your work
Logged
NXT: NXT-BK2J-ZMY4-93UY-8EM9V
NXT nodes: 209.222.98.250, 216.155.128.10

Klokan

  • Sr. Member
  • ****
  • Karma: +28/-5
  • Offline Offline
  • Posts: 286
    • View Profile
Re: Ardor v2.2.3
« Reply #3 on: April 29, 2019, 12:51:12 pm »

What's the main point of MVStore format over the older H2, please ? Just for comparing: DB size in Ardor 2.2.2 was around 661MB (692248576 bytes - nxt.h2.db). When I installed the new version 2.2.3 from scratch, size of DB just after downloading blockchain was around 1200MB (1253048320 bytes - nxt.mv.db), two days after I'm on 1400MB (1428541440 bytes - nxt.mv.db). If the increase process will be the same, the necessity of disk space will be really huge (comparing to the older one DB format) :-(
Logged

Klokan

  • Sr. Member
  • ****
  • Karma: +28/-5
  • Offline Offline
  • Posts: 286
    • View Profile
Re: Ardor v2.2.3
« Reply #4 on: April 29, 2019, 12:58:37 pm »

What's the main point of MVStore format over the older H2, please ? Just for comparing: DB size in Ardor 2.2.2 was around 661MB (692248576 bytes - nxt.h2.db). When I installed the new version 2.2.3 from scratch, size of DB just after downloading blockchain was around 1200MB (1253048320 bytes - nxt.mv.db), two days after I'm on 1400MB (1428541440 bytes - nxt.mv.db). If the increase process will be the same, the necessity of disk space will be really huge (comparing to the older one DB format) :-(

Ok, it looks like that
Code: [Select]
./compact.sh made the trick. But - how often I have to run this utility (as a prevention of huge DB filesize) ?
Logged
 

elective-stereophonic
elective-stereophonic
assembly
assembly