Recent Posts
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Ardor Client: Ardor 2.2.6; Latest Experimental Ardor Client: Ardor 2.3.1e

Pages: 1 [2] 3 4 ... 10
 on: June 18, 2020, 04:08:24 pm 
Started by Jose - Last post by Jose
Austrian Government funds an Ardor Blockchain-based COVID-19 related app called QualiSig
Full article -

 on: June 17, 2020, 06:12:25 pm 
Started by Jose - Last post by Jose
4 Cryptocurrencies You Must Get Familiar With
Full article -
Ardor is a cryptocurrency project based on the open-source NXT blockchain, working like a blockchain-as-a-service (BaaS) provider. It offers the blockchain infrastructure for businesses and institutions to set up their chains without needing to code or secure it. With the parent-child chain architecture, the Ardor blockchain is comprised of a single chain that is attached to multiple transactional chains. This is an ambitious project designed to compete with enterprise solutions like Microsoft Azure...
Full article -

 on: June 16, 2020, 01:19:36 pm 
Started by Jelurida - Last post by Jelurida
Hash: SHA512

Release 2.3.0e

sha256 checksums:



The exe package must have a digital signature by "Jelurida Swiss SA".

Change log:

This experimental release is a mandatory upgrade for all testnet nodes. It can
also be used on mainnet.

On testnet, a hardfork is scheduled for block 4949000, expected on 18.06.2020.

Features that will be activated only on testnet at this hardfork are the new
GPS child chain, and the child chain control for AEUR (see details below). All
other new features do not require a consensus change and can therefore be used
on both testnet and mainnet immediately, but should still be considered

## HD Wallets ##

This release introduces Hierarchical Deterministic (HD) wallets to Ardor, and
enables the integration of hardware wallet devices such as Ledger.

Functionality to derive multiple public/private key pairs and account addresses
based on the BIP32 specification is now integrated into the wallet.

This HD wallet functionality allows the creation of a practically unlimited
number of accounts all from a single secret "seed". The user only needs to
have this seed to be able to access and use all HD accounts derived from it.
On the blockchain, HD accounts are indistinguishable from standalone accounts,
and there is no way for a third party to determine which HD addresses are
derived from the same seed, unless it has access to either the seed or the
master public key.

Hardware based key derivation, transaction signing, encryption and token
generation are now supported by the Ledger hardware wallet.
For more information see:

Software based key derivation is compatible with the Ledger hardware wallet so
that given the same seed, the same key pairs can be derived using either
hardware or software.

The wallet defaults to the following standard BIP44 derivation paths:
m/44'/16754'/0'/0' for mainnet
m/44'/16754'/0'/1' for testnet
All keys generated by the wallet are direct child keys of these paths.

An account address derived from a seed with a specific path generates a pair
of private/public keys from which the account address is derived. These HD
accounts do not have an account secret phrase associated with them like
existing standalone accounts. All API calls which accept the secretPhrase
parameter now also accept the privateKey parameter, which allows a derived
account to be used the same way as a standalone account simply by replacing
the secretPhrase parameter with a privateKey parameter in all API calls. The
GetAccountId API now includes the privateKey in the response, to be used to
calculate privateKey from a secretPhrase.

New APIs were added to support the HD account functionality.
GetLedgerMasterPublicKey connects directly to a Ledger device to load the
public information of a BIP32 node given a BIP32 path parameter.
Use this API to load a serialized master public key from the Ledger device to
be used for offline child account derivation.

DeriveAccountFromSeed uses software based seed derivation to derive the full
information of a BIP32 node from the combination of a seed mnemonic, a seed
passphrase and a BIP32 path. Use this API to load the information of a specific
BIP32 node.

DeriveAccountFromMasterPublicKey uses a serialized master public key obtained
using any of the other APIs and a child index to derive the public key of a
child BIP32 node. Use this API to derive the public key of a child account
without exposing any private information.

For passphrase accounts, the private key is calculated using sha256 hash plus
some bit manipulation (clamp), therefore every passphrase can be converted to
a private key but a private key cannot be converted back to a passphrase.
Whenever entering a passphrase in the wallet it is possible to enter the 64
characters private key hex string instead. To enter old 64 character passphrase
composed of exactly 64 characters hex string, prefix it with the string
"Passphrase:" (without quotes).

When loading accounts from a hardware wallet or a software seed the wallet
loads accounts sequentially starting from index 0 until it finds an account
without a registered public key or until 20 accounts have been loaded. This
behavior can be customized using the wallet login page. The APIs themselves do
not restrict the range of child keys which can be used by applications.

The wallet login Page was redesigned, new tabs were added - "Seed" for software
based account derivation, and "Hardware" for loading accounts from a hardware
wallet. The passphrase and account login options are still available. The QR
code scanning tab was replaced with a widget available for specific fields.

When launching the wallet for the first time, a walkthrough tour is displayed
to present the various login options. Each of the login options has its own
specific tour activated using a '?' button on the top bar. Additional tour is
displayed on the dashboard after login.

BIP39 compatible secret generator
The old 12 words passphrase generator used for passphrase creation was replaced
with a BIP39 compatible seed generator which can be used to generate seed or
passphrase of 12 to 24 words with an internal checksum.

Public key creation for standby shuffler
The standby shuffler can now use a master public key to derive a new public key
for each shuffling it joins so that it never runs out of public keys.
The Seed login option or a new "BIP32 Calculations" dialog can be used to
generate a master public key for use by the standby shufflers.

## GPS Child Chain ##

A new GPS child chain will be added, migrating the existing GPS asset (asset id
3123987739214429747 on mainnet, 8016986501463341146 on testnet) to a child
chain token. On testnet, the migration will happen at the testnet hardfork
block. On mainnet, the migration will be scheduled for the next hardfork block.
At the time of the migration, the GPS asset will be frozen, existing bid and
ask orders cancelled, and further transactions with it will be disabled. The
GPS token balances of the GPS child chain will be based on 1:1 snapshot of the
GPS asset at that height.

## Child Chain Control ##

The child chain control functionality as described at
is now available on the Ardor blockchain, making it a unique hybrid
public-permissioned platform. Child chains can now be made permissioned,
allowing only authorised users to submit transactions on them, while still
being a part of the public blockchain and relying on its consensus mechanism.

New APIs have been added to grant, revoke, or query account permissions on
permissioned child chains: GetAccountPermissions, AddAccountPermission,
RemoveAccountPermission, GetChainPermissions.

On testnet, the AEUR child chain will become permissioned at the testnet
hardfork block, to be used for future testing of child chain control. On
mainnet, it will become permissioned at the next mainnet hardfork block, thus
disabling further transactions with AEUR.

## Node Configuration ##

Configuration of is now supported from inside the wallet using
the new node configuration page. New GetConfiguration and SetConfiguration APIs
have been added. Add-ons that make use of their custom properties in the file can define a getConfigProperties method returning the
configuration metadata for such properties, to allow those to be displayed and
edited from the node configuration page.

## LedgerLogger add-on ##

The new LedgerLogger add-on allows logging of Account Ledger records of
selected accounts to a flat csv file, ledgerlog.csv, optionally decrypting
message attachments if the private keys of these accounts have been provided.
In addition to enabling the add-on by setting nxt.addOns=LedgerLogger, users
should set nxt.ledgerTrimKeep=0 to enable logging of ledger entries even before
the default trim height, set nxt.ledgerLogUnconfirmed=0 to only log confirmed
balance changes, and set nxt.LedgerAccounts to a list containing the accounts
to be included in the output. Optionally, the log can be limited using the
nxt.LedgerLogger.from and properties to define a date range
in a 'yyyy-MM-dd HH:mm:ss Z' format. To decrypt message attachments, the
secret phrase or the private key of each account can be provided respectively
in the nxt.secretPhrase.<account> or nxt.privateKey.<account> property. A full
rescan or re-download is needed to actually generate the ledgerlog.csv file
after the add-on has been enabled and configured.

## Improved Bundler fee rate calculator ##

When submitting a child chain transaction without specifying a fee, users can
now specify a transactionPriority parameter, displayed as a slider in the UI.
Transaction with higher priority will use a fee higher than the best bundler
rate, based on the higher rates announced by other bundlers, thus increasing
the chances of the transaction to get bundled. The bundlers to be considered
can still be filtered using the nxt.bestBundlerRateWhitelist property.

## Other improvements ##

Light client networking
Implemented bootstrap of API proxy - try to connect to known peers and if this
fails, connect to trusted nodes to get latest open API peers. The purpose is
to either have a node serving the proxy at start, or to know that the network
is down, and also to fix the problems caused by old initial peers.

Default bootstrap node is defined in;

The new BootstrapAPIProxy API can be used to refresh the latest open API peers
from the bootstrap node.

Added a new property nxt.stopDownloadHeight to allow forcing the blockchain
download to stop once a certain height is reached.

Added a new GetEpochTime API, to return the blockchain epoch time given a unix
timestamp. Added unixtime to GetTime response.

The APIs returning expected transactions now return both bundled and
non-bundled transactions.

The Node JS module provided with the installation no longer depends on the
availability of the JQuery and JSDom modules thus making it easier to
integrate with 3rd party libraries. The latest version is now published on

Improved prunable data retrieval, genesis block loading, database shutdown.
Improved keeping track of remaining bundler fees limit.

Optimize checkpoint calculation by using hash of checkpoint block bytes
instead of hashing all intermediate transactions.

Performance optimizations in trimming of the derived tables to speed up
blockchain download.

Trimming frequency can now be modified per table by setting a frequency
modifier property nxt.trimFrequencyMultiplier, which contains a list of
dash-separated pairs [schema.]table_name-frequency.

When attaching a message to a transaction, the boolean parameters messageIsText
and messageToEncryptIsText, if supplied, are now used also when the message
data is uploaded as a file, overriding the mime type auto detection.

Support multiple file parameters in the API requests that accept file uploads.

Usability of the wallet was enhanced for small screen form factor. Tables
use horizontal scrollbar when necessary and some widgets change their look
when the screen width is reduced.

Wallet static resources, Html and Javascript files, are now downloaded in
parallel to significantly reduce the startup time.

Branded Account Prefix
When specifying a recipient address users can use any alphabetic prefix they
like before the first '-' symbol. The default prefix is determined by the
account address used during login and the default for the login account can be
defined in the device settings dialog. The default setting is "ARDOR". When
using a branded account prefix the account addresses returned by API calls
still use the "ARDOR" prefix regardless of the branded account value.

Updated Jetty to version 9.4.29 and Bouncy Castle to 1.65.

## Backward Compatibility ##

The SplitSecret API now accepts a "privateKey" parameter. The existing
"secretPhrase" parameter was renamed to "secret" since it can represent
seed words as well.
Similarly the response of the CombineSecret API now returns the attribute
"secret" instead of "secretPhrase".

Server APIs and client side code will no longer accept as parameter a hex
string with an odd length.



 on: June 15, 2020, 08:08:37 am 
Started by Jose - Last post by Jose
Weekly Wins - 15th of June, 2020
More info -

 on: June 12, 2020, 01:28:06 pm 
Started by Jose - Last post by Jose
Ardor Virtual Workshop | 18th of June, 2020

 on: June 11, 2020, 04:24:16 pm 
Started by Jose - Last post by Jose
ARDOR v2.3.0e will be released next Tuesday

 on: June 10, 2020, 07:19:02 am 
Started by Jose - Last post by Jose
Triffic is now out of beta
Triffic is built on Ardor. Earn cryptocurrency just for walking!
visit for more info and to find the download links

 on: June 08, 2020, 07:41:41 am 
Started by Jose - Last post by Jose
Weekly Wins - 8th of June, 2020
More details -

 on: June 06, 2020, 02:43:45 pm 
Started by Jose - Last post by Jose
Ardor Blockchain Platform explained by Switchain
Full articles - &

 on: June 06, 2020, 07:39:10 am 
Started by Jelurida - Last post by sergi
I think you're answering yourself correctly.

Yes, you can run two instances on the same port with different IP addresses using the nxt.apiServerHost configuration property.

But those instances won't be seen as OpenAPI. That's correct. Detecting some edge cases like the one you're mentioning won't be easy. And I don't see much utility about the setup that you describe.

You can use different port numbers and do the trick using the operating system firewall, for example.

Pages: 1 [2] 3 4 ... 10