Nxt Software Change Log

Version 1.12.0e

This is an experimental release, enabling several new features on testnet only at block height 2500000. All testnet nodes must upgrade to this release before this block (expected Sept 1, 2019). This release can also be used on mainnet but upgrade is optional.

New features:

Added Asset Dividends payment by asset or currency. This allows paying asset dividends not only in NXT, but also in any asset or monetary system currency.

Added Asset Properties feature, to allow setting arbitrary name/value metadata on assets. Any user can set a property on any asset, only the asset issuer or the user who sets the property can delete it.

Added Asset Increase transaction, allowing asset issuers to increase the total number of asset shares available.

The Asset Delete History has been renamed to Quantity Change History and now shows both asset deletion and new shares issuance transactions. The getAssetDeletes API has been deprecated and a new getAssetHistory API can be used to retrieve asset deletions, increases, or both.

Asset Dividends by Holding, Asset Properties and Asset Increase are currently testnet-only features and will be enabled on mainnet at the next planned hardfork block, exact height to be announced later.

New APIs related to the above features:

getAssetHistory, increaseAssetShares, getAssetProperties, setAssetProperty, deleteAssetProperty

Process management add-ons, APIs and UI:

When enabling add-ons using the nxt.addOns property, if a package name is not specified, the nxt.addons package is assumed, therefore it is no longer needed to specify the full package name for the default add-ons included in the release.

Added StartForging and ForgingEncrypted add-ons to facilitate management of forging processes.

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 ForgingEncryptedConfig add-on can be used to store the passphrases of forging accounts in an encrypted file. This add-on exports two APIs: saveForgingEncrypted and startForgingEncrypted, used respectively to save the list of forging passphrases in an encrypted file, and 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.

Added StartFundingMonitors and FundingMonitorsEncryptedConfig add-ons to facilitate management of funding monitor processes.

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. The secretPhrase parameter needs to be manually added to the JSON for each funding monitor.

The FundingMonitorsEncryptedConfig 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. It exports two APIs for this purpose, saveFundingMonitorsEncrypted and startFundingMonitorsEncrypted.

The SaveEncrypted APIs require the admin passphrase when used on a remote node. To prevent overwriting arbitrary files, they will only overwrite an existing file located in the conf/processes directory and with a default for the add-on filename; otherwise the file must not already exist.

An UI for the above ForgingEncryptedConfig and FundingMonitorsEncryptedConfig add-ons has been added, accessible under the cogwheel/processes menu.

Accounts under account control are no longer allowed to start FundingMonitors.

Java programming API:

As an alternative to programming against the http API, the same API calls are now accessible from java programs using the so called APICallers. Those are available in the nxt.http.callers package, and code samples for how to use them are provided under src/java/com/jelurida/ardor/client/api, demonstrating tasks such as local signing, message encryption and decryption, waiting for a new block, etc. When integrating the Nxt functionality in your java programs, using APICallers is the recommended approach instead of accessing core Nxt classes directly.

Light client networking improvements:

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 nxt.properties: nxt.proxyBootstrapNodes=nxt.jelurida.com;

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

Performance and stability improvements and bugfixes.

Windows and Mac installations now use by default an embedded Open JDK 11 installation.

The H2 database now uses the newer MV_STORE format by default. Conversion to this format however takes effect only when running compact.sh on an existing database, or re-downloading the blockchain from scratch.

Updated Jetty to version 9.3.27, H2 to 1.4.199.

Version 1.11.15

This is a critical bugfix release. IMMEDIATE update is mandatory for everyone.

Fixed validation of string fields length in transaction attachments.

Fixed locale issue affecting Turkish users.

Allow setting the Content-Type header of the API responses to application/json instead of text/plain using the nxt.apiFixResponseContentType property. Default is still text/plain to preserve compatibility.

Updated libraries to Jetty 9.3.24, Bouncy Castle 1.60, IzPack installer 5.1.3.

Version 1.11.14

Updated the translation resource files.

Updated default peers, added checkpoint at height 1865000.

Version 1.11.13

Desktop wallet performance optimizations to reduce excessive load.

Do not allow login using passphrase to a non-existing account to prevent users from losing their funds due to a typo. Use the "choose your own passphrase" link under "create new account" if you really need to login to a non-existing account using passphrase.

Client UI enhancements and bugfixes.

Version 1.11.12

Fixed peer disconnections while downloading the blockchain. Upgrade to this release is recommended for all public nodes, to help improve download speeds.

Snapshot code bugfixes. Added a checkpoint after the snapshot hardfork.

Made all toLowerCase/toUpperCase conversions locale insensitive. Should fix the problems with running Nxt under Turkish locale.

Updated Bouncy Castle to version 1.59.

Version 1.11.11

Peer networking improvements, increased nxt.maxNumberOfInboundConnections to 2000.

Snapshot code bugfixes.

Updated Lucene to version 5.5.5.

Version 1.11.10

Removed the IGNIS Token Sale page.

Mobile app bugfixes, node.js module improvements, other minor bugfixes.

Updated jetty to 9.3.22 and bouncycastle to 1.58.

Version 1.11.9

Performance optimizations of derived table trimming and pruning, should fix the issues some nodes encounter with these database operations taking too long.

Other minor bugfixes.

Version 1.11.8

Transaction Scheduler improvements and bugfixes.

Added deleteScheduledTransaction API.

Allow getting all scheduled transactions when no account id is specified in getScheduledTransactions.

Added Scheduled Transactions page. Allow deleting scheduled transactions from the client UI.

Added fake tokens warnings.

Display transactions in the block info modal according to their natural order and mark phased transactions. Added "executed phased" tab.

Added ability to search by block height from the client search box.

Add validate passphrase modal to give users another chance to validate their passphrase after login.

Passphrase recovery tool will now search for a single typo in any position, in case no specific position is specified, and will also work for accounts without a public key.

Version 1.11.7

This release adds the ability to submit a JLRDA purchase transaction from the IGNIS Token Sale page even before the sell offer has been published. Such transactions are not broadcasted immediately, but held in memory and only sent out when the expected sell offer arrives in the unconfirmed transaction pool. For this to work, you must keep the node running after submitting the purchase transaction, until the sell offer has been received and processed.

Note that after submitting a purchase transaction in advance of the sell offer, you will get a pop-up that your currency buy order has been submitted, but it will not show in the unconfirmed pool. This is normal as such advance orders are kept separately.

This functionality is currently available for full nodes only, i.e. those that have downloaded the full blockchain. Users of light clients can submit JLRDA purchase transactions only after the sell offer has been accepted in a block. To switch from a light client to full node, set nxt.isLightClient=falsein conf/nxt.properties, and wait for the blockchain to download.

More IGNIS Token Sale UI bugfixes and improvements: Add paging buttons to the exchange history table on the Ignis page. Initialize the JLRDA units field to 0.

Fixed "calculate fee" when connecting to a remote node with remembered passphrase.

Implemented TransactionScheduler, added ScheduleCurrencyBuy and GetScheduledTransactions APIs.

ScheduleCurrencyBuy API accepts same parameters as CurrencyBuy API, and an additional offerIssuer parameter. Instead of broadcasting the prepared transaction immediately, it schedules it to be broadcast as soon as an unconfirmed currency exchange offer transaction from that issuer, for that currency and a sell rate not higher than the requested, arrives in the unconfirmed transaction pool. The broadcast parameter must be set to false. This API requires a full node (not a light client) and admin password unless running on localhost.

GetScheduledTransactions API returns a list of all scheduled transactions for a given account.

Note that these APIs were specifically added for the purpose of the IGNIS Token Sale, and may be removed or modified in the future.

Other fixes and improvements:

Allow blacklisting the real remote host, not the proxy, when running a public node behind a reverse proxy. Use the nxt.forwardedForHeader property to configure the header added by the proxy to the API http requests (normally X-Forwarded-For).

Fixed printing of paper wallet for passphrases containing special characters.

WARNING: If you printed out a paper wallet for an account passphrase which contains special characters using an earlier release, this passphrase may have been printed out incorrectly, with those characters missing, or truncated. In this case you are advised to print out a correct copy using this version. The QR codes were not affected by this bug, and neither were the standard account passphrases generated by the client.

Also note that some long passphrases may be cut off by your printer unless page size is adjusted to width.

ALWAYS VERIFY THAT THE PRINTED PASSPHRASE IS CORRECT BEFORE RELYING ON A PAPER WALLET AS YOUR ONLY BACKUP!

Version 1.11.6

July 29th, 2017

IMPORTANT LICENSING CHANGE:

The Nxt software is now distributed under the Jelurida Public License (JPL) version 1.0 for the Nxt Public Blockchain Platform. The full text of the JPL is in the LICENSE.txt file (use JPL-NRS.pdf for a printable version).

The client UI remains under the MIT license.

This release is a mandatory upgrade. A hard fork will be scheduled at the Ardor Genesis Snapshot block, expected to be set some time after the end of the IGNIS token sale. At that time, nodes running 1.11.5 or older will be left on a fork.

Added IGNIS Token Sale page. See https://www.jelurida.com/ico for latest token sale terms and schedule.

Added support for the Changelly cryptocurrency exchange.

Added code to disable trading or transferring of assets that will be migrated to Ardor after the Ardor Genesis Snapshot, and delete open ask/bid orders for them at that time. Currently such assets and their ids are:

• ARDR: 12422608354438203866
• Bitswift: 12034575542068240440
• Janus: 4348103880042995903
• JanusXT: 14572747084550678873
• ComJNSXT: 13363533560620557665

Added support for printing a "paper wallet" when creating a new account and from the account details modal.

Added a custom installer panel that allows to: shutdown NXT server if it is running; remove existing installation; customize conf/nxt.properties by choosing from a fixed set of settings.

The pre-defined installer settings are taken from property files under conf/examples. The installer makes sure no settings are in conflict.

Added password recovery tool for brute forcing partially forgotten or mistyped passphrases. Use the passwordRecovery.sh or passwordRecovery.bat script to run, after first setting the known password text fragments and guesses dictionary in nxt.properties. See nxt-default.properties for configuration details.

Added ability to display a custom warning message on the login screen, configurable as nxt.customLoginWarning.

Added active shufflings notification in the header bar.

Added image loading progress bar to the lock screen.

Performance optimizations when under higher transaction load.

Monetary System UI improvements and bugfixes.

API gzip filter is now automatically enabled for open API nodes, unless explicitly disabled in nxt.enableAPIServerGZIPFilter.

Support running Nxt as a Windows service.

Updated mobile app to latest Cordova Android platform.

Added IntelliJ IDE project files to folder ./ide/intellij/project, developers working on the source code should copy the content of folder ./ide/intellij/project to the root folder of the project and open the project from inside IntelliJ using File-Open for the project root folder. The IntelliJ project is pre-configured with the necessary dependencies to build and run the Java source code. To copy the IntelliJ files to the project root folder, open a command prompt at the project root folder and issue the following command:

• Windows: xcopy /e/k/s/h ide\intellij\project
• Linux: cp -r ide/intellij/project/.

Updated H2 to version 1.4.196, bouncy castle to 1.57, and jetty to 9.3.20. Delete the old lib folder first if unpacking on top.

Version 1.11.5

April 1st, 2017

Added firstIndex, lastIndex parameters to the getUnconfirmedTransactions and getUnconfirmedTransactionIds APIs to support pagination.

Minor performance optimizations and UI improvements.

Updated H2 to version 1.4.194 and jetty to 9.3.17.

Version 1.11.4

March 5th, 2017

Added Node JS module, see html/www/js/README.

Minor UI and desktop application bugfixes, ported from Ardor.

Added About dialog.

Version 1.11.3

February 10th, 2017

Fixed missing plugin files error in the client.

Backported minor bugfixes from the Ardor branch.

Treat all text/* media types as text, not just text/plain for the data cloud.

Updated Jetty to version 9.3.16, delete the old lib folder before unpacking on top.

Version 1.11.2

December 26th, 2016

Added "Copy Account" button next to the account id header.

Added again the API and DBShell links to the cogwheel menu.

Minor bugfixes and UI improvements.

Android App updated to use Apache Cordova 6.4.0.

Updated Jetty to version 9.3.15, Bouncy Castle to 1.56, slf4j to 1.7.22, and zxing to 3.3.0, delete the old lib folder before unpacking on top.

Version 1.11.1e

November 28th, 2016

Implemented "Store Remembered Passphrase" setting in the device settings page.

When checked, the client stores the remembered passphrase in the local browser settings or mobile app settings so that the next time the client is launched it will login in automatically.

For the mobile app this setting defaults to true. In other configurations it defaults to false. The stored passphrase is deleted when logging out of the wallet.

Desktop Application now supports request confirmations when running as light or roaming client.

Sign Transaction modal now signs the transaction bytes on the client side.

When the mobile app cannot connect to a randomly selected remote node, it will popup the device settings modal to allow the user to configure a specific node.

When the mobile device is offline, the device settings modal allows signing transactions and generating tokens to support cold storage functionality.

Additional client side bug fixes and refactoring.

Updated Jetty to version 9.3.14 and H2 to version 1.4.193, delete the old lib folder before unpacking on top.

Updated localization component i18next to version 3.4.4

Version 1.11.0e

October 30th, 2016

Added Generators page (under the cogwheel menu), showing the predicted next block generators.

When working as a roaming or light client, data returned by the remote node is validated against other remote nodes. In case of a difference a visual indication is displayed on the toolbar to warn the user that the data returned by the remote node may not be consistent.

The user interface files are now located under html/www instead of html/ui, as this is the path required by the Apache Cordova framework used by the mobile wallet.

The lockup screen now displays a button group of "by account", "by passphrase", "by QR code" login options side by side above the credentials entry field, instead of the old "By Account" / "By Password" toggle button.

Scanning a QR code for login, has been implemented by clicking the QR code icon on the lockup screen. When the value scanned matches an NXT account format it will be treated as account login, otherwise the value scanned will be treated as the account passphrase.

The old "Remember Account" and "Remember Passphrase" checkboxes were merged into a single "Remember Me" checkbox.

Save passphrase in local storage when using passphrase login with "Remember Me" checked. Choosing logout will clear this data.

Account and passphrase entry fields on modal dialogs now support scanning the value from a QR code by clicking the QR link above the field.

When logging in with passphrase and the "Remember Me" checkbox checked, the "Account Details" modal will display the QR code for the account passphrase in addition to the QR code for the account id.

Experimental support for running the client wallet as a mobile app has been added. See specific documentation at https://nxtwiki.org/wiki/Mobile_App

Updated Jetty to version 9.3.13, delete the old lib folder before unpacking on top.

Version 1.10.3

October 14th, 2016

Removed old code, the Ardor distribution UI, and the getFxtQuantity API, as the Ardor distribution is now complete.

Blacklist peers of version older than 1.10.1.

As a performance optimization, the ARDR asset distribution data is now loaded from the conf/fxt.json for production and conf/fxt-testnet.json files for testnet, instead of being recalculated during blockchain download. If those files are missing, and a rescan or redownload is performed, snapshot data will be calculated again and saved as the corresponding json file in the nxt folder, thus allowing independent validation of the hardcoded distribution data.

Added ShapeShift support to the desktop wallet by using a proxy servlet on the local node.

The security manager which is automatically enabled when add-ons are in use now allows add-on network connections.

Added nxt.disableSecurityPolicy property to disable the security manager even when add-ons are in use, in order to improve performance, default false.

Added nxt.keyStoreType property to configure the keystore type used, default is JKS.

Updated Jetty to version 9.3.12 and Bouncy Castle to version 1.55, delete the old lib folder before unpacking on top.

The copyright of all GPLv2 code contributed by the Nxt Core Developers to the Nxt Reference Software now belongs to Jelurida IP B.V., a private company registered in the Netherlands. Please contact info@jelurida.com for commercial licensing options if the GPLv2 license does not fit your private blockchain needs.

Version 1.10.2

August 28th, 2016

Changed default setting of nxt.apiServerCORS to true in nxt-default.properties, to enable cross origin filter on the API server by default.

Added CORS peer service field, showing whether CORS is enabled for open API nodes.

Recalculate NRS.isLocalhost when api proxy is enabled and blockchain download has finished. Fixed starting funding monitor when running on remote host.

To protect against brute force attacks on the admin password of public nodes, after 3 unsuccessful login attempts the remote host is blacklisted for 1 h.

Version 1.10.1

August 10th, 2016

This release adds transaction replay protection, to be enabled at the hard fork scheduled for block 1,000,000. Upgrading to 1.10.1 or later before that block is mandatory for all.

The ecBlockId and ecBlockHeight transaction fields, previously populated but not used, will begin to be used for enforcing that a transaction submitted on one blockchain or fork will not be accepted on another blockchain or fork that shares the same code. These fields by default will be set to a block 720 blocks behind the last block at the time the transaction is created, and transactions will only be accepted if their ecBlockId and ecBlockHeight values point to an existing block when they are included in the blockchain. This default setting provides protection against replaying the transaction on a hard fork that has diverged more than 720 blocks from the one where the transaction was created.

Light clients that have no way of verifying the ecBlock values returned by a remote node will use hardcoded values, to be updated manually at some releases. Transactions from legacy light clients that leave eBlockId and height set to 0 will still be accepted, but cannot benefit from such replay protection.

All CreateTransaction APIs now accept additional ecBlockId and ecBlockHeight parameters, allowing the default values to be overridden by the client.

Minor bugfixes and UI improvements.

Updated Jetty to version 9.3.11, delete the old lib folder before unpacking on top.

Version 1.10.0e

July 31st, 2016

This is an experimental release introducing the new light client and roaming client features.

The roaming client feature, enabled by default, makes the client immediately usable by forwarding API requests that need the full blockchain to a randomly chosen peer (remote node), selected to provide the openAPI service. As all html and javascript files are still served locally and not from the remote host, this is considerably safer than just using a remote node. Outgoing transactions are also signed locally, never sending the secret phrase to the remote peer.

This roaming client (API Proxy) mode is used automatically while the blockchain is still downloading, with a switch to full client mode once the download is complete. It can be disabled by setting nxt.enableAPIProxy=false in nxt.properties. For openAPI nodes, the API proxy remains disabled, ignoring this setting. For light clients, the API proxy is always enabled.

The light client feature, disabled by default, makes the node run in roaming mode permanently, without downloading the blockchain at all. It can be enabled by setting nxt.isLightClient=true. Light clients are not advertised as providing openAPI service even if they do have their API publicly accessible.

The remote node to use when in roaming and light client modes is selected randomly, but can be changed manually in the UI, or using the new setAPIProxyPeer API, or forced to a specific peer using the nxt.forceAPIProxyServerURL property.

Remote nodes can be blacklisted from the UI, or using the blacklistAPIProxyPeer API. This blacklisting is independent from peer blacklisting. The API proxy blacklisting period can be set using the nxt.apiProxyBlacklistingPeriod property (default 1800000 milliseconds).

API requests that require sending the secret phrase, shared key, or admin password to the server, for features like forging, shuffling, or running a funding monitor, are disabled when in roaming or light client mode.

While a remote node cannot steal your secret phrase, and data returned by such nodes is escaped to prevent javascript injection attacks, users must be aware that the validity of such data cannot be verified. For example, a rogue remote node can still return fake asset exchange recent trades or open orders prices, or modified voting system poll options and descriptions.

To force using a remote node for testing APIs, the /test-proxy URL can be used instead of /test for the API test page, i.e. http://localhost:7876/test-proxy.

A new sendTransaction API has been added, similar to broadcastTransaction but without validating the transaction, without re-broadcasting the transaction and without adding it locally as unconfirmed transaction. This API is mostly useful for light or roaming clients that cannot validate or accept locally unconfirmed transactions, but must nevertheless be able to send such to peers.

A new getNextBlockGenerators API has been added, returning the next block generators ordered by hit time. The list of currently active forgers is first initialized using the block generators with at least 2 blocks generated within the previous 10,000 blocks, excluding accounts without a public key. The list is updated as new blocks are processed. The results are not 100% correct since previously active generators may no longer be running and new generators won't be known until they generate a block.

Added a peer info modal. Minor other UI improvements and bugfixes.

Version 1.9.2

July 2nd, 2016

This is the first stable release in the 1.9 series. Update to this release on mainnet is optional up until block 1000000 (Oct 12), however users are advised to do it earlier, as after July 14th updating will trigger a blockchain rescan.

• The main new feature in 1.9 is the distribution of ARDR assets. See the 1.9.0e changelog for details.
• Performance optimizations for blockchain rescans and for snapshot balance calculations. Added nxt.dbMaxMemoryRows property to allow setting the H2 MAX_MEMORY_ROWS parameter.
• Updated Jetty to version 9.3.10, delete the old lib folder before unpacking on top.

Version 1.9.1e

June 20th, 2016

Fixed a client UI bug affecting some form submission.

Version 1.9.0e

June 19th, 2016

This is an experimental release. It is a required update for all testnet nodes, optional for main net.

This release enables taking multiple snapshots of accounts NXT balances, every 60 blocks, for a period of 90 days, and distributing an ARDR token based on the average of those balances, at the end of the snapshot, to be used for the Ardor consensus chain token distribution in Nxt 2.0.

On testnet, the snapshot will start at block 649400 and end at block 779000 (June 24). On mainnet, the snapshot will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12).

Since on testnet the starting block is in the past, on upgrade to this release a blockchain rescan will be performed automatically in order to calculate past account balances. Those who delay upgrading their mainnet nodes until after block 870400 will also experience such a rescan. However, the hard fork block is set at the end of the snapshot, so the final deadline for upgrading to 1.9 is at blocks 779000 and 1000000 respectively.

To get your ARDR tokens, it is essential that you keep your NXT balance in your own account. There is no need to run a node or forge. It is the confirmed NXT balance that is used for the snapshot, not the unconfirmed (available) balance, so having some NXT locked in open AE bid orders, shufflings, etc, will not affect your ARDR distribution. For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

• A new getFxtQuantity API has been added, which allows retrieving the already accumulated ARDR quantity for each account during the snapshot, and an estimate for the quantity yet to be obtained. While snapshots are done every 60 blocks, the numbers that this API returns are updated once every 720 blocks only.
• Snapshot balances used for the ARDR distribution for a specific account can be recorded in the log by setting the nxt.logFxtBalance property to that account number, and performing a rescan if the snapshot has already started.
• Added some additional transaction bytes validation, and phasing parameters validation, to take effect after the hardfork.
• Added getAssetDividends API, to retrieve the dividend payment history for an asset. It can be viewed in the client by clicking on the new "View Asset Dividends" link on the asset exchange page. Dividend payments made before a node is updated to 1.9.0e will not show in this history, unless a blockchain rescan is forced manually.
• After the hardfork block, asset dividend payment transactions will be limited to not more than one per asset every 60 blocks.
• Added a new Messages table in the client UI. Allowed uploading a file as a message attachment, plain or encrypted, and downloading such messages as files.
• All create transaction APIs that support prunable message attachments now also optionally accept multipart file uploads as messageFile or messageToEncryptFile parameters, or when using client-side encrypted data the data part can also be uploaded using encryptedMessageFile parameter. As the test API page does not support multiple file upload parameters, upload buttons for those are not currently available there.
• Accept sharedKey parameter in downloadPrunableMessage and getPrunableMessage APIs.
• Added client UI support for decrypting messages using a shared key, to allow disclosing the shared key for a specific encrypted message to a third party in order to decrypt it without having to reveal the account passphrase.
• Forging optimization to reduce block skipping when switching forks.
• Minor other bugfixes and UI improvements.
• Updated H2 library to version 1.4.192, tika to 1.13, and slf4j to 1.7.21. If installing manually, make sure to delete the old lib folder first.

Version 1.8.3

May 21st, 2016

This release contains a number of improvements and bugfixes.

API changes:

• Optional includeHoldingInfo parameter added to the GetAccountLedgerEntry and GetAccountLedgerEntry APIs.

UI improvements:

• Account switch no longer reloads the wallet.
• Numeric decimal position, thousands separator and date formats are now locale based. The default browser locale language is used by default. A new "Regional Format" client side setting provides the ability to override the default.
• Numeric formatting is now implemented for most table columns which display NXT amounts or holding amounts. The number of decimals positions in each cell is calculated according to the largest number of decimals required and zeros are padded to the right.
• Amounts specified in NXT are limited to the number of decimal positions specified by the "Maximum NXT decimal positions" client setting. The default behavior is to display two digits after the decimal position.
• UI improvements for transaction tables, displayed in the dashboard and other pages. Height column was added as a link to the block in which the transaction is included.
• Starting the wallet on a specific asset page is now supported.

Desktop Wallet:

• Right click functionality for copy/cut/paste of input fields and copy of label text is now enabled. Right click menu on the asset exchange left pane is enabled.
• Entering admin password in the UI settings is no longer required when using the desktop wallet.

Upgraded jetty to version 9.3.9, make sure to delete old lib folder first if updating manually.

Version 1.8.2

April 18th, 2016

This is a bugfix release. All users running 1.8.0e or 1.8.1 should upgrade.

• Added html escaping of product names for marketplace recent listings.
• Fixed marketplace listing for items without image.
• Only show completed purchases in recent purchases.
• Implemented import contacts for the desktop wallet UI.
• Other minor UI improvements and bugfixes.
• Allow absolute paths for keystore file location in nxt.keyStorePath property.

Version 1.8.1

April 8th, 2016

This is the first stable release in the 1.8 series. Please also read the 1.8.0e changelog for all new features and changes since 1.7.5. This release does not require a hard fork and upgrading to it is optional. It will not do a rescan either, but once upgraded to 1.8.1, going back to older version requires downloading the blockchain again or restoring the nxt_db folder from backup.

API enhancements:

• Added getSharedKey API, to allow calculating the one-time shared key used for encryption of messages. Parameters are the secret phrase for one of the accounts, the other account, and the nonce used in the message encryption.
• The readMessage API now also supports decryption of encrypted message parts using the shared key, as provided by the above getSharedKey API, instead of the secret phrase. An optional retrieve parameter is also supported to request automatic retrieval of pruned message parts from archival nodes.
• The getDGSPurchase API now supports decryption of the purchased goods, using either the secret phrase of the buyer or seller, or the shared key from the getSharedKey API.
• The getBalance API now supports an optional height parameter to retrieve account balance at previous heights, if still available.
• The getPolls and getAllShufflings APIs now support an optional finishedOnly parameter, to retrieve only polls or shufflings that have already completed.

Add-on framework improvements:

• Add-ons can now register their own http API request handlers, allowing custom request types to be supported. Overriding existing client APIs is not allowed. See the example add-on nxt.addons.PopOffCounter. Such APIs must be tagged with APITag.ADDONS and will appear under "Add-ons" on the API test page.
• The add-on framework supporting custom APIs, in combination with the client-side plugin system, present an opportunity for developers to add functionality to the NRS without having to modify core code. Add-on developers should be aware that the Java API in 2.0 will undergo many changes, and add-ons code will have to be updated. And users are again reminded to only install and run add-ons from trusted sources.

UI improvements:

• Added pagination to the recent marketplace listings and recent purchases pages.
• Added finished polls and finished shufflings tables under the active polls and active shufflings respectively, with pagination. A "view" action for polls now makes it easy to view the results of an active or finished poll.
• Added full-size image display in a new modal, when clicking on an image in the marketplace listings or purchase modal.

Other minor bugfixes and improvements.

Version 1.8.0e

March 30th, 2016

This is an experimental release. It adds several new features, which however do not require a hard fork.

JavaFX UI:

• A desktop wallet UI, mostly equivalent to the in-browser UI, is launched on supported platforms automatically when the server is started by clicking on the Nxt desktop icon or start menu shortcut.
• More details about the JavaFX UI are available at: https://bitbucket.org/JeanLucPicard/nxt/issues/338/desktop-wallet
• The property nxt.defaultDesktopAccount can be used to specify an account to login to automatically once the desktop wallet loads.
• The desktop wallet UI can be disabled by setting nxt.launchDesktopApplication=false
• The pre-compiled package will still run if JavaFX is not available, but to recompile the code on such platforms the compile-nojfx.sh script must be used, which skips the compilation of the desktop wallet.
• The installer now creates a start and stop menu shortcuts and desktop icons on Unix platforms too, which start the NRS client in desktop mode. From the command line, use the new start.sh script to start the client in desktop mode, and the corresponding stop.sh script to stop it. The start.sh and stop.sh scripts can be run from any directory.
• The jar installer package has been replaced with a self-extracting shell script package nxt-client-1.8.0e.sh, which Unix users can just run, or click on, in order to launch the installer. An advantage of using the installer instead of the zip package is that the installer will create the above mentioned menu shortcuts and desktop icons, and will also automatically remove old libraries from previous installations in the same directory.
• A known bug (of IzPack it seems) is that on Unix the installer fails to create desktop icons when installing in a not yet existing target directory. It will also fail to remove old menu shortcuts and desktop icons, so first running an uninstall of a previous installation is still advisable.

Incompatible change:

• Note that when run in desktop mode on Unix and Mac, the ~/.nxt directory is now used to store configuration files, logs, and the nxt_db blockchain database. This makes it simpler to upgrade to a new version, by deleting the content of the old nxt installation directory, as no user configuration files or database files are stored in it.
• The run.sh script continues to use command line mode, i.e. does not attempt to start the desktop wallet and desktop tray icon, and continues to use the nxt installation directory from within which it must be run to store the nxt_db database, logs, and configuration files. Users who want to use desktop mode but still use the nxt installation directory instead of ~/.nxt for those files can use the run-desktop.sh script instead.

Funding Monitor:

• The new Funding Monitor feature provides monitoring account balances, and their automated replenishment from a funding account, based on account properties set by the funding account to the monitored accounts.
• NXT, asset, or currency balances can be monitored. If a balance falls below the configured threshold, a transaction will be submitted to transfer units from the funding account to the monitored account. A transfer will remain pending if the number of blocks since the previous transfer transaction is less than the interval configured for the monitor.
• The APIs for the Funding Monitor feature are StartFundingMonitor, GetFundingMonitor, and StopFundingMonitor. Detailed documentation for those is provided in the API javadoc files. A user interface for setting and viewing currently running Funding Monitors is accessible from under the cogwheel menu.

Client UI page or modal redirection. By adding page or modal parameters to the http://localhost:7876/index.html URL, the client can be redirected to open a specific page or modal pop-up, with pre-populated parameter values. For usage example, see: https://bitbucket.org/JeanLucPicard/nxt/pull-requests/42/added-page-redirect-modal-popup-with

The Marketplace has been enhanced by adding recent listings and recent purchases tables, showing the last 10 goods listed or purchased.

Marketplace listings now can have images. Image files are uploaded as prunable unencrypted binary message attachments to the DGSListing transaction. A new messageFile file parameter has been added to the dgsListing API, to allow direct upload of files as multipart form data. This parameter is also supported by all createTransaction APIs which allow message attachments, but is not exposed on their /test API pages.

Image attachments that have been pruned are retrieved automatically from archival nodes when the user views the page.

A new downloadPrunableMessage API has been added, to allow downloading of prunable message attachments directly as binary data. An optional secretPhrase parameter is supported, to allow decryption and downloading of the encrypted part of the message instead of the plain text part.

The nxt.apiSSLCiphers property can be used to select which SSL ciphers should be enabled for the API server when using SSL.

Unless overridden in nxt.myPlatform, the real system platform is now shown in the peer info, as found in the java os.platform and os.arch system properties.

Other minor bugfixes and optimizations.

Updated jetty to version 9.3.8, lucene to 5.3.2, tika to 1.12, and slf4j to 1.7.18. Delete the old lib directory first when installing manually on top of a previous installation. If using the installer, old libraries will be deleted automatically, as well as any existing files under the classes and html directories, excluding html/ui/plugins.

Server-side add-ons:

• It is now possible to trigger script execution, or really add any custom Java code to the server, by writing a class which implements the nxt.addons.AddOn interface, making sure it is on the classpath, and enabling it by adding its name to the nxt.addOns property. See the example add-ons in the nxt.addons package. The AfterStart and BeforeShutdown add-ons can be used to trigger scripts to be run just after the server has started, and just before shutdown. Java source files for add-ons can be placed under addons/src to be compiled with the compile.sh script, and the resulting class files under addons/classes will be included on the classpath at runtime.
• This is an unsupported feature for developers only. While in the 1.x series the Java API is expected to be stable, it will undergo significant refactoring in 2.0. Keep any custom add-on code simple, and be prepared to have to change it for 2.0 or discard it. It should also be obvious that such custom Java code can crash your node or have unexpected side effects.
• Malicious add-ons installed under the classes directory can easily get access to your secret phrase. For add-ons installed under addons/classes, this has been made more difficult, but they could still do other malicious acts. Therefore, do not install and run add-ons from untrusted sources.

Version 1.7.5

January 25th, 2016

• Code cleanup and removal of logic no longer needed after the 1.7 hard fork has been passed. Added checkpoint at block 622000.
• Peers running versions older than 1.7 are now blacklisted.
• Allow disabling of specific API or groups of API using the nxt.disabledAPIs and nxt.disabledAPITags properties, each taking a list of API request names, or API tag names, separated with ';'. For example:
  • nxt.disabledAPIs=startForging; startShuffler
  • nxt.disabledAPITags=Create Transaction; Tagged Data

  will disable the startForging and startShuffler API, and all API that are listed under the Create Transaction or Tagged Data tabs on the API test page.

• The enabled/disabled status of each API or APITag is exposed in getConstants.
• The client UI hides menus related to disabled API tags and the "Send NXT", "Send Currency" and "Send Message" buttons are hidden automatically when their corresponding API is disabled.
• The getAccountLedger API has been fixed to always apply the firstIndex, lastIndex pagination to the final list of entries matching the query, rather than to all entries for the given account or based on block height.
• Use fixed shuffling transaction timestamps. To prevent timestamp correlation attacks, all shufflers now use the same transaction timestamp, set to the last block timestamp.
• Performance optimizations. Account public keys are now cached in memory. This cache currently takes around 12 MB at most, and can be disabled by setting nxt.enablePublicKeyCache=false.
• Back button added to the transaction info, account info, block info and ledger info modals. Use the back button to return to the previous info modal.
• Updated H2 to version 1.4.191. The MVStore storage engine is disabled by default as it is still in beta, PageStore continues to be used. As this version no longer accepts implicitly relative jdbc URLs, if you have configured a custom db location in nxt.properties, make sure to prefix the path with ./ if it is not absolute, e.g. nxt.dbUrl=jdbc:h2:./nxt_db/nxt... instead of nxt.dbUrl=jdbc:h2:nxt_db/nxt... . If unpacking on top of existing installation, delete the old lib folder first.
• Token generation is now supported when using the "Remember Passphrase" option and the NRS.signBytes() method now uses the remembered passphrase in case the passphrase parameter is not specified.
• The transition effect displayed when hiding the left menu was disabled since it is causing UI rendering problems under certain conditions.
• "Switch Account" button added to the account info dialog. Clicking it would switch the wallet to this account.
• "Refresh Search Index" option added to the "Settings" menu. Use it to rebuild the search index in case you are no longer getting correct search results.
• Added UI for issuing singleton asset.
• run.bat now works on Windows XP and Windows 2003. Database, configuration files and logs are stored in the roaming folder under the user folder and tray icon is operational.
• Nodes that update from version older than 1.7.3e to this release after the hard fork block will have blocks after 621000 deleted, to make sure they switch to the 1.7.4 fork.

Version 1.7.4

January 1st, 2016

• This is the first stable release in the 1.7 series. It is a mandatory update for everyone. There is a hard fork scheduled for block 621000, estimated to occur around Jan 21, 2016, at which new features will be enabled. Nodes that do not update to 1.7.4 or later by this date will be left on a fork.
• On testnet, the hard fork block is already passed, and all new features are fully functional.
• There were incompatible API changes introduced in the 1.6 series. API users still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs and forum announcements, before upgrading to 1.7. These changes do not affect regular end users who just run the NRS client on their desktop or VPS node.
• The new features and improvements in the 1.7 series have been documented in the 1.7.0e through 1.7.3e changelogs, available in the changelogs directory.

Here is a high level summary of the new features to be enabled after the hard fork:

• Coin Shuffling, a fully decentralized coin mixing, to improve account privacy.
• Account Control for phased transactions, the Nxt equivalent of multisignature.
• Immediate release of certain types of phased transactions on approval.
• Improved block times, 60 s average, long block times now extremely unlikely.
• Account Properties, assigning arbitrary name/value metadata to user accounts.
• Singleton Assets, useful for representing single tradeable objects.
• Dynamic fees, proportional to the relative transaction size.
• Improved Exchange Booth UI.
• Data Cloud, adding a UI and multiple enhancements to the existing Tagged Data feature, to allow decentralized, censorship-free and tamper-proof publication and retrieval of small files, documents, or arbitrary data. This feature is not dependent on the hard fork and will be fully usable immediately on update to this release.

Changes added since the 1.7.3e release:

• Added detectMimeType utility API, allowing auto-detection of the mime type of uploaded file or data, using the Apache Tika library.
• The uploadTaggedData API now uses such mime type auto-detection to determine the mime type of uploaded data when the user has not explicitly provided a type parameter. It also automatically sets the isText property to true for data of type text/plain only.
• Made the maximum permitted number of forgers or shufflers running at the same time configurable, default 100 each, using the nxt.maxNumberOfForgers and nxt.maxNumberOfShufflers properties.
• The default value of includeCounts parameter in the searchDGSGoods API is now also false, this API was inadvertently missed when globally changing the defaults to false in the 1.6 branch.
• Various UI improvements.
• Updated Bouncy Castle library to version 1.54.

Version 1.7.3e

December 20th, 2015

This is an experimental release for testing only. Source code is not provided.

Change log:

• This is an experimental bugfix release. It is a mandatory update for testnet nodes.
• Added retrievePrunedTransaction API. This API can be used to force retrieval of the prunable data for a given transaction, even if past the configured nxt.maxPrunableLifetime. Using this API to retrieve pruned data however does not increase its lifetime, i.e. at the next scheduled table trimming the data will be pruned again if expired. This API queries all currently available archival peers, until the missing data is found, therefore it can take some time to complete, and can also return no results if there are no such peers online, or none of them has the requested data. Consistent with the behavior of getTransaction and related API, the returned transaction JSON will not have the prunable parts included if they have already expired and nxt.includeExpiredPrunable=false (default is true), but if those parts have been successfully restored, they can be requested using the more specific APIs such as getPrunableMessage, getTaggedData, etc.
• The getPrunableMessage, getTaggedData, and downloadTaggedData APIs now support optional "retrieve" parameter, default false. If the corresponding data has been pruned and retrieve is true, an attempt will be made to retrieve the data from archival peers, as if using the retrievePrunedTransaction API.
• Added getReferencingTransactions API, returning the transactions referencing a given transaction id.
• Added getLinkedPhasedTransactions API, returning the phased transactions with by-transaction voting model for a given linkedFullHash, regardless of their phasing status (pending, approved or rejected). Since the corresponding table is trimmed after finish height however, the result will not include those transactions that finished before the last trimming height.
• Increased maximum leasing period to 65535 blocks, to take effect after the hard fork.
• Shuffling UI improvements.
• Added UI for the Tagged Data feature, now known as Data Cloud.
• The Exchange Booth UI has been improved. The user must only enter the number of currency units to be bought or sold, and the server determines the maximum or minimum rate required in order to obtain or sell this amount, based on the current market offers available. This avoids the creation of exchange requests that cannot be filled, and eliminates the need for manually calculating the required exchange rate.
• To prevent clickjacking exploits, a new http header is now added by default to all http API responses, X-FRAME-OPTIONS: SAMEORIGIN. This can be turned off by setting nxt.apiFrameOptionsSameOrigin=false in nxt.properties.

Incompatible changes:

• The taggedData field in the getAllTaggedData API response has been renamed to data, for consistency with the other get*TaggedData APIs.
• The behaviour of the currencyBuy API has been fixed, to exchange no more than the number of currency units specified in the units parameter. Currently, the total amount of NXT as calculated from rate * units is exchanged for currency, even if this results in purchasing more than the number of units requested, which is non intuitive and not consistent with the way currencySell works. This change will take effect after the hard fork.
• Updated Jetty to version 9.3.6 and slf4j to version 1.7.13. Make sure to delete the old lib folder if unpacking over a previous installation.
• This release will do a blockchain rescan on testnet and may delete blocks after certain height, to resolve testnet forks.

Version 1.7.2e

December 7th, 2015

This is an experimental release for testing only. Source code is not provided.

Change log:

• This is an experimental bugfix release. It is a mandatory update for testnet nodes.
• Accounts under phasing only control are not allowed to create or join shufflings, or start shufflers.
• Shuffling UI improvements. The My Shufflers page has been merged with My Shufflings.
• Added includeParticipantState parameter to getShufflers, to allow retrieving shuffling participant state too with the same request.
• The deleteAccountProperty API has been fixed to accept both recipient and setter parameters, to be able to delete properties set to the account by another account.
• For consistency with setAccountProperty and deleteAccountProperty, the getAccountProperties API account parameter has been renamed to recipient. The account owner is also identified as recipient in the JSON fields of the properties returned.
• Added getAvailableToBuy and getAvailableToSell Monetary System APIs, to allow calculating the rate required in order to completely fill an exchange request, or the maximum available currency units or NXT amount considering the current market offers.
• Added Account Properties UI.
• Account Control UI improvements and bugfixes.
• This release will do a blockchain rescan on testnet only, deleting blocks after height 484310.

Version 1.7.1e

December 2nd, 2015

This is an experimental release for testing only. Source code is not provided.

Change log:

• This is an experimental bugfix release. It is a mandatory update for testnet nodes.
• Added nxt.useStrongSecureRandom property, default false, to control whether a strong SecureRandom implementation is used.
• Test speed of SecureRandom on startup and refuse to start if slower than 512 bytes per second.
• Disallow starting multiple shufflers for the same recipient account on the same node, even if for different shufflings.
• Fixed local signing of shuffling create transactions for holdings.
• Added current registrant count to shuffling fields.
• Improved handling of failed transactions submitted by shufflers.
• Improved My Shufflers, My Shufflings, and Active Shufflings UI.
• GetHoldingShufflings should return shufflings of NXT if holding parameter is not specified or zero.
• Blacklist peer versions older than 1.7 on testnet.
• This release will do a blockchain rescan on testnet only.

Version 1.7.0e

November 29th, 2015

This is an experimental release for testing only. Source code is not provided.

Change log:

• This is an experimental release. The new features will be activated at block 483000 on testnet (Nov 30) and 621000 on production (estimated Jan 21, 2016).
• All testnet nodes are required to upgrade to this release. Those that don't will remain on a fork.
• Production nodes will need to upgrade to the stable 1.7 version once it is released (expected before end of December), but in any case before the hardfork scheduled for block 621000.

New features:

• Coin Shuffling. This feature is based on the paper by Tim Ruffing et al, http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .
  • Coin shuffling can be used to perform mixing of NXT, MS currencies (unless created as non-shuffleable), or AE assets. Any account can create a new shuffling, specifying the holding to be shuffled, the shuffle amount, number of participants required, and registration deadline. This is done using the shufflingCreate API. The subsequent shuffling steps can be done either manually, by using the shufflingRegister (for accounts other than the creator), shufflingProcess, shufflingVerify or shufflingCancel APIs, or, much more conveniently, by starting an automated Shuffler, using the startShuffler API. Once started, the Shuffler monitors the blockchain state for transactions relevant to the specified shuffle, and automatically submits the required transactions on behalf of the user, performing shuffle processing, verification, or cancellation as needed. To do this, the Shuffler is required to keep the user secret phrase in memory, therefore it should be run on a trusted local machine only. A restart or a crash of the node requires the shuffler to be started again using the startShuffler API, as it should never save the user secret phrase on disk.
  • To participate in a shuffling, a deposit of 1000 NXT is needed, in addition to the amount of currency or asset being shuffled. Or if shuffling NXT, the amount of the shuffle must exceed this 1000 NXT minimum. If the shuffling completes successfully, this amount is added to the recipient account balance, to allow it to send outgoing transactions (as it is required that only new, unused accounts are specified as recipients). If the shuffle fails due to a registered participant failing to participate as required, or intentionally submitting false data, the participant responsible for the shuffle cancellation is penalized by retaining this deposit and sending it to the forgers of the shuffle finish block and the previous three blocks instead. If a shuffle is cancelled because the required number of participants is not met, nobody is penalized and all deposits are refunded. On testnet, the deposit and penalty is 7 NXT only.
  • After shuffling registration is complete, participants must submit processing data within a 100 blocks period each (10 blocks on testnet). For the verification and blame phase, the total allowance for all participants is 100 + numberOfParticipants blocks (again reduced to 10 + n blocks on testnet).
  • Full blocks are not counted towards the limit. If at any stage the deadline is reached without some participant submitting the next required transaction, the shuffling is cancelled at this participant's fault. It is therefore critical that after registering for a shuffling, the shuffler started is left running until its successful completion. If the node must be restarted, all previously running shufflers must be started again manually.
  • Query APIs to retrieve currently running shufflers, shufflings, and shuffling participants are: getAllShufflings, getAccountShufflings, getAssignedShufflings, getHoldingShufflings, getShufflers, getShuffling, and getShufflingParticipants.
  • If desired, finished shufflings can be automatically deleted from the database if the nxt.deleteFinishedShufflings property is set to true (default is false).
  • The fee for creating a shuffling or registering in one is 1 NXT, for the shuffling process or shuffling cancel transactions 10 NXT, and for the verify transaction 1 NXT.

• Account control for phased transactions. Any account can be restricted to only be allowed to issue phased transactions subject to a specific voting model. This is achieved by the account submitting a setPhasingOnly transaction using the setPhasingOnlyControl API. The getPhasingOnlyControl API can be used to retrieve the status of an account phasing control, and getAllPhasingOnlyControls to get all accounts subject to phasing control with their respective restrictions.
  • Once set, the phasing only account control can only be disabled or changed with another setPhasingOnly transaction, itself subject to the currently set phasing restrictions.
  • Note that by-transaction and by-hash voting models are not allowed for phasing control, and setting voting model to none is used to disable the control.
  • To prevent deadlocks due to cyclic account control restrictions, approval transactions themselves (PhasingVoteCasting) are not subject to phasing only account control.
  • When setting phasing account control, a maximum fees total can be specified, limiting the total fees for currently pending phased transactions of the controlled account, and limits can be placed on minimum and maximum phasing duration allowed.
  • Transactions of accounts subject to phasing account control with restriction on maximum fees are throttled at one per account per block.

• Immediate release of phased transactions on approval. Phased transactions with a voting model that does not depend on account balance (such as by-transaction or by-hash), or by-account with no minimum balance and with a whitelist, will be released before their finish height as soon as approved (in the block in which the transaction causing their approval is executed), if possible. Such early finish is guaranteed for transaction types known to be phasing safe. For others, if the early finish does not succeed due to the transaction failing validation at this height or conflicting with another transaction in the same block, a second, final release attempt will be performed at finish height.
• New base target adjustment algorithm. Average block times will be 60 s, with 1440 blocks per day. Block times should practically never exceed 10 min.
• Limit of 1000 NXT on minimum forging balance. This applies to the total of the account own guaranteed balance plus any balances leased to it, but not to each individual balance lease. An account with balance lower than the limit can still lease its balance to another.
• Account properties. Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts. The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.
• Account properties are managed using the setAccountProperty and deleteAccountProperty APIs. To query the properties of an account, or those set by an account, the getAccountProperties API can be used.
• Singleton assets. Issuing an asset with a quantity of 1, decimals 0, and description length not exceeding 160 characters, will require a base minimum fee of 1 NXT only, instead of the regular 1000 NXT asset issuance fee. For description of more than 32 chars, an extra 1 NXT fee is added for each 32 chars. Asset name for singleton assets is limited to 10 chars, same as for regular assets.
• Throttling of unique resource allocation transactions. Asset issuance (excluding singleton assets), monetary system currency issuance, and alias assignment (excluding re-assignment), will be limited to only one transaction of each type accepted per block.
• Spreading back block fees for asset and currency issuance. The transaction fees for asset (excluding singleton assets) and currency issuance will be split between the forgers of the current and the previous three blocks in a 4:3:2:1 ratio.
• Prunable plain and prunable encrypted message attachments both allowed in the same transaction. The maximum data size for each such attachment is 42 kbytes, but when coexisting in the same transaction the sum of the two is still being limited by the maximum payload size of 44880 bytes.
• Peers that provide http or https API access open to anyone, configured with nxt.apiServerHost=0.0.0.0 and nxt.allowedBotHosts=* , are now labelled as providing a service, API or API_SSL, and can be found using the getPeers API with the corresponding "service" parameter. This API has been modified to accept multivalued "service" parameter, returning peers that match all requested services. The ports on which the open API access is running are included in the peer info of peers providing those services as apiPort and apiSSLPort fields.

Incompatible changes:

• Deletion of asset shares will be performed as a separate AssetDelete transaction type instead of as sending the shares to Genesis. Sending shares to Genesis will no longer be allowed. A new API, getAssetDeletes has been added to retrieve asset deletions, as using the getAssetTransfers API to find transfers to Genesis account no longer can be used for that purpose. There is also a new API, getExpectedAssetDeletes, to get asset deletes expected in the next block, analogous to getExpectedAssetTransfers.
• Since both prunable plain and prunable encrypted messages can now be added to the same transaction, the APIs getAllPrunableMessages, getPrunableMessage, and getPrunableMessages cannot continue to use just a single "isText" boolean field in the JSON response to indicate if the prunable message is text or binary. For all prunable plain messages, a new "messageIsText" boolean field is added, and for all prunable encrypted messages, a new "encryptedMessageIsText" boolean field is added in the response of the above APIs, for each message. For backwards compatibility, the "isText" field will continue to be added, but only for transactions that have either plain, or encrypted, prunable message attachment, not for those that have both. This change does not affect the attachment JSON returned from getTransaction API, as there are already separate messageIsText and encryptedMessage.isText fields there.
• Fees and size limit changes. Several transaction types or attachments will have new fees and size limits, to encourage users to utilize the prunable versions when available, and to make fees proportionate to actual blockchain space consumed.
  • Aliases: Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus URI total length, after the first 32 chars. Name and URI size limits remain at 100 and 1000 chars respectively.
  • Messages and EncryptedMessages (non-prunable): Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the first 32 bytes. For encrypted messages, the length is measured excluding the nonce and the 16 byte AES initialization vector, and to account for those there is an extra fee of 1 NXT. Fees and size limit for prunable messages remain unchanged.
  • AccountInfo: Base fee 1 NXT, with 2 NXT additional fee for each 32 chars of name plus description total length, after the first 32 chars. Name and description size limits remain at 100 and 1000 chars. AccountInfo transactions throttled at one per block.
  • Polls: Base fee 10 NXT for polls with up to 20 options, and total size of poll name plus poll description plus total option length not exceeding 320 chars. For each option above 20, an additional fee of 1 NXT, and for each 32 chars after 320, an additional fee of 2 NXT. Poll creation throttled to one per block. Name, description, and option length limits remain at 100, 1000, and 100 chars respectively.
  • DGS Listing: Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus description total length, after the first 32 chars. Name and description size limits remain at 100 and 1000 max. DGS Listing throttled at one per block.
  • DGS Delivery: Base fee 1 NXT, with 2 NXT additional fee for each 32 bytes of encrypted goods data after the first 32 bytes, nonce and AES initialization bytes excluded. Encrypted goods data size limit remains 1000 bytes.
  • Phasing: In addition to the current fee for phasing (1 NXT for balance independent, 20 NXT otherwise), 1 NXT will be added for each 32 bytes of hashedSecret or linkedFullHash fields.
  • Referenced transactions: An extra fee of 1 NXT for the 32 byte referencedTransactionFullHash if set, i.e. if the transaction is using the referenced transactions feature.
• To facilitate migration of legacy client code to the new fees, if the property nxt.correctInvalidFees=true has been set in nxt.properties (default is false), the server will automatically replace insufficient fees for submitted unsigned transactions with the minimum fee needed, depending on the transaction, as if feeNQT=0 has been specified. Fees exceeding the minimum, or fees for already signed transactions, will not be corrected.
• This release will perform a blockchain rescan on first start.

Version 1.6.2

October 31th, 2015

The 1.6 series is no longer considered experimental. If upgrading from 1.5.15 or earlier, see the 1.6.0e and 1.6.1e changelogs for other important changes in 1.6.

• The account ledger now uses transaction id as event id for all events except block generation. To apply this change, the account ledger table will be automatically truncated on upgrade to this release. Users who desire to restore the deleted past account ledger entries should run a full rescan from the API test page. Note that account ledger records are only kept for 30000 blocks by default.
• Added currency transfers history page to the Monetary System UI.
• Added generate hallmark dialog to facilitate hallmarking your node. The host field is pre-populated with the external node address as detected by UPnP. Note that when using dynamic IP address you should set up and use a dynamic DNS hostname instead of the numeric IP for the hallmark. And when using a non-default port, the host field should be filled as host:port.
• Added "clear results" link in the ShapeShift My Exchanges section, to allow clearing past transaction history. As this history data is being retrieved from the ShapeShift servers, it allows correlating Nxt accounts previously used for exchange transactions with the current user IP address and with each other, thus clearing history after no longer needed is important for the user privacy.
• Funding a new account using ShapeShift now relies on the ShapeShift sendamount API which provides better conversion rate. The user first specifies the amount of NXT to receive, the dialog then presents a deposit address for the source currency which the user needs to fund with the exact amount within 10 minutes.
• Added ledger tab to the account info dialog.
• Added includeAssetInfo or includeCurrencyInfo parameters, default false, to the getAccountAssets, getAccountCurrencies, getAccountExchangeRequests, getExpectedAssetTransfers, and getExpectedCurrencyTransfers APIs.
• Tabs are now sorted mostly alphabetically on the API test page.
• Added nxt.hideErrorDetails property, default false, to allow suppressing node specific configuration details in error messages returned to peers.
• Increased default prunable lifetime setting to 90 days. Minimum enforced is still 2 weeks.
• The UPnP connection timeouts are now also configurable in nxt.properties.
• Updated Bouncy Castle library to version 1.53, Jetty to version 9.3.5, IzPack installer to 5.0.5, and weupnp to 0.1.4. Make sure to delete the old lib folder if unpacking over a previous installation.

Version 1.6.1e

October 11th, 2015

This is an experimental release for testing only. Source code is not provided.

• New feature: ShapeShift exchange integration.
  • The ShapeShift plugin is now integrated in the core NRS package. A detailed description of this in-client coin exchange functionality is available at: https://bitbucket.org/JeanLucPicard/nxt/issues/316/shapeshift-integration
• This release also adds several API changes and optimizations.
  • Added getExpectedTransactions API, to return the non-phased unconfirmed transactions expected to be included in the next block (only), plus the phased transactions scheduled to finish in that block (whether approved or not). Takes an optional multivalued "account" parameter, to filter the result by transaction sender or recipient account.
  • The "account" parameter of getUnconfirmedTransactions and getUnconfirmedTransactionIds APIs can also be repeated multiple times now, to specify more than one account.
  • Several APIs have been enhanced to make dealing with phased transactions easier.
  • getBlock and getBlocks now take an optional includeExecutedPhased boolean parameter, default false. If true, the phased transactions approved and executed in each block (which were accepted in some previous block), if any, are included separately in the response, as either an array of transaction ids or full transaction json depending on the value of the includeTransactions parameter.
  • getTransaction and getBlockchainTransactions now take an optional boolean parameter includePhasingResult, default false. If true, the execution status of each phased transaction is also retrieved and included in the result. The status of each phased transaction is retrieved in a separate database query, so for getBlockchainTransactions requests that retrieve many phased transactions at the same time the performance of this API may not be optimal.
  • getBlockchainTransactions now takes an optional executedOnly boolean parameter, default false. If true, phased transactions that were not executed are not included in the result.
• Incompatible changes:
  • As a performance optimization, many query APIs that accept an object id as parameter, i.e. account, asset, currency, and so on, now no longer load this object from the database if only having the id is sufficient to retrieve the required records. This has the side effect that such APIs now will return an empty result list instead of an error when supplied with a non-existent object id. Missing or malformed id parameters will still return an error as expected.
  • For example, getAssetAccounts will now return an empty shareholder list instead of unknown asset error, when supplied with a non-existent asset id.
  • This change affects the query APIs only, not the create transaction APIs.
  • As another performance optimization, for all APIs that accept optional "include" parameters to retrieve additional data, e.g. includeCounts, includeAssetInfo, includeCurrencyInfo, and so on, the default value of those parameters (i.e. when not explicitly specified) is now assumed to be false. API users will have to set those parameters to true when these extra data are really needed. One important API affected by this change is getAccount, for which now includeLessors, includeAssets, includeCurrencies, includeEffectiveBalance are all assumed to be false if not specified, i.e. only the account NXT balance and info are returned by default.
• As announced with the 1.6.0e release, upgrade to the 1.6 branch is optional, users who depend on the current 1.5 API behavior can stay with 1.5 up until the 1.7 hard fork.
• The default search query operator, used when searching the MS currencies or the marketplace, is now AND instead of OR.
• The Lucene full text search library has been updated to version 5.3.1, and Jetty has been updated to version 9.3.3. Remove the old lib subdirectory if unpacking on top of a previous installation.

Version 1.6.0e

September 11th, 2015

This is an experimental release for testing only. Source code is not provided.

This experimental release adds several major new features. It does not require a hard fork, and update to the 1.6 branch will be completely optional even after it is declared stable. 1.6 peers are compatible with 1.5 peers, but as usual the database changes are not reversible, going back from 1.6 to 1.5 would require starting again from a 1.5 database.

• Account ledger:
  • The account ledger feature provides a record of all recent changes to the account balances (including NXT, asset, and currency balances), and the event that caused each change. It is enabled by default for all account, but can be set to track certain accounts only or be disabled completely, using the nxt.ledgerAccounts property. By default records are kept for the last 30,000 blocks, this can be changed using the nxt.ledgerTrimKeep property. The nxt.ledgerLogUnconfirmed property controls whether confirmed, unconfirmed, or both types of changes are tracked.
  • The new APIs getAccountLedger and getAccountLedgerEntry are used to retrieve account ledger records. Their parameters and response fields are documented in the javadoc.
  • Account ledger events can also be followed using the existing eventRegister and eventWait API.
  • Using account ledger events as an alternative to the getAccountTransactions or getBlockchainTransactions API completely avoids the need to handle phased transactions as a special case. Only changes to account balances that actually happened, and at the time (block height) they happened, are recorded in the account ledger. The account ledger also makes it easier to monitor an account for changes that occurred as a result of past transactions (e.g. an AE order being filled), or are result of dividend payment transactions, or block forging fees.
• Peer services:
  • Peers can advertise to other peers the set of services they provide, and include this information when sharing peer addresses with each other. Currently available services are Hallmark (being a hallmarked peer), and Prunable (providing archival and retrieval service for expired prunable data).
  • To configure a peer to provide the Prunable service, nxt.maxPrunableLifetime must be set to -1 and nxt.includeExpiredPrunable must be true (default). Such a peer will then provide expired prunable data to other peers when requested.
  • If nxt.includeExpiredPrunable is false, the node will still keep prunable data indefinitely (if nxt.maxPrunableLifetime is -1), but will not provide them to others.
  • The services a peer provides are also exposed in the getBlockchainStatus and getStatus APIs. The getPeers API accepts optional service parameter, to filter the result based on desired provided service, and includes the services each peer provides in the peer info.
• Restore prunable data:
  • A peer configured with nxt.maxPrunableLifetime=-1, or any positive value higher than the minimum of two weeks (1209600 seconds), when downloading the blockchain from scratch, will automatically start requesting the missing prunable parts (prunable plain/encrypted messages, and tagged data) from any archival peers it finds on the network (those providing the Prunable service).
  • This task of requesting and restoring missing prunable data can also be triggered using the new retrievePrunedDat debug API, for peers that already have the full blockchain or need to be restarted during the download process. (Note that when nxt.maxPrunableLifetime is set to a positive value, extend tagged data transactions are ignored for the purpose of selecting which pruned tagged data to retrieve, the timestamp on the original upload data transaction is what is being used. To make sure all pruned data are retrieved, set nxt.maxPrunableLifetime to -1, and if really needed set it back to the desired value after the initial restore is complete.)
  • The getBlockchainTransactions API now accepts optional includeExpiredPrunable parameter, to force including expired prunable parts in the response, if available (default false).
• Asset delete: Asset transfers to the Genesis accounts are now treated as deleting the corresponding number of shares, with the total asset quantity adjusted accordingly. A new deleteAssetShares API has been added to perform this function. At the next hard fork (1.7), asset transfers to Genesis will be completely disallowed and the deleteAssetShares API will then create a new AssetDelete transaction type, to achieve the same quantity reduction effect.
• API additions:
  • A new getTaggedDataExtendTransactions API has been added, to retrieve all tagged data extend transactions for a given tagged data upload transaction.
  • The getConstants API now also returns a list of all supported request types and their properties.
  • The approveTransaction API accepts revealedSecretIsText boolean parameter, default false, as a way of specifying whether revealedSecret is text or binary. The old revealedSecretText parameter to submit the text value directly is still supported.
  • Added encodeQRCode and decodeQRCode APIs, to handle the encoding and decoding of QR image on the server side, instead of in javascript, using the ZXing java QR processing library, version 3.2.1. This improves the generation and parsing of QR codes used in offline transaction processing, images that failed to decode correctly using javascript can now successfully be processed.
  • Allow attaching encrypted messages to accounts that don't yet have a public key announced, as long as the public key is included in the same transaction as a public key announcement attachment.
• Several performance optimizations have been included in this release:
  • The last 10 blocks and the transactions in them are now cached in memory. The unconfirmed transactions (up to nxt.maxUnconfirmedTransactions, default 2000) are also cached in memory.
  • Accounts with zero balance are now deleted from the account table, which significantly reduces its size and should make queries for the balances of the active accounts faster. Only public keys for such accounts, if available, are permanently stored in the separate public_key table. Creation of new accounts for one-time use, which is the practice of many exchanges and merchants, should now be less of a burden for the database, as long as such accounts are fully emptied after use.
  • Updated jetty to version 9.3.2. If unpacking on top of a previous installation, delete the old lib subdirectory first.
  • This release will perform a database upgrade and rescan on first start.

Version 1.5.15

August 14th, 2015

Full offline transaction signing support.

• The purpose of this security feature is to allow users to sign transactions without ever entering their passphrase on a workstation connected to the internet, thus avoiding the risk of having their passphrase stolen by locally installed malware such as key loggers or copy/paste loggers, or malicious plugins.
• As a prerequisite to using this feature, users should setup two workstations:
  • (1) online with up to date blockchain, on which transactions will be prepared;
  • (2) offline with Java and NXT installed, but without internet connection, and without needing to have up to date blockchain, on which transactions will be signed.
• The nxt.isOffline=true parameter can be used on the offline machine to make sure it doesn't even try to connect to peers or to listen on the peer port.
• In addition, users should prepare either a web camera to scan QR codes, or a USB stick to copy data between the workstations.
• The following procedure should be followed:
  • On the online workstation - users can create a transaction without entering their passphrase. Click on the "advanced" link, check the "Do Not Broadcast" option, and then check the newly added "Do Not Sign" option that appears. When "Do Not Sign" is checked, the passphrase field is cleared and disabled.
  • If the account submitting the transaction does not yet have its public key announced, a separate input field appears, to allow entering the public key.
  • In response, the server returns the unsigned transaction JSON, and in case there are no message attachments to be encrypted, also the unsigned transaction bytes.
  • The client now displays the "Raw Transaction Details" modal with the unsigned transaction JSON, and the unsigned transaction bytes (including a QR code representing them), if those exist.
  • The unsigned transaction bytes do not include the prunable attachments, however they can still be used for signing the transaction, and also for broadcasting the transaction in case no prunable attachments exist.
  • Users can transfer the unsigned transaction bytes to the offline workstation by scanning the QR code, or download the unsigned transaction JSON to a file by clicking the download icon, and transfer it using a USB stick to the offline workstation.
  • On the offline workstation - users should use the "Transaction Operations" modal, "Sign Transaction" tab, to sign the unsigned transaction JSON, which can be uploaded from a file.
  • In response, a signature field is displayed, with a QR code, and also the signed transaction JSON which users can save to a file for transferring back to the online workstation.
  • Back on the online workstation, users can scan the signature QR code into the "Raw Transaction Details" modal signature field, and broadcast the transaction. Alternatively, they can use the "Broadcast Transaction" tab of the "Transaction Operations" modal to broadcast the transaction JSON copied from the offline workstation.
• A command line tool, sign.sh, has been provided, for signing transaction JSON without needing to even have an Nxt server or a browser running.
• Note that when the transaction to be signed includes a message to be encrypted, the encryption is also performed on the offline workstation. However, when generating the unsigned transaction JSON on the online workstation, if using a remote node, the plain text content of the message must be sent to this node in order for it to prepare the transaction JSON. Therefore, use a local installation when preparing encrypted messages for offline signing, if the content of the message is sensitive.
• All tabs in the "Transaction Operations" modal that have both bytes and json input fields need to have only one of them filled. If in doubt, using the json is preferred, as it will work for all transactions. The bytes format is still accepted, when possible, for backwards compatibility, and for transferring using QR codes (as the json cannot fit in a QR representation).

Other changes:

• The signTransaction API now also returns the full signed transaction JSON.
• The calculateFullHash API now also accepts unsignedTransactionJSON parameter.
• Added getLastTrades and getLastExchanges API, accepting a multivalue asset, respectively currencies parameter, and returning an array containing the last trade or exchange for each of those assets or currencies.
• Added fullHashToId utility API.
• Display warning when trying to issue an asset or currency with less than 2 or more than 6 decimals.
• Display total value of currencies owned on dashboard. Set default leasing period to the maximum allowed (32767) in the UI. Other UI improvements.
• Updated jetty to version 9.2.13. If unpacking on top of existing installation, delete the lib subdirectory first.

Version 1.5.14

July 22nd, 2015

• Using cached thread pool for blockchain download and event listeners threads, resulting in better parallelism and faster blockchain download speeds.
• The getAskOrders and getBidOrders APIs now accept an optional boolean parameter showExpectedCancellations, default false, to show if any of the orders returned are expected to be cancelled in the next block, based on the content of the unconfirmed transactions pool and the phased transactions expected to finish in the next block.
• Expected order cancellations are now shown in the asset exchange UI.
• The calculate hash modal can now be used for all supported hash algorithms.
• Fixed handling of non-ascii characters in the filename for the DownloadTaggedData API.
• Fixed incorrect fees shown in the client for some phased transaction types. Fixed missing approval button for phased transactions.
• Load html page and modal before javascript for plugins.
• Updated some translation files, added Turkish as experimental, status of Catalan and Romanian translations changed to stable.
• Updated jetty libraries to version 9.2.12. If unpacking on top of a previous installation, delete the old lib directory first.

Version 1.5.13

July 13th, 2015

• Fixed Token validation to check whether the public key matches the one announced in the blockchain for the same account.
• Added compact.sh/compact.bat scripts to compact the database, resulting in smaller size and possibly better performance. Those should only be run when the Nxt server is not running.

API improvements:

• getAllPrunableMessages, getAssetTransfers, getBlocks, getCurrencyTransfers, getPolls, getPrunableMessages now allow filtering by block timestamp.
• Many APIs now support requireBlock and requireLastBlock optional parameters. If either of those is specified, it is guaranteed that the specified block is present in the blockchain, or the specified last block is the current last block, and the blockchain state does not change, while the API request is being executed. An error is returned otherwise.
• Added getExpectedAskOrders, getExpectedBidOrders, getExpectedAssetTransfers, getExpectedBuyOffers, getExpectedSellOffers, getExpectedCurrencyTransfers, getExpectedExchangeRequests, getExpectedOrderCancellations. Those return the corresponding orders, transfers, or offers, that are expected to be executed in the next blocks, based on the current content of the unconfirmed transactions pool, and the phased transactions planned to finish in the next block, in the order in which they are expected to be executed. It is not guaranteed that the next block will indeed contain exactly those transactions and in the same order, as this is up to the block forger. It is also not possible to know in advance if the phased transactions expected to finish in the next block will be approved or rejected.
• getAccountExchangeRequests now excludes the phased exchange requests that have not yet finished, or have not been approved, and the timestamp field now contains the block timestamp of the block in which the exchange request was executed, rather than the transaction timestamp.
• getPollVotes and getPollVote now accept includeWeights parameter, default false, to calculate and display the weight assigned to each vote in the poll results.
• Added Hash API, for calculating the hash of a secret using any of the supported hash functions, which can be used for deriving the hash in by-hash phasing. See getConstants for the list of supported hash functions.
• For running over tor, or other socks proxy, the socksProxyHost and socksProxyPort parameters can now be specified in the nxt.properties file instead of having to include them in the command line.
• Performance improvements, allowing table trimming to be done in parallel with blockchain download.
• Added UPnP support, enabled by default for the peer port and disabled for the API port, using the nxt.enablePeerUPnP and nxt.enableAPIUPnP properties.
• Added a warning on startup if nxt.myAddress is set but does not resolve to any of the external addresses found, including those discovered using UPnP.

Client UI:

• More links to the wiki tutorials in the help menu.
• System tray status dialog now refreshes every second when visible.
• The asset exchange page now displays unconfirmed orders as well as phased orders that are expected to be executed in the next block.
• The monetary system page now displays unconfirmed exchange requests and offers as well as phased requests and offers that are expected to be executed in the next block.
• Phasing modals "None", "By Transaction" and "By Hash" were implemented as part of the advanced section of transaction modals.
• Calculate hash modal is now available in the settings menu. Use it to calculate hash values for "By Hash" phasing model.
• Added "Admin Password" field to the client settings. Set it to the server admin password to allow the client to automatically determine its forging status when connected to a remote node.
• Peer modal dialogs now use the admin password specified in the client settings as default value.
• Forging indicator is displayed in Gray instead of Red when the forging status cannot be determined by the client when connecting to a remote node without specifying a correct admin password.
• Forging indicator tooltip, now displays further information about the forging status.
• Transaction info dialog correctly follows links between matching bid and ask orders and links from vote to poll.
• Marketplace usage warning and a corresponding, marketplace enablement setting has been implemented.

• This release will perform a rescan on first start.

Version 1.5.12

June 14th, 2015

• Significantly reduced the number of threads used when WebSockets are enabled. This should prevent the out of memory issues on some systems caused by excessive number of native threads created.
• Fixed important bugs in fork resolution during blockchain download.
• Improved blockchain download speeds, reduce load on hallmarked nodes and avoid slow peers during download.
• Send event notifications when using the eventRegister and eventWait APIs only after the database transaction has been committed, to make sure the changes that triggered the event are visible at the time the event is emitted.
• Added generateFileToken and decodeFileToken APIs, allowing creating and verifying tokens for files.
• Fixed file upload when using the test page.
• The maximum file size accepted for upload can be restricted using the new nxt.maxUploadFileSize property, default and minimum accepted value is 42 kB.

Client UI:

• Fixed missing scrollbars in modals invoked from other modals.
• Updated some translations. Added Romanian translation (experimental).
• Updated bootstrap to version 3.3.4.

Version 1.5.11

June 8th, 2015

• This release removes compatibility with peers older than version 1.5, and no longer accepts connections from them.
• Conditional logic dependent on block 445000 has been removed where no longer necessary, as block 445000 has been passed now.
• Parallel blockchain download using 36-block segments is now the default regardless of height. Returning more than 36 blocks at a time by getNextBlocks is no longer supported.
• The maximum WebSockets message size and the maximum allowed response size to a getNextBlocks request have been reduced from 192 MB to 10 MB.
• A checksum at block 445000 has been added.
• Added isDownload field to the getBlockchainStatus and getState API response, indicating if blockchain download is in progress. This gets set to true when a batch of more than 10 blocks at once has been downloaded from a peer, and gets reset to false when an attempt to download more blocks from a peer does not result in any new blocks added.
• The peer requests getUnconfirmedTransactions, getMilestoneBlockIds, getNextBlockIds, getNextBlocks, processBlock, processTransactions, getCumulativeDifficulty, are being rejected while a blockchain download is in progress, as indicated by the above isDownloading property.
• The timestamp of the last connect attempt to a peer is now included in the peer JSON object.
• Added a connect parameter to DumpPeers debug API, to force a connection attempt to each known peer first, adminPassword required if needed.
• The run.bat script on Windows no longer uses the -server flag by default.
• Updating nodes of version older than 1.5 to this release will delete blocks after height 445000, to make sure such nodes are not left permanently stranded on the 1.4 fork.

Version 1.5.10

June 4th, 2015

• Create installer package for Windows and Linux using the IzPack installer. See https://bitbucket.org/JeanLucPicard/nxt/issue/283
• Added separate linux and windows (cygwin) build and release scripts.
• Track and log database query execution times. The new properties: nxt.statementLogThreshold, nxt.transactionLogThreshold, and nxt.transactionLogInterval can be used to configure logging of slow queries.
• Database performance improvements and optimizations. The account leasing data has been moved from the account table to a separate account_lease table. More table indexes have been added or existing ones modified.
• Improved JSON encoding performance.
• Outbound websockets connections are no longer initiated when using a socks or http proxy (if system property socksProxyHost or http.proxyHost is defined).
• Include expired prunable JSON in API transaction JSON, if available.
• To protect public nodes from unneeded extra load, the getState API does not include counts even if includeCounts=true, unless the adminPassword is either provided as a parameter, or is not needed.
• Added numberOfAccountLeases and numberOfActiveAccountLeases to getState, showing the total number of scheduled (first lease only) or currently active account balance leases.
• Limit peer details length to 10 characters for version, 20 for application, 30 for platform, and 100 for announced address.
• Client UI improvements:
  • Fixed a bug sometimes not showing notification badge after login.
  • Improved Bulgarian and Slovak translations.
  • Fix local signing of upload tagged data and approve transaction.
• This release will perform a full blockchain rescan on first start.
• Updated jetty to version 9.2.11. If unpacking on top of existing installation, delete the old lib folder first.

Version 1.5.9

May 27th, 2015

• Enable Voting System, Phasing, and related new features at block 445000.
• This is a hard fork, upgrade to 1.5.9 or later is mandatory for everyone.
• If upgrading from 1.4.x, read the 1.5.0e and later changelogs for the important changes and new features introduced in the 1.5 series.
• Peer networking improvements. Peers unreachable for more than 7 days and not listed under nxt.wellKnownPeers or nxt.defaultPeers are removed from the peers database.
• Updated some translation files, added Bulgarian and Catalan translations.
• Other minor bugfixes and improvements.

Important licensing change:

• The Nxt core software is now distributed under the GNU General Public License version 2, with the exception of the client UI code which remains under the MIT license. Please read the files LICENSE.txt, COPYING.txt and DEVELOPER-AGREEMENT.txt for more information.

Version 1.5.8e

May 15th, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Set the content type to "text/plain; charset=UTF-8" when sending http requests to peers. This is an important bug fix, as the incorrect encoding of outgoing blocks and transactions containing some Unicode characters can prevent their propagation and lead to forks. Everyone running the experimental release should update.

Version 1.5.7e

May 15th, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Added WebSockets support in the peer to peer networking. When connecting to peers that do not support WebSockets, HTTP is still used. WebSockets can be disabled by setting nxt.useWebSockets to false (default is enabled).
• Implemented parallel blockchain download. After Constants.PHASING_BLOCK (not yet set on main net), blocks and transactions data will be requested from multiple peers in parallel, in batches of 36 blocks (when more than 36 blocks need to be downloaded), instead of downloading up to 720 blocks from the single blockchain feeder peer. This is expected to reduce the time for full blockchain download, once most nodes upgrade to support the parallel download protocol.
• Added file upload using multipart form requests to the UploadTaggedData, ExtendTaggedData and VerifyTaggedData APIs. Added upload file button to the corresponding forms on the /test page.
• Added DownloadTaggedData API, to download tagged data as a file.
• Added optional includeData boolean parameter to all GetTaggedData APIs, default true, to allow omitting the actual data from the result for saving bandwith, since it can now be retrieved separately using the DownloadTaggedData API.
• Improved search by tags. Improved validation of tagged data.
• Added includeEffectiveBalance to getAccount and getBalance API, default true. If false, effective balance and guaranteed balance are not included in the response, which should improve performance for these APIs.
• Added HexConvert utility API.
• Improved GetConstants JSON to include an alternative transaction type JSON representation.
• Peers in the nxt.wellKnownPeers list are always kept connected, regardless of the number of connected public peers or the total number of know peers.
• Added GetInboundPeers API, to return all peers that have sent a request to this peer in the last 30 min.
• Added inbound, inboundWebSocket, and outboundWebSocket boolean fields to the Peer JSON returned by the getPeer and getPeers APIs, to show the inbound status of each peer and whether it has established an inbound or outbound websocket connections to this node.
• Limit the total number of inbound or outbound connections, using the properties nxt.maxNumberOfInboundConnections and nxt.maxNumberOfOutboundConnections, defaults 250 and 50 respectively. The nxt.maxNumberOfConnectedPublicPeers value cannot exceed the nxt.maxNumberOfOutboundConnections value (if it does, it is set to nxt.maxNumberOfOutboundConnections).
• The getAccountTransactions and getAccountTransactionIds APIs have been restricted to always return only the non-phased transactions. Those APIs have also been deprecated and will be removed in 1.6. The getBlockchainTransactions API should be used instead, which has the same behavior but returns both phased and non-phased transactions (by default, unless either phasedOnly or nonPhasedOnly parameters is specified). Do not simply replace getAccountTransactions with getBlockchainTransactions in your client code without an understanding of how phased transactions work and without being prepared to handle them correctly.
• Added links to the Wiki documentation for each API request from the /test page. The links are autogenerated and thus work only for the wiki sections following the same hash tag pattern, but most of them currently do.
• The JavaScript NRS.sendRequest() function no longer accepts a callback function as its second parameter. Instead, when sending a request with no data, specify the value {} as the second parameter and the callback function as the third parameter.

Client UI improvements:

• Implemented client side signing of the tagged data transactions.
• Added File Upload form, accessible from the settings menu. Allow extending a tagged data transaction from the transaction info modal.
• Integration of current status of client translations for new 1.5 features, new "experimental" state for languages with translation status at 40-50%+, added Czech, Greek, Hindi translations in experimental state, updated translation state for other languages (Beta: 70-80%+, Stable: 90-95%+).

Version 1.5.6e

April 28rd, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Peer networking improvements.
• Announced addresses are always verified to resolve back to the peer address and not accepted if they don't. Old peer instances and old announced addresses are removed when a peer with dynamic IP changes address.
• If nxt.maxNumberOfKnownPeers (default 2000) is exceeded, the peers pool size is reduced back to nxt.minNumberOfKnownPeers (default 1000), keeping the highest hallmarked peers first.
• Peers are only identified by IP address now, not by address and port. Multiple nodes sharing the same IP address will be treated as one peer, with announced address and port as of the most recent GetInfo request or response sent out of or received from this address.
• Incompatible change: If using non-default port, the hallmark must also include that port, otherwise the hallmark is ignored.
• Optimizations in unconfirmed transaction propagation. When forwarding newly received unconfirmed transactions to peers, if their count exceeds 10, the broadcast is done in multiple batches of 10. When requesting unconfirmed transactions from a peer, the ids of the transactions currently in the pool are included in the request, so that the remote node does not need to include them in the response. The response size is also limited to 100 transactions, unless the requesting node does not provide such exclude parameter.
• Each tagged data can now also have a channel field. The searchTaggedData API can filter the search results by channel, and a new getChannelTaggedData API has been added to retrieve tagged data by channel, optionally filtered by account too.
• Fixed the UI for AddPeer and BlacklistPeer to accept admin password if needed.
• "Approve Transaction" action is now available in the transaction info actions tab.
• "Reveal Secret" field is added to the "Approve Transaction" modal when voting model is "By Hash".
• Enhanced the /test page to accept and pre-fill the test forms with any parameter values supplied in the url, e.g.: http://localhost:7876/test?requestType=getBlocks&lastIndex=10&includeTransactions=true
• This release will perform a full rescan on test net.

Version 1.5.5e

April 23rd, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Fixed processing of unconfirmed ExtendTaggedData transactions.
• AddPeer and BlacklistPeer APIs now require POST and admin password.
• This release will perform a full rescan on testnet.

Version 1.5.4e

April 22nd, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Fixed a bug in parsing ExtendTaggedData transaction json which prevents such transactions from propagating between peers.
• Added permanent message option to most send transaction dialogs.
• Other minor bugfixes.

Version 1.5.3e

April 19th, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• This update adds the Prunable Tagged Data feature, planned to be enabled at the voting system block too.
• Prunable tagged data are similar to prunable plain messages with no recipient, but with additional searchable metadata fields added. This feature can be used for decentralized and trustless distribution of small (up to 42k, including the metadata) pieces of data, which are by default stored for two weeks only (24h on testnet), but can optionally be stored longer or indefinitely by some nodes, and can be verified against the blockchain even after their expiration.
• Currently each tagged data can have the following fields, in addition to the data itself: name (required), description, tags, type, isText, filename.
• Name, description and tags are indexed and searchable using Lucene. All data and metadata is prunable, after pruning only a single 32 byte hash remains.
• Fee for either uploading or extending tagged data is based on the total data size (including metadata), and is 1 NXT for up to 1k bytes, 0.1 NXT for each 1k above, up to the limit of 42k.

New APIs:

• UploadTaggedData - create and broadcast new tagged data.
• ExtendTaggedData - extend the expiration time of already uploaded tagged data. If the data is still available, only the transaction id is needed. If not, already pruned data can be resurrected by including (in addition to the original transaction id) all of its fields too, i.e. name, description, etc. Anyone can submit an extension, not only the original uploader. Each extend transaction increases the expiration deadline by two weeks (24 h on testnet). Extending an existing tagged data from another account does not change the original submitter account id by which it is indexed and searchable.
• VerifyTaggedData - used to verify expired tagged data downloaded from another node, against the hash in the current blockchain.
• SearchTaggedData - full text search on name, tags, and description, optionally filtered by submitter account.
• GetTaggedData - retrieve tagged data by transaction id.
• GetAccountTaggedData - retrieve all tagged data submitted by a given account.
• GetAllTaggedData - retrieve all existing tagged data.
• GetDataTags - returns the distinct tags of all tagged data, with the number of data having each tag.
• GetDataTagsLike - prefix search of data tags.
• GetDataTagCount - the total number of distinct tags.
• All the Get* and Search* APIs above can only retrieve tagged data that has not been pruned yet.
• There is no client UI support for any of these APIs. It is expected that specialized third party plugins will be developed for specific tagged data use cases, depending on file type and target user group.
• Currently the pruning of tagged data is controlled by the same configuration properties that are used for prunable messages expiration.
• Same as with prunable messages, when using broadcastTransaction API to submit an already signed tagged data upload transaction, the prunable parts must be in the prunableAttachmentJSON parameter in case transactionBytes parameter is used. If submitting transactionJSON, it already has the prunable parts.

New debug APIs:

• GetAllBroadcastedTransactions - if transaction rebroadcasting is enabled, returns the unconfirmed transactions that have been broadcasted from this node but have not yet been received back from a peer.
• GetAllWaitingTransactions - returns the unconfirmed transactions that are currently temporarily kept in memory during transaction processing.
• RebroadcastUnconfirmedTransactions - if transaction rebroadcasting is enabled, causes transactions currently in the unconfirmed pool to be broadcasted to peers again, until received back.

Other changes and bugfixes:

• Improved handling of invalid transactions during block generation. Fixed validation of AE order cancellation transactions. Fixed a memory leak in processing of unconfirmed transactions. Set the default limit on waiting unconfirmed transactions nxt.maxUnconfirmedTransactions to 1000.
• The DGS goods delivery data size will be limited to 1000 bytes after VS block.
• Bugfixes in prunable messages processing.
• Fixed phasing with whitelisted approval accounts.
• On testnet, this release will perform a full rescan on first start with rollback to height 263895.

Version 1.5.2e

April 15th, 2015

• This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
• Added getAllPrunableMessages API, returning all currently available prunable messages in reverse block timestamp order.
• Added verifyPrunableMessage API, which can be used to verify that a prunable message obtained from another node (a service provider) matches the hash found in the blockchain, i.e. has not been tampered with.
• Show maxPrunableLifetime setting in getState and getBlockchainStatus. Show current number of prunable messages in getState.
• Changing the nxt.maxPrunableLifetime property now also affects existing prunable messages (next time pruning is run), as transaction timestamps instead of expiration timestamps are now used.
• Reverted DGS goods delivery maximum size to 10 kbytes, same as in 1.4. For goods of a larger size, a prunable encrypted message should be included in the delivery instead.
• Removed core restriction on 28 byte minimum prunable message length, this will be checked by the client UI only.
• Added nxt.includeExpiredPrunables property, to be able to force to still include the prunable parts in the returned transaction JSON, even if expired, as long as they are still available. Can be used to force an archival node to always return those, thus allowing another archival node that feeds from it to also get all of them.
• Limit the number of unconfirmed transactions that can be brought in memory to nxt.maxUnconfirmedTransactions, no limit by default. If set, transactions with lowest fee/size ratio are dropped from the unconfirmed pool first. The ordering is same as the one used when selecting which transactions to include in a new block.
• Added requeueUnconfirmedTransactions debug API.
• Added support for uncompressed non-prunable encrypted messages and encrypted to self messages, as a new appendix version, to avoid the need to specify the compression status as a request parameter when reading them.
• Added setLogging API, to allow changing log levels without having to restart the server.
• Added eventRegister and eventWait APIs, to be used for registering listeners and waiting for server events instead of polling.
• Changed the parameters accepted by broadcastTransaction. The prunable parts must be submitted either in the transactionJSON, or, if using transactionBytes, in a new prunableAttachmentJSON parameter, which has the same format as the transaction attachment json. The prunableAttachmentJSON is also returned by the signTransaction and getTransactionBytes APIs now.
• Added support for prunable plain and encrypted messages in the client UI.
• Added optional buyer parameter to getDGSGoodsPurchases API.
• Voting system UI improvements and bugfixes.

Version 1.5.1e

April 11th, 2015

• This is an experimental release which adds the Prunable Messages feature. It will be enabled at the same block as the Voting and Phasing features.
• This is a required update for all testnet nodes, but is also possible to run on main net.

New features:

• Prunable plain and encrypted messages.
• Plain and encrypted messages can now be created as prunable. For a prunable message, the message data itself is never a part of the transaction bytes. Instead, only a 32 byte sha256 hash of it is included in the bytes that are being signed, used to verify the signature, or to generate the full transaction hash or id. This makes it possible to completely remove the message data at a later time, keeping only that 32 byte hash, and still be able to verify the transaction signature and have the transaction hash and id unaffected by the pruning.
• Prunable messages have a predefined lifetime, after which their prunable parts are deleted from the blockchain. This lifetime is measured starting from the transaction timestamp of the message. When a node receives a transaction or a block from a peer, it is only required that the prunable parts of any prunable message are also included if their expiration time has not yet been reached. If it has, and a valid message hash is included instead, the block or transaction will still be accepted.
• Currently the minimum lifetime of all prunable data is set to 24 h for testnet, to allow easier testing of this feature. For main net, it is tentatively set to two weeks, but this is subject to change before the stable release. Note that pruning is performed at the same time as derived table trimming, which by default is every 1000 blocks, so the actual removal of the prunable data from the database will happen with some delay after their expiration time.
• A node can choose to keep prunable messages longer, by setting the nxt.maxPrunableLifetime property to a larger value. It cannot be set to prune them earlier. Changing this value only affect transactions received after the change. Pruning can be disabled completely by setting this property to -1.
• Prunable messages that have not yet been expired, but are past the minimum lifetime, are only retrievable using the getPrunableMessage(s) APIs, but are not included as part of their transaction JSON.
• If a transaction containing prunable attachments is phased, the prunable parts are nevertheless saved and available immediately, not at finish height. If their expiration deadline comes before the phasing finish height, they will be pruned and not available at finish height.
• Fees for prunable message attachments are set at 0.1 NXT per 1024 bytes, with the first 1024 bytes free (the regular transaction fee depending on its type still applies). This is again subject to change before the stable release.
• The full size of prunable message attachments is limited to 42 kbytes. Note that the full size is still included for the purpose of calculating the total block payload, even though only the 32 byte hash is in the transaction bytes.
• The size of regular plain and encrypted messages in this release has been restricted back to 1000 bytes, and will likely be reduced even further, before the stable release. This will be done in order to encourage users to switch to prunable instead of regular messages. Fees for regular message attachments will also be increased substantially.
• Creating prunable plain messages of less than 28 bytes is not allowed, as at such small sizes it is more efficient to store the full message instead of a 32 byte hash of it. There is no lower limit on prunable encrypted messages.
• It is not possible for a transaction to have both prunable plain and prunable encrypted message at the same time. It is also not possible to have both prunable and regular message of the same type (plain or encrypted). It is however possible to have a regular plain message and an encrypted prunable message, or a prunable plain message and a regular encrypted message.
• Prunable encrypt-to-self messages are not currently supported as there seems to be no good use case for them.
• Prunable encrypted messages can optionally be compressed before the encryption (default is to compress). The compression status is stored and does not need to be specified when decrypting. Regular encrypted messages are still compressed by default, but this compression can now optionally be disabled. For backwards compatibility, since their current bytes format does not store the compression status, this needs to be specified again when decrypting, else an error or unreadable data will be returned.

New APIs:

• GetPrunableMessage - returns the prunable message for a given transaction id, optionally decrypting it if encrypted and if a secretPhrase is supplied.
• GetPrunableMessages - returns all prunable messages for a given account id, optionally limiting to only those with another account as recipient or sender, and decrypting them if a secretPhrase is supplied.
• Prunable messages that have already been pruned are not returned by the above APIs.
• The UI for those APIs will be implemented in a later release.
• TrimDerivedTables - a debug API to trigger a derived tables trim, and prunable tables pruning.

Changed APIs:

• All APIs that create a new transaction now also accept optional messageIsPrunable or encryptedMessageIsPrunable boolean parameters (default false). If true, the message or encrypted message attachment, if any, is created as a prunable message.
• To control whether compression is performed before the encryption or not, the new compressMessageToEncrypt and compressMessageToEncryptToSelf parameters can be used (default true).
• Prunable messages, if not yet pruned, are also returned as part of the transaction json by the getAccountTransactions API, using the same fields as the corresponding regular messages, but adding a messageIsPrunable or encryptedMessageIsPrunable boolean flag.
• ReadMessage now also handles prunable message attachments, if any. It takes an optional uncompressDecryptedMessage and uncompressDecryptedMessageToSelf (default true) parameters, only used for non-prunable messages (not needed for prunable ones).
• DecryptFrom accepts an optional uncompressDecryptedMessage parameter, and encryptTo accepts an optional compressMessageToEncrypt parameter, default true.

INCOMPATIBLE changes:

• BroadcastTransaction has been modified to optionally accept all parameters that are needed to create a prunable plain or encrypted message (client side encryption only). This is required because the data for such messages is never a part of the transaction bytes themselves, so trying to broadcast a transaction that has a prunable part by only submitting its bytes to broadcastTransaction WILL FAIL, unless the corresponding parameters necessary to add the prunable parts are also supplied. Note that they need to exactly match the original parameters with which the transaction bytes have been created and signed.
• For non-prunable messages, broadcastTransaction behaves as before, but users are encouraged to start switching to prunable messages in view of the planned size restrictions and fee increases.
• The EncryptedData java class no longer handles compression internally, this is left to the caller of the encrypt and decrypt methods to do.

Other changes:

• GetPolls now supports an optional includeFinished parameter (default false).
• Multiple bugfixes and improvements in the Voting System and Phasing UI.
• The limit on transaction deadline of 1440 minutes has been removed. It is now possible to create a transaction with a deadline of up to 32767 minutes. This has been done because many use cases of phasing require that the transaction bytes are prepared much earlier than the actual broadcasting of the transaction to the blockchain.
• This release will perform a database upgrade with a full rescan on first start. On testnet, it will cause a rollback to block 256935.

Version 1.5.0e

April 6th, 2015

• This is an experimental release for the Voting System and Phasing. It enables these features on testnet, and is a required update for all testnet nodes.
• It is also possible to run this version on main net, but the block at which the new features will be enabled has not been set yet.
• New features:
  • Voting System.
    • Voting System API calls:
      • CreatePoll, CastVote, GetPoll, GetPolls, GetPollResult, GetPollVote, GetPollVotes, SearchPolls.
    • Polls processing is optional. If nxt.processPolls=false (default is true), vote counting is not done and no poll results are stored. This can be used to reduce the load on lower performance nodes. It is still possible to get the results of a poll using getPollResult, as long as the required vote and balances data hasn't been trimmed yet.
    • Regardless of the nxt.processPolls setting, votes for polls that finished before the last trim height (1441 blocks by default) are deleted and only aggregate results, if processing is enabled, are kept.
    • Votes are weighted based on the voting model selected, which can be by account, by balance, by asset balance or by currency balance, and a minimum balance cutoff can also be specified. The voting model is defined when the poll is created, however a different voting model can be specified when calling the getPollResult API, to calculate on the fly an alternative vote counting, as long as vote data is still available.
    • Voting multiple times, changing, or deleting votes is not allowed.
    • The fee to create a poll is 10 NXT for a poll with up to 20 options, with 1 NXT additional fee for any additional option (max 100 options are possible).
  • Phasing.
    • Phasing API calls:
      • ApproveTransaction, GetAccountPhasedTransactions, GetAccountPhasedTransactionCount, GetAssetPhasedTransactions, GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls, GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.
    • A transaction of any type can be phased by adding a phased=true parameter and an appropriate set of phasing parameters. Phased transactions are accepted in the blockchain immediately (subject to all usual validations), but are executed only at finish height, if still valid and if the required quorum has been met.
    • If not approved, or not valid at finish height, they remain in the blockchain but are never executed, and any changes they caused to the sender unconfirmed balance are reversed, except that the fee is not refunded.
    • In addition to the voting models available in polls, phased transactions can use a whitelist of accounts (max 10) allowed to vote for the transaction.
    • It is possible to vote for (approve) up to 10 phased transactions with a single approval transaction. This transaction will be accepted in the blockchain only if all phased transactions it is voting for are already in it.
    • Voting multiple times is allowed but has no effect on vote counting, votes after the first vote from each account are ignored.
    • It is also possible to make any transaction phased without needing voting for approval. This can be used to create transactions with deferred execution.
    • Pay on reveal secret is supported as a voting model for phased transactions.
    • When this voting model is used, the phased transaction must include the hash of a secret chosen by the sender (up to 100 bytes long), and an approval transaction for it is only accepted if it includes the secret that results in this hash. It does not matter who the sender of the approval transaction is, unless a whitelist is also defined. Supported hash functions currently are sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them as parameters are available from the getConstants API.
    • Finally, it is possible to make a phased transaction that is released or rejected not on the basis of voting, but based on the presence of other transactions (linked transactions) in the blockchain at its finish height. To do that, up to 10 phasingLinkedFullHash transaction hashes can be defined when creating the phased transaction. Note that this does not create a dependency between the linked transactions themselves. This feature can be used to implement atomic execution of transactions of any type, provided the phased transaction is phasing safe. Transactions already in the blockchain before the acceptance of the phased transaction can also be linked, as long as they are not more than 60 days old, or themselves phased transactions.
    • The deferred execution with no approval needed, pay on reveal secret, and linked transactions features are currently accessible using the API only, the UI for them will be completed in a later release.
    • Similar to voting, the phasing data for phased transaction that finished before the last trim height is also deleted and only the aggregate approval results are kept.
    • The fee for making a transaction phased depends on the voting model selected. For by-account voting with no minimum balance, or no voting needed, it is 1 NXT in addition to the regular fee for that particular transaction type. For voting that depends on voter balances, the additional phasing fee is 20 NXT.
    • The fee for approving a phased transaction is 1 NXT for each phased transaction included in the vote.
  • Variable size messages, encrypted messages, digital goods deliveries. After VS block, messages and encrypted messages will be allowed to be up to 40 kbytes long instead of 1000 bytes, with 1 NXT fee for each 1024 bytes. Digital goods deliveries can also be up to 40 kbytes, with 1 NXT fee for each 1024 bytes after the first 10k. A single transaction is always limited not to exceed the maximum block payload length, currently 255 * 176 bytes.
  • Other new APIs:
    • GetOrderTrades - given an askOrder, bidOrder, or both, returns all trades that were executed as a result of this order.
    • GetDGSExpiredPurchases - returns the purchases for a given seller which have expired without being delivered.
    • GetDGSTagsLike - returns all Digital Goods Store tags starting with a given (at least 2 characters long) prefix.
    • GetAliasesLike - returns all Aliases starting with a given (at least 2 characters long) prefix.
    • SearchAccounts - full text search on account info (name and description).
    • GetPlugins - returns a list of all installed plugins.
    • DumpPeers - returns all active peers of a certain version.
    • Shutdown - shuts down the server. Takes an optional scan parameter, if true the derived tables are truncated and a full rescan with validation is scheduled on next start. The resulting nxt_db folder is smaller, and a node bootstrapped with this database is going to verify the blockchain and rebuild all derived tables on start. While this ensures validity of the blockchain and all tables, it cannot verify that this is the current consensus blockchain and not a fork, therefore providing such a database for download is still not trustless.
    • GetLog - returns the most recent log messages, kept in a memory buffer.
    • GetStackTraces - returns the stack traces of the currently running threads.
    • Shutdown, getLog and getStackTraces require the admin password.
  • Changed APIs:
    • CreateTransaction - to facilitate debugging and to allow preparing transaction bytes and json even for transactions that are currently invalid, if broadcast parameter is false, all relevant transaction fields (json, bytes, hash, etc) are still included in the result even in the case of invalid transaction. If broadcast=true, those fields are returned only in case of successful transaction broadcast, otherwise only the error messages are returned. This change affects all APIs that end up creating a new transaction.
    • GetConstants - in addition to adding the new transaction types and subtypes, and the voting models, the format of the resulting json has been changed.
    • Added optional timestamp parameter to getExchanges and getTrades.
    • Added optional account parameter and pagination support to getCurrencyFounders.
    • Always include errorCode and errorDescription in some API results that only had an error field in case of an error.
    • Limit number of records returned by all APIs that support pagination to nxt.maxAPIRecords at a time (default 100), unless the admin password is provided or is not needed.
    • AddPeer adds an isNewlyAdded boolean to the returned peer json, indicating whether the peer was not already known.
• Client changes:
  • Extended UI in the "advanced" transaction modal dialog for every transaction type for invoking the different variants of phased transactions (to be approved by a certain number of accounts or balance/asset/currency holders).
  • New main sidebar item for the Voting System, modal to create the various types of polls, pages to find active polls and follow polls over time, list with own polls and votes casted.
  • Generic notification system for incoming transactions showing the number of transaction types and total new transactions.
  • Unconfirmed transactions are only displayed in the "Dashboard" and "My Transactions" pages and no longer appear in other tables.
  • Transaction info dialog for AE Bid and Ask orders now displays a table containing the actual trades mathcing the specific order.
  • New account login feature for faster login just by Nxt account.
  • User specific client DB with new logout option to clear user data.
  • Streamlined sidebar/navigation structure.
  • Send Currency button added to the toolbar which invokes the transfer currency dialog
  • Environment information, client settings and various diagnostic information is logged to the browser's JavaScript console during startup and login.
  • Phasing tab was added to the transaction info dialog of phased transactions.
• Various bug fixes.
• Client Plugin System:
  • Functionality - The NRS client comes with a new plugin system, enabling third party developers to provide additional functionality for the client. Plugins can be activated/deactivated on startup, the status of installed plugins can be seen on a separate settings page. Plugins can hook into the new "Plugins" sidebar navigation item or provide their own navigation structure.
  • Security - Plugins are not sandboxed or restricted in any way and have full access to client functionality including the passphrase. It is essential to only install plugins from trusted sources and in doubt don't use plugins together with accounts storing larger amounts of NXT. There are prominent security warnings both on the login page and within the plugins folder.
  • Installation - A Plugin is provided as an archived file containing the necessary HTML/JS/CSS files and can be installed by extracting the file in the plugins/client directory.
  • Developer - For a plugin to be valid is has to follow a certain minimal file structure and be shipped with a manifest.json file with some meta information. Detailed information can be found in the DEVELOPERS.md file in the plugins/directory. There is also a "hello_world" example plugin to get an idea how things work.
• Other important changes:
  • Fixed transaction ordering in AE order matching to always be by transaction index instead of by id, to take effect after Voting System Block.
  • Enforce nxt.adminPassword if set, even if the APIServer is listening on localhost only.
  • Added nxt.ignorePeerAnnouncedAddress and nxt.cjdnsOnly properties, relevant only for cjdns users or multihomed nodes.
  • Default initial peers are now stored in nxt.defaultPeers and nxt.testnetDefaultPeers instead of being populated by NxtDbVersion on database creation.
  • Allow the API server to handle both http and https requests on different ports, if nxt.apiServerSSLPort is set to a port different from nxt.apiServerPort and nxt.apiSSL=true. If the SSL and non-SSL ports are configured to be the same, the nxt.apiSSL property determines whether SSL is used or not. On testnet, non-SSL port is hardcoded to 6876 and SSL, if enabled, to 6877.
  • Reduced the default nxt.maxRollback to 800. Also added a nxt.trimFrequency setting to control how often the trim is run, default 1000.
• This release requires Java 8 and will not run or compile with Java 7.
• run.bat has been updated to search for a Java 8 installation using the Windows registry.
• Updated Jetty to version 9.2.10 and Bouncy Castle to version 1.52. If unpacking on top of a previous installation, delete the old lib folder first.
• This release will perform a database upgrade with a full rescan on first start.

Version 1.4.18

May 15, 2015

• This is a bugfix release. Everyone is required to update.
• Set the content type to "text/plain; charset=UTF-8" when sending http requests to peers. This is an important bug fix, as the incorrect encoding of outgoing blocks and transactions containing some Unicode characters can prevent their propagation and lead to forks.

Version 1.4.17

April 19, 2015

• This is a critical bugfix release. Everyone is required to update.
• Fixed validation of asset exchange order cancellations.
• Fixed excessive memory usage in unconfirmed transaction processing.

Version 1.4.16

February 24, 2015

• Updated jetty to version 9.2.9 due to a critical security bug:

http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00074.html There are no code changes, only the jetty libraries have been updated. Delete the old lib folder before unpacking on top of a previous installation.

Version 1.4.15

February 13, 2015

• Possible fix for the invalid CurrencyMint counter exception.
• Made URLs in descriptions clickable and fixed potential XSS exploit problem.

Version 1.4.14

February 9, 2015

• Added debugging output for failing currency mint transactions.
• Reduced default numberOfForkConfirmations to 2.

Version 1.4.13

February 9, 2015

• Peer networking improvements, better logging, bugfixes.
• News page now loads correctly when the wallet uses https.
• Nxt forum message updates are displayed instead of new topics.
• Feed refresh is performed whenever the news page is refreshed.
• Minor UI bugfixes.

Version 1.4.12

February 4, 2015

• Improved fork resolution by allowing a better difficulty block pushed from a peer to replace the current last block.
• When forging, do not accept a peer block with hit time after the next hit time of a currently forging account (i.e. prevent front-running in forging).
• Removed the possibility of a forger to miss his turn. Even if late, the block will still be generated and submitted.
• Delay forging and submission of blocks by 20 s, configurable via the nxt.forgingDelay property, in order to be able to accumulate more transactions in the forged block. The arrival of a front-running block from a peer however cancels that delay and the next block is generated up to 3 s earlier instead, which can be controlled via the nxt.forgingSpeedup property.
• The above time shifts apply to the physical time of block generation and submission only. Block timestamps are always fixed by the forging algorithm within 1 s accuracy, and are not possible to modify.
• Better logging of peer networking errors. Log, but do not blacklist missing or malformed JSON responses.
• UI for adding and blacklisting peers. Blacklisting from the UI is possible only when admin password is not needed (disabled or running on localhost).
• Database optimization. Moved the public key of accounts, transaction senders, and block forgers to a separate table, resulting in 15% reduction of total database size. This change will be performed at first start and will take some time. A shutdown after the first start is recommended to compact the database.
• Forging API improvements: getForging and stopForging now allow access using admin password instead of account secret phrase. This respectively retrieves the status of, or stops the forging of, all currently forging accounts. As with other admin password protected APIs, password is not required when the API server is listening on the localhost interface only. The getState API now also returns a needsAdminPassword boolean, to indicate this.
• Enforce that the nxt-default.properties file used matches the version of the current release.
• Added currency distribution dialog invoked using a link from the currency transaction info dialog.

Version 1.4.11

January 27, 2015

• Fixed a bug in transaction validation that could break blockchain downloading.The default (and minimum allowed) value for nxt.maxRollback is now 1441.
• Restrict maximum HTTP request and response size in peer networking to prevent potential out of memory attacks.
• Ctrl-C can now stop the server without having to wait for initial rescan to complete.

Version 1.4.10

January 25, 2015

• Improved display of blockchain downloading status in the client UI.
• Added client translations, changed state from beta to stable for the following languages: Italian, Dutch, Ukrainian.
• Fixed a bug in transaction bytes parsing which could cause signature verification failed errors and break forging.
• When downloading the blockchain, require at most one fork confirmation when still below the last hardcoded checkpoint (currently MS block).
• New API calls for peer management: addPeer and blacklistPeer. AddPeer will add a peer address or IP, optionally with port number, to the list of known peers and will try to connect to it. BlacklistPeer (password protected) will blacklist a peer, for the default blacklisting period.
• These APIs, and a few others related to peer networking, have been grouped under a new Networking tab on the test page.
• Peer port handling has been improved to allow different peers to share the same IP address provided they use different ports.
• To prevent overloading a node with invalid peer addresses, the maximum total number of known peers is limited to nxt.maxNumberOfKnownPeers (default 2000).
• Once this number has been reached, new peer addresses are not added, and peers that have been last connected to more than a week ago are removed from the known peer list, provided the node has enough connected public peers, until the number of known peers is again reduced to below nxt.minNumberOfKnownPeers (default 1000).
• Improved database performance by storing currency supply and reserve per unit data in a separate table.
• This release will perform a rescan on first start.
• Updated jetty to version 9.2.7. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

Version 1.4.9

January 18, 2015

Server Logic:

• Password protect the Debug APIs. The nxt.enableDebugAPI property is no longer used. Instead, the debug APIs which allow direct manipulation of the blockchain database are always enabled, but are now protected with a password, which needs to be set in the nxt.adminPassword property. Password is not required when the API server is listening on the localhost interface only (the default). The password protection can be disabled by setting nxt.disableAdminPassword=true.
• Some refactoring to allow creation and signing of transactions using the Java API even in the complete absence of blockchain data, as needed for the MintWorker.
• Minor peer networking improvement, addPeers and processBlock requests are now executed in the background.
• Improvements in fork resolution. The peer networking getNextBlocks API no longer limits the number of blocks returned to 1 MB total payload size, but always returns 720 blocks, if available.

MintWorker:

• Added nxt.mint.stopOnError property, default false. Minting will now continue, by default, even after an error occurred when sending the mint transaction to the server.
• Minting transactions are now signed locally and sent to the server using the broadcastTransaction API. Thus the secretPhrase for the minting account is never sent to the server, and the server or the connection to it do not need to be trusted. The secretPhrase is also not logged to the log output anymore.

User Interface:

• Added second row of info boxes on Dashboard.
• Notifications for incoming messages.
• Reworked page navigation.
• Account leasing dialog now displays the number of blocks until lease expiration.
• Fixed named account links on the transaction info dialog.

Client Translation:

• Added language selection to welcome screen.
• Added translations for monetary system for different languages.
• Stable: English, Spanish, French, Lithuanian, Portuguese (Brazilian), Russian, Chinese (Simplified), Chinese (Traditional)
• Beta: German, Finnish, Galician, Croatian, Indonesian, Italian, Japanese, Dutch, Slovakian, Portuguese, Serbian (Cyrillic), Serbian (Latin), Ukrainian

Version 1.4.8

January 11, 2015

• Removed some validations and logic no longer needed after the Monetary System block.
• Added a checkpoint at block 330000.
• Various minor UI bugfixes.
• Fixed currency search. Fixed handling of very high minting difficulties.
• Fixed concurrency issues with Scrypt minting, can use multiple threads now.
• Allow use of https for submitting minting transactions, set nxt.mint.useHttps=true. Note that this will accept any SSL certificate as valid, therefore will not protect you against man-in-the-middle attacks when minting.
• Allow no more than one unconfirmed minting transaction per account and minted currency to be accepted in the unconfirmed pool.
• Improvements in translations handling, documented in DEVELOPERS-GUIDE.md.
• Better validation of hallmarks for peers with multiple addresses. Do not blacklist peers with invalid hallmarks but just treat them as not hallmarked.
• Blacklist peers with versions older than 1.4.
• As more than 720 blocks have passed since the MS block, nodes older than 1.4 are now on a fork that will not be resolved by itself. To fix that, upgrading such nodes from a version older than 1.4 to this release will cause deletion and full download of the blockchain.

Version 1.4.7.1

January 10, 2015

• Always enable Monetary System menu in the UI as we are after block 330000 now.
• There are no other changes from 1.4.7.

Version 1.4.7

January 6, 2015

• This is a mandatory update. Everyone should update to 1.4.7 or later before block 330000.
• The Message Pattern in AccountInfo feature, introduced in 1.4.0e, has been disabled, and will not be activated at block 330000. This is to prevent possible denial of service attacks by malicious regular expression patterns which can cause excessive CPU load with certain inputs. This feature will probably be introduced again in 1.5, but with a predefined set of allowed well behaved regex patterns.
• Multiple minor UI improvements and bugfixes.
• Enhanced nxt.allowedBotHosts property to also accepts a range of addresses using CIDR notation.
• This release will perform a rescan on first start, on testnet only.

Version 1.4.6

January 1st, 2015

• Set MS block to 330000 in the UI too, so that the MS features menu appears after that height.
• Enforce that currency exchange offer expiration height is after the current blockchain height.
• Refactoring of the UI html, splitting index.html into multiple files.
• Added offer and transfer links to currency exchange booth UI.
• This release will perform a rescan on testnet only, with a rollback to block 159305.

Version 1.4.5

December 28, 2014

• Enable Monetary System at block 330000. This is a hard fork, therefore everybody should upgrade to 1.4.5 or later before that.

• If upgrading from 1.3.x, read the 1.4.0e and later changelogs for the important changes and new features introduced in the 1.4 series.

Version 1.4.4e

December 25, 2014

• Improvements and bugfixes in the UI of Monetary System, dividend payments, and account leasing.

• Added contacts export/import feature.

• Restrict currency exchange offer sell and buy supply not to exceed total sell and buy limit.

• This release will force a rescan on testnet only, deleting blocks after 159306.

Version 1.4.3e

December 23, 2014

• Added availableOnly parameter to getBuyOffers and getSellOffers, to return only exchange offers with non-zero supply and limit, default false. This parameter is however ignored when both currency and account are specified in the above APIs.

• Added getExchangesByOffer API to get executed currency exchanges for an offer.

• Do not log currency exchanges of zero amount.

• Fixed setting of peer state. Improvements in connecting to peers.

• Added README.md, DEVELOPERS-GUIDE.md OPERATORS-GUIDE.md, and USERS-GUIDE.md files.

• Added search for currencies based on code, name, or description keywords.

• Fixed bugs in unconfirmed balance handling in currency exchange and currency deletion.

• This release will perform a rescan, on testnet only.

Version 1.4.2e

December 21, 2014

• Additional validations of Monetary System transactions, and bugfixes in existing validations.

• Allow setting a different file as default page for the API server, in nxt.apiWelcomeFile, default index.html.

• Bugfixes in processing decimal point conversions in the UI, affecting MS and AE transactions.

• Bugfixes in currency minting and in MintWorker. The mint dialog has been removed, you can mint using the mint worker utility or manually submit a currencyMint transaction from the test page.

• Fixed the UI issue of client not responding after submission of certain MS transactions.

• Fixed duplicate transactions on the dashboard UI issue.

• The link to the founders table has moved from the currencies table to the transaction info dialog. Other Monetary System UI improvements.

• Improved peer networking to run the sending of blocks and transactions to peers in a background thread.

• This release will force a rescan on testnet only, deleting blocks after 159306.

Version 1.4.1e

December 17, 2014

This is a bugfix release following 1.4.0e.

• Fixed Currency Exchange Booth not working.

• Fixed currency decimals issue.

• Fixed minor bugs in MS transaction validation.

• Show total alias count in aliases page.

• Alias deletion and dividend payment UI fixes.

Version 1.4.0e

December 17, 2014

This is the experimental release to test the new Monetary System major feature. It is enabled on testnet, and those running testnet nodes should upgrade to this release, even if they don't plan to use the MS features, otherwise will be left on a fork. This release is also possible to run on main net, but is not to be considered stable for production use there. The Monetary System block is not yet defined for main net.

New features:

• Monetary System. See https://bitbucket.org/JeanLucPicard/nxt/issue/205/monetary-system-documentation for a detailed description. See https://bitbucket.org/JeanLucPicard/nxt/issue/207/mint-worker-utility for a description of the MintWorker tool for currency minting.

• Dividend payment transaction. Asset issuers can make a dividend payment to all asset holders with a single transaction. Required parameters are the blockchain height at which asset holders shares will be counted (must be less than 1440 blocks in the past), and the amount to be paid per share.

• Delete alias transaction. The owner of an alias can now delete it completely, thus making the alias available for anyone to reserve again if desired.

• Message pattern in AccountInfo. An account owner can set a regular expression pattern in the AccountInfo for his account, using the setAccountInfo API. Once such a pattern has been set, incoming transactions to this account are only accepted if they contain a plain text message which matches this pattern. The syntax follows the java.util.regex.Pattern specification.

API changes:

• After MS block, adding a public key announcement when sending a transaction to an account without a public key will be optional.

• Added withMessage boolean parameter to getAccountTransactions and getAccountTransactionIds APIs, to return only transactions having a message attachment, either non-encrypted or decryptable by the account.

• Added optional includeLessors, includeAssets, and includeCurrencies boolean parameters to getAccount API. Set to false when retrieving those data is not needed, in order to improve the getAccount performance.

• After MS block, sending messages, selling aliases, and leasing balances, to the Genesis account, will be disallowed.

• The popOff debug API now allows pop off of more than max rollback number of blocks, triggering a full rescan in such case.

Internal changes:

• After the Monetary System block, the order in which transactions in a block are executed will be determined by the block forger, instead of by id, default being by arrival time at the forger's node.

• Improvements in blockchain download to prevent getting stuck on the wrong fork. Nodes will download blocks in batches of not more than 719 blocks at a time from a single peer, and after each such batch will verify with nxt.numberOfForkConfirmations other peers (default 5) if this is the best fork, before continuing, unless the downloaded batch is of less than 10 blocks.

• Rescan status is now saved in the database, to prevent the database from being left in an inconsistent state when a rescan fails or is interrupted. Once a rescan has been scheduled, it will be triggered again at restart, until it completes successfully.

• Improvements in the processing of unconfirmed transactions.

• This release will perform a rescan on first start.

Version 1.3.5

December 14, 2014

• Added getDGSTagCount API, allow getDGSGoodsCount and getDGSPurchaseCount to be used also to get total goods or purchase counts.

• Added completed parameter to getDGSGoodsPurchases, getDGSGoodsPurchaseCount, getDGSPurchaseCount, getDGSPurchases, to allow querying for completed purchases only. Added withPublicFeedbacksOnly parameter to getDGSPurchaseCount.

• Secondary sort of search results after sorting by relevance, by timestamp if for any seller, or by name and then by timestamp if for a single seller.

• Improved performance of Marketplace page, show counts for goods in stock only.

• Increased default purchase delivery deadline to 168 hours (1 week).

• Include full peer info in getPeers API if includePeerInfo=true, to avoid having to do a separate getPeer request for each peer.

• Include cumulativeDifficulty in the block JSON.

• Allow transaction signing in signTransaction to skip the validation of the transaction bytes being signed, if an optional validate=false parameter is added. This would be useful when signing transaction bytes on a machine that doesn't have the full blockchain downloaded, which normally prevents validation.

• Allow sending messages with no recipient.

• Automatically blacklist peers with version older than 1.2.0.

• UI improvements of the API /test page.

• Changed nxt-default.properties to enable MVCC by default, to avoid database lock timeout errors.

• Updated jetty to version 9.2.6. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

Version 1.3.4

November 20, 2014

• This release is focused on improving the Nxt Marketplace (Digital Goods Store) by adding search and browse capabilities.

• Implemented full text search using the Lucene library, as supported by H2. Table columns currently indexed are asset.name, asset.description, goods.name, goods.tags, goods.description. A rebuild of the search index can be forced using the luceneReindex debug API.

• The full text search query parameter supports the standard Lucene syntax, which makes AND, OR, phrase queries, or wildcard queries possible. The default query operator is OR, to do an AND search need to specify AND between keywords explicitly.

• Added searchAssets API which takes a query parameter and returns assets having name or description matching the query.

• Added searchDGSGoods API which takes a query parameter and returns goods having name, tags, or description matching the query. The results can also be restricted to a specific seller, goods in stock only, or goods with a specific tag only.

• getDGSPurchases API now takes an optional withPublicFeedbacksOnly parameter. If true, results are filtered to include only purchases with public feedbacks.

• Added getDGSGoodsPurchases API to retrieve purchases for a specific goods, optionally those with public feedbacks only.

• Added getDGSTags API returning all DGS Goods tags, sorted by number of goods in stock with that tag and total number of goods with that tag. Takes an optional inStockOnly parameter, default true, to retrieve tags for goods in stock only. At most three tags per goods are used, tags longer than 20 characters or shorter than 3 are ignored, and the parsing of tags is done using the Lucene StandardAnalyzer.

• Show purchase counts and public feedback counts in all API responses returning Goods JSON, unless includeCounts parameter is false.

• Include total numbers of Goods, Purchases, and Tags in the getState API.

• Added getAccountAssetCount, getAliasCount, getDGSGoodsCount, getDGSGoodsPurchaseCount, getDGSPurchaseCount APIs, to be able to retrieve the corresponding total counts directly.

• To populate the tags table in the database, a blockchain rescan will be done at first start.

• Updated jetty to version 9.2.5. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

• UI changes:
  • The Marketplace page now shows a listing of tag keywords, ordered by number of goods in stock with that tag.
  • Clicking on each tag brings the list of goods having that tag.
  • Searching for goods is now possible using keywords from the goods name, description, or tags.
  • The list of goods also display the number of completed purchases, and for goods with a public feedback available, a link to display that feedback.

Version 1.3.3

November 12, 2014

• Fixed incorrect guaranteed balance bug in getAccountLessors API.
• Added getAccountBlockCount API returning number of forged blocks for an account.
• Added includeCounts parameter to the getAssets API, to avoid getting trades,accounts, and transfers counts, if not needed.
• Cache hallmarked peer account balances to reduce number of database calls.
• Other minor performance improvements and bugfixes.
• Fixed decryption of purchased DGS goods. Fixed missing DGS purchase feedbacks. To repopulate the feedbacks table, this release will perform a blockchain rescan at first start.
• Added a hideDelisted parameter to the getDGSGoods API, default false. If true, delisted goods are not included in the results. This parameter has effect only if inStockOnly=false, as delisted goods are considered not to be in stock.

• UI bugfixes and improvements. Added themes settings and a corporate theme.

• Hide fee input when sending NXT in basic mode, and set to the minimum fee.
• Improved the http://localhost:7876/test page interface, allow custom API call selection, syntax highlighting of the response JSON.
• Added getAccountAssets API request, returning account asset balances for the specified account. If an asset parameter is also specified, only return balance for that asset. Unlike the getAccount API, this request can also take a height parameter, to return asset balance as of that height.
• Added getAssetAccountCount API request, returning number of accounts holding the specified asset, again with optional height parameter.
• Updated jetty to version 9.2.4. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

Version 1.3.2

October 30, 2014

• Allow re-broadcasting of transactions already in the unconfirmed pool.
• Added clearUnconfirmedTransactions debug API to force clearing of the unconfirmed transactions pool.
• Show correct timestamps in asset transfer history.
• Only try to set account public key when inside a database transaction, fixes a bug in setting public keys for accounts that never had an outgoing transaction.

• getAccountLessors API now returns the guaranteed balance of each lessor too, as of the height specified in the optional height parameter. The format of the returned json has been changed to allow adding this guaranteedBalanceNQT property.
• getPeers now accepts an optional "state" parameter, to return only peers in that state. Possible values: CONNECTED, NON_CONNECTED, DISCONNECTED. If present, the active=true parameter takes precedence.
• getBlock now accepts an optional "timestamp" parameter, to return the last block as of that timestamp. The parameters to getBlock: "block", "height", "timestamp", are processed in that order of precedence, i.e. if both height and timestamp are specified, height is used and timestamp is ignored. If no parameters, current last block is returned.
• getState now accepts an optional "includeCounts" parameter, default true. If set to false, database table counts, which are slow to retrieve, are not included in the response.
• getTrades, getAllTrades, and getAssetTransfers API now accept an optional "includeAssetInfo" parameter, default true. If set to false, asset name and decimals are not included in the result Trade json, and not having to retrieve those speeds up the request processing.
• Added getBlocks API, returning the blocks ordered by height descending, and using firstIndex, lastIndex parameters for pagination. Restricted to return up to 100 blocks at a time. If includeTransactions is true, also includes the full transaction JSON.

• Improved default H2 cache size allocation. If nxt.dbCacheKB is not set, the H2 cache will vary linearly from 16MB for JVM heap size 160MB, to 256MB for heap size 640MB or higher. This should allow low end devices to run without needing a custom setting for the nxt.dbCacheKB parameter, and prevent excessive memory use on machines with plenty of memory too.
• Disabled the SSLv3 protocol when using SSL for the API.

• Client UI improvements:
  • Added pagination to the Blocks page. The default number of rows per page can be changed in settings.
  • Show account balance in the sidebar on all pages.
  • Improvements and bugfixes in the asset trade and transfer history pages.
  • New design of the dashboard, and an improved recent transactions list.

Version 1.3.1

October 16, 2014

• This is a critical bugfix release, everyone using 1.3.0 should upgrade.
• Fixed a bug in transaction loading which was causing transaction id's and signatures for some transactions with invalid ecBlock values to change after saving and reloading from the database.
• Report requestProcessingTime in the JSON of all API responses.
• Delay loading of block transactions from the database until they are needed.

Version 1.2.9

October 16, 2014

• This is a critical bugfix release, everyone using 1.2.8 or earlier should upgrade.
• After installing 1.2.9, set nxt.forceValidate=true in nxt.properties and restart, to force a revalidation of blocks already in the database. Set this property back to false after the first run.
• Fixed a bug in transaction loading which was causing transaction id's and signatures for some transactions with invalid ecBlock values to change after saving and reloading from the database.

There are no other changes from 1.2.8.

Version 1.3.0

October 14, 2014

This is the first release which stores all derived objects in the database, instead of keeping all of them in memory only.

Derived objects are those that are constructed based on the information already available in the blockchain blocks and transactions - i.e, Accounts, Aliases, Assets, Goods, Purchases, Orders, Trades. Storing them in the database instead of in memory means the Asset Exchange and the Digital Goods Store can scale to much higher number of assets, orders, and goods, without requiring an ever growing amount of memory for each node.

Using a standard SQL database tables to store those records also allows for much more sophisticated queries, and allows third parties to write and execute custom queries against those tables directly, without being dependent on the NRS http API only.

By storing the state of all derived objects as of the current height, plus their state at previous heights up to 1440 blocks back, it is possible to completely eliminate the need for blockchain rescans on startup, and on fork resolution.

On upgrade from 1.2.8 and older releases, this version will perform an initial build of the derived objects tables, which on a fast machine takes about 4 min, but may take longer depending on your hardware. The database size will again grow during this rescan, but after shutdown should shrink back to around 550 MB.

There will be no rescans on subsequent restarts, and the startup time is now reduced to a few seconds only. There will also be no rescans at runtime on block pop offs.

Derived object tables are kept small by trimming them, only records needed to allow rollback of up to 1440 blocks back are kept. If you need to preserve and query historical information going back all the way to height 0, this trimming can be disabled by setting nxt.trimDerivedTables=false (default is true) in nxt.properties. After changing this property, a rebuild of the derived tables can be triggered using the new scan API request, see below.

The default number of rollback records kept can be increased while still keeping trimming enabled, by setting nxt.maxRollback to a higher value (default and lowest possible is 1440). This should provide a compromise for those who want to keep history of more than the default 1440 blocks, yet want to avoid the performance penalty of never trimming the derived objects tables.

To allow for the increased use of database, default max number of database connection has been increased to nxt.maxDbConnections=30, and lock timeout increased to nxt.dbDefaultLockTimeout=60 in nxt-default.properties.

Slower machines and high traffic public nodes may experience database lock timeouts with the default settings. To prevent those, MVCC mode can be enabled by appending MVCC=TRUE to the jdbc url in nxt.properties. MVCC is not enabled by default however, because while providing for higher concurrency under multiple simultaneous connections, and thus avoiding timeouts, it is also slower overall and less well tested.

To help with debugging potential bugs, default logging level has been set to nxt.level=FINE in logging-default.properties for this release, which will cause more output than usual in the log.

API changes:

• The following existing APIs now allow optional pagination using firstIndex, lastIndex parameters:
  • getAccountBlockIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds, getAliases, getAllAssets, getAllTrades, getAskOrderIds, getBidOrderIds, getAskOrders, getBidOrders, getAssetIds, getAssetsByIssuer.
• The limit parameter is no longer accepted by the getAskOrderIds, getBidOrderIds, getAskOrders and getBidOrders APIs, as firstIndex/lastIndex parameters are now used instead for pagination.
• getAccountBlockIds in addition to allowing pagination now returns the blocks in descending order, as this is more useful when showing the newest blocks on top in the client.
• getTrades now accepts an optional account parameter, in addition to asset, to allow retrieving trade history for a specific account, for either all assets or a specific asset only.
• getUnconfirmedTransactions and getUnconfirmedTransactionIds now also accept the RS account number format.
• The Trade JSON now includes buyer and seller account ids, the height at which the trade occurred, the asset name, and the heights at which the ask and bid orders were accepted in the blockchain.
• The Asset JSON now includes total number of transfers, and number of accounts holding the asset.
• parseTransaction does not just return an error when trying to parse an invalid transaction bytes or JSON, but adds a validate=false field, plus the actual error message, in addition to the parsed transaction JSON.
• getState no longer includes total effective balance.

New API requests:

• getAccountBlocks - like getAccountBlockIds, but returning full block JSON. If includeTransactions parameter is true, also includes the transaction JSON.
• getAccountCurrentAskOrders and getAccountCurrentBidOrders - like getAccountCurrentAskOrderIds and getAccountCurrentBidOrderIds, but returning full order JSON.
• getAllOpenAskOrders and getAllOpenBidOrders now replace getAllOpenOrders, but only returning ask or bid orders respectively, and allow firstIndex/lastIndex pagination.
• getAssetTransfers - retrieves the asset transfers for an asset, account, or both, sorted by height descending.
• getAssetAccounts - accepts an asset parameter and returns all accounts holding this asset as of the current height, and the asset quantity each one owns, sorted by asset quantity descending. Takes an optional height parameter to allow retrieving asset holders as of a previous blockchain height.
• getAccountLessors - retrieves the accounts that have leased their balance to the specified account, takes an optional height parameter to allow querying previous blockchain heights.

The historical height query feature in getAssetAccounts and getAccountLessors depends on the specified height records still being available, i.e. either table trimming disabled, or maxRollback set high enough to cover that height.

• longConvert - an utility API to convert between signed long ids as used in the database and unsigned long ids represented as strings. Accepts an id in either form and returns both the signed and unsigned versions.
• getECBlock - returns the ecBlockId and ecBlockHeight given an optional timestamp, current time if not supplied.

New debug API requests:

• The following requests are used for debugging purposes only and should not normally be needed. They are disabled by default, set nxt.enableDebugAPI=true in the properties to enable them. Do not enable on a public node where the API is accessible to anyone.
  • fullReset - delete and redownload the whole blockchain.
  • popOff - accepts a numBlocks or height parameters, and pops off that many blocks or back to that height. If table trimming is enabled (default), at most 1440 blocks can be popped off. Derived object tables are rolled back to the specified height and blocks and transactions after that height are deleted.
  • scan - accepts a numBlocks or height parameters, rolls back the derived object tables to that height and rebuilds them by rescanning the existing blockchain from that height up again. Does not delete blocks or transactions from the blockchain, unlike the popOff request. A request to rescan more than 1440 blocks when table trimming is enabled will do a full rescan starting from height 0. Setting validate parameter to true will also re-verify signatures and re-valudate blocks and transactions during the rescan.

DbShellServlet: A command line access to the H2 database at runtime is now possible at: http://localhost:7876/dbshell This page uses the H2 shell tool to allow querying the database at runtime, directly from the browser, without having to enable auto server mode in the jdbc url. This servlet is only enabled if nxt.enableDebugAPI=true, and is very unwise to enable on a publicly accessible node as it allows full read and write access to the database.

The usability of the http://localhost:7876/test API access page has been further improved.

Packaging changes: To prevent intentional misunderstanding of why jar files hashes are never reproducible, the class files are now left unpacked in a classes subdirectory after compilation, instead of being packaged in a nxt.jar file. The run.sh and run.bat scripts have been modified to include this directory on the classpath instead of the nxt.jar file. Those who still prefer to build a nxt.jar file, can easily do that with the included jar.sh script, and modify the classpath to use it. A pre-built nxt.jar file will still be included for a few releases, as it is expected by the restart code when upgrading from an older version, but is not otherwise used.

Other internal changes:

• Everywhere, object ids that used to be Longs are now primitive longs, as their use as HashMap keys is no longer needed.
• Preserve and re-process unconfirmed transactions after fork resolution pop-off.
• Improved propagation of unconfirmed transactions.
• Multiple minor improvements and optimizations based on profiling results.
• Merged in code to enable future variable fees based on transaction type and transaction size.
• Updated Jetty to version 9.2.3.
• Added an option to disable transaction re-broadcasting by setting the property nxt.enableTransactionRebroadcasting to false (default is enabled).

Testnet: This release will reset the testnet blockchain back to height 77431. Testnet nodes staying with 1.2.8 are already on a different fork.

There is no urgency to upgrade on main net, both 1.2.8 and 1.3.0 versions can coexist on the network and there is no hard fork involved. The local database changes however are not reversible, if you upgrade to 1.3.0 and decide to go back to 1.2.8, you will need to delete the nxt_db folder and re-download the blockchain.

Version 1.2.8

September 3, 2014

API changes:

• The timestamp parameter in getAccountTransactionIds and getAccountTransactions now refers to the timestamp of the block in which the transaction was included rather than the transaction timestamp itself. Transactions are sorted in descending order of block timestamp and transaction id, instead of transaction timestamp. This is so that the sorting matches the order in which transactions are processed, and because transactions with earlier timestamps may appear in the blockchain after transactions with later timestamps have already been processed, thus being unintentionally skipped while navigating the transactions list by transaction timestamp.
• The getAccountTransactionIds and getAccountTransactions requests now accept an optional numberOfConfirmations parameter, which can be used to retrieve only transactions with at least numberOfConfirmations number of confirmations.
• The getBlock API now optionally accepts height instead of block parameter, to retrieve the block at that height. If both block and height are specified, height parameter is ignored.
• The getBlock API now also accepts includeTransactions parameter, if set to true, full transaction JSON is returned instead of only transaction ids.

There are no other changes between 1.2.7 and 1.2.8, so those who rely on the old behavior of the above APIs can continue to use 1.2.7 for the time being.

Client GUI:

• Added the option for merchants to specify a specially formatted message that is required to be added to a payment transaction or an asset transfer.
• To activate this behavior, you must set your account info description to the following format: #merchant:[0-9]+#
  • This example will only accept a numeric message.
• If the message should be of a particular length use this: #merchant:[a-zA-Z0-9]{4,8}#
  • This format will only allow messages that have a length of 4 to 8 characters and is alphanumeric.
• Note that the regex is case sensitive.
• Fixed issue with public key field not showing when using a contact in the recipient field.

Version 1.2.7

August 26, 2014

• No longer allow creation of pre-DGS block transactions, and ignore such transactions received from old version peers on a fork.
• Improvements in exception handling, transaction validation, error logging. Updated run.bat file. Blacklist unreachable peers on connection timeout. Prevent server from starting if any of the startup tasks failed.
• Added an optional "active" parameter to the getPeers API request. If true, only active peers are returned (those in state CONNECTED or DISCONNECTED).
• Avoid unnecessary DNS queries.
• No longer process or return "comment" parameters in Asset Transfer.

Version 1.2.6

August 17, 2014

• Preserve unconfirmed transactions during rescan instead of relying on being able to get them again from peers.
• Keep retrying the block generation in the case it fails due to an invalid transaction. Prevent block generation failures due to minimum transaction size changes.
• Ignore peer weights in choosing a random peer when hallmark protection is disabled (it is enabled by default). When hallmark protection is enabled, the nxt.maxNumberOfConnectedPublicPeers count is now based on hallmarked peers only, i.e. the node will keep trying to connect to more peers until it is connected to at least that many hallmarked peers.
• Added peer networking addPeers request. After sending a getPeers request and processing the response, the peer will also send to the other peer all peer addresses it is connected to which are not present in the other peer's peers set, to improve the propagation of peer addresses through the network.
• Minor bugfixes.

Version 1.2.5

August 13, 2014

• Added peer networking gzip compression. It is enabled by default, and will make downloading of the blockchain faster, but in case it causes extra load on your public node can be disabled by setting nxt.enablePeerServerGZIPFilter=false in nxt.properties.
• Enabled serving gzip compressed static resources (html, javascript, css files)by the API Server. This would make loading the wallet UI from remote servers faster. The compressed .gz files are included in the installation package.
• Allow gzip compression of API Server responses too, however this is disabled by default. This would be helpful when running the server on a remote machine, for online wallets and service providers, to enable it set nxt.enableAPIServerGZIPFilter = true in nxt.properties.
• Fixed client-side rescanning bug that caused UI to appear outdated.

Version 1.2.4

August 11, 2014

• Fixed important bugs affecting arbitrary message and asset transfer transactions before DGS block.
• Minor client UI bugfixes.
• Updated jquery to version 2.1.1 and bootstrap to version 3.2.0.

Version 1.2.3

• Everyone should upgrade to 1.2.3 before block 213000.
• Those upgrading from the previous stable release, 1.1.6 or earlier, should also consult the changelogs for 1.2.0e, 1.2.1e and 1.2.2e for important changes introduced in the 1.2 branch.
• Minor bugfixes.
• ParseTransaction, signTransaction, and broadcastTransaction API can now accept transaction in JSON format instead of transaction bytes.
• Moved DGS block forward, will be enabled at 213000 instead of 210000.

Version 1.2.2e

This is a development release for testing only. Source code is not provided. Change log:

• This is still a test release intended to get testnet working. Please update your testnet nodes.
• Bugfixes in transaction attachment versioning and version validation.
• Added encrypt-to-self message attachment type. Any transaction can optionally have such an attachment, intended to be used for private notes that only the transaction sender can read. This feature is not yet supported by the GUI.
• Added nxt.isOffline property. If set to true in nxt.properties, peer networking will not start, no peers will be loaded from the database, and no outgoing connections will be made.

Version 1.2.1e

This release is still considered experimental, but is now enabled to run on main net too. The DGS milestone block is set to 210000 for main net. A stable release is expected before that, but all exchanges and websites should already start trying the 1.2.1e release, because the upgrade to 1.2.2 stable will be mandatory before block 210000.

• Multiple bugfixes in DGS and Alias Transfer transaction validation. Restricted some types of alias and DGS transactions to one per alias / DGS purchase per block.
• Alias sale transactions now use null recipient instead of genesis when the sale is open to any buyer. Alias buy transaction uses amountNQT instead of priceNQT parameter, as the price is being stored in the amount field anyway.
• GetDGSGoods request now always skips delisted goods.
• Improved handling of IPv6 addresses.
• Improved the http://localhost:7876/test interface by adding support for tagging of API requests in multiple categories. All http API requests are now classified under separate tabs for easier navigation.
• Reduced startup time by running in parallel the initial peer loading and address resolution, and the initial blockchain scanning.
• To improve database performance, transactions that do not have a recipient now have null instead of the genesis account id as recipient in the transactions table. Such transactions will also not have a recipient field in their JSON.
• Added support for pagination to the getAccountTransactionIds API. The results are now returned sorted by timestamp in descending order.
• Added getAccountTransactions API also returning the full transactions json.
• Refresh peer info for already connected peers every hour.
• Call setReuseAddress(true) for all jetty ServerConnectors.
• Refactoring of transaction attachment handling. Added support for transaction versions and global options. Transactions will switch to version 1 at DGS block.
• Added Message and EncryptedMessage attachments that can be attached to any transaction types, and can have either text or binary content. All APIs that create a new transaction now accept additional parameters to allow attaching a Message or EncryptedMessage (or both). This removes the need for creating new transaction types for encrypted messages or payments with messages.
• After DGS milestone block, Asset Transfer transactions can no longer have a "comment" field. Switch to using a plain text "message" attachment instead.
• Added transaction attachment versioning. Transactions of version 1 and later will have a version field in the attachment too, which allows future optional changes to one attachment type only, e.g. adding expiration field to asset issue attachment without having to add a new transaction type.
• Added PublicKeyAnnouncement attachment. Those will be accepted after DGS block, but only enforced after block 215000. After that block, transactions with recipient account that does not have a public key will be required to have such an attachment in order to announce and set the public key of the reciepient. To add a PublicKeyAnnouncement, just add a "recipientPublicKey" parameter with the hex-encoded public key string when sending the first transaction to that account. It is harmless (but useless) to keep adding the same recipientPublicKey for further transactions to the same account. But trying to set a different public key for an account that already has a public key will result in rejectionof the transaction.
• The getAccountId request can be used to get the public key for a secret phrase (even when not yet announced to the blockchain).
• Added first part of Economic Clustering - fork detection. After DGS block, each transaction will include a reference to a recent blockId. For now this is used only to detect forks, and transactions refering to a different fork are still not rejected.
• Next step of Transparent Forging will be enabled at block 215000: accounts that miss their turn to forge will not be able to forge for the next one hour.
• Updated jetty to version 9.2.2 and bouncycastle to version 1.51.
• This release will cause a reset of testnet, deleting blocks and transactions after block 117907.
• Client Updates:
  • Redesign login page.
  • Multilingual interface. Some translations are incomplete and still considered experimental.
  • Most forms now allow you to add an encrypted or public message to them.
  • Added public key announcement support.
  • Passphrase login length check.
  • Automatically enable certain features at DGS block.
  • Several DGS bug fixes.

Version 1.2.0e

June 29, 2014

• This release will run only on testnet. Set nxt.isTestnet=true in nxt.properties.
• New features:
  • Digital goods store.
    • New http API calls for creating transactions: dgsListing, dgsDelisting, dgsPriceChange, dgsQuantityChange, dgsPurchase, dgsDelivery, dgsRefund, dgsFeedback
    • New http API calls for quering DGS: getDGSGood, getDGSGoods, getDGSPurchase, getDGSPurchases, getDGSPendingPurchases
    • Goods and notes exchanged between buyer and seller are encrypted with AES, and gzip compressed before encryption. Maximum allowed digital goods size is 10240 bytes after compression and encryption.
  • Alias transfer.
    • New http API calls: sellAlias, buyAlias
    • Alias sale can be restricted to a specific buyer, or open to anyone. Alias sale with price 0 is treated as immediate transfer and doesn't require a separate buy alias transaction. To change the ask price, submit a new sellAlias transaction. To cancel a sale, submit a new sellAlias transaction to yourself with price 0.
    • Buy alias transaction can only be placed if the alias is already for sale. It is not currently possible to just bid on an alias that is not for sale.
  • Encrypted messages.
    • AES encrypted messages are now supported in the core, so there is no need to use externally encrypted arbitrary messages anymore. Use arbitrary messages only for plain text, encrypted messages for confidential messaging.
    • New APIs: sendEncryptedNote and readEncryptedNote. Max message length is 1000 bytes, after compression and encryption.
    • New http API calls: encryptTo/decryptFrom can be used for encrypting and decrypting arbitrary text to/from an account. But those just do the encryption and decryption, don't actually send messages between accounts.
• New rsConvert http query for converting account number to RS format and back.
• New getBlockId API to get blockId for a given height.
• Improved logging, to handle the case when Nxt is embedded as a library.
• Minor improvements: getState and getBlockchainStatus now also show application name, block JSON also shows generatorPublickKey, getAccountId also accepts publicKey as a parameter.
• Updated jetty to version 9.2.1.
• Client Updates:
  • Digital Goods Store UI.
  • Alias Trading UI.
  • Encrypted Messages.
• Only RS account numbers are allowed. Exchanges and services should switch to RS format ASAP.
• Decode Token Functionality.
• Hide Fee / Deadline by default, show via advanced toggle.
• Show warning message if user is on a fork (if his account has generated at least the last 10 blocks).
• Several settings (remember passphrase by default, 12/24 hour format).

Version 1.1.6

June 27, 2014

• Fixed logic bugs in unconfirmed transactions handling and detection of double spending transactions.
• Improved performance of getTransactions query.
• Added nxt.debugLogUnconfirmed parameter (default false) to control debug logging of unconfirmed account balances.
• Improved UI of the API test servlet, patch submitted by Holger Drewes.

Version 1.1.5

June 20, 2014

• Fixed a special case in the calculation of unconfirmed balance. Added additional checks for account balances.

Version 1.1.4

• Aliases http API cleanup. There are only two API requests to get aliases now:

getAlias
parameters: either "aliasName" (the alias name) or "alias" (the alias id)
returns: full Alias JSON

getAliases
parameters: "timestamp" (optional timestamp) and "account" (the account id, required)
returns: list of aliases (full JSON) owned by the account, optionally filtered by timestamp

• The old getAliasId, getAliasIds, getAliasURI and listAccountAliases have been removed as they are redundant and the new requests return all necessary info.
• assignAlias has been renamed to setAlias, with "aliasName" and "aliasURI" parameters.
• Removed getAssetsByName API.
• The getAssetsByIssuer API now accepts a multivalued "account" parameter and returns a list of lists of assets issued by those accounts.
• Use the slf4j logging framework. Thanks to ScripterRon for adapting our Logger to use slf4j! The logging can now be configured in conf/logging.properties, see conf/logging-default.properties for possible parameters and their defaults and create a new conf/logging.properties file with any custom settings if needed.
• Minor DebugTrace improvements - log Arbitrary Messages events, sender and recipient, and generated block ids.
• Improvements in transaction validation and rescan logic.
• Client updates:
  • No longer shows full list of assets. You must now add assets manually via either the asset ID or account issuer ID.
  • Instant asset bookmark search (no enter needed).

Version 1.1.3

• Handle undo of initial alias assignment in order to minimize rescans. Clear unconfirmed transactions maps after rescan instead of before.
• Added nxt.forceValidate parameter to allow re-validating blocks and transactions on startup.
• Client UI:
  • Make reed solomon account format the default.
  • Search by reed solomon account number.
  • Differentiate background color of assets owned in asset sidebar.
  • Differentiate background color of assets issued in account modal.
  • Autolink URLs in asset description and alias data.
  • Show notice on login if an update for NRS is available.
  • Added a max asset transfer warning setting.
  • Added a help menu.
  • Correct amounts on my assets page.
  • Alias search on aliases page.
  • Added global unconfirmed transactions to transactions page.
  • Show quantity of asset available for transfer in asset transfer modal.

Version 1.1.2

• Avoid unnecessary fork processing resulting in too many scans.

Version 1.1.1

• Fixed forking problem. Hopefully.
• Include guaranteedBalanceNQT (1440 confirmations) in getAccount JSON.
• Client UI:
  • Fixed AE display in Safari.
  • Removed some pre-NQT logic. Make AE visible by default.

Version 1.1.0

• Attachments are now stored in the database as byte arrays instead of serializedobjects. The conversion will take place at first start of this version and will take some time and disk space, but after shutdown the database will shrink back even more (about 25%).
• Added blockchain checkpoint at NQT_BLOCK.
• Rely on partially-canonical signatures being enforced after NQT_BLOCK to detect signature malleability attacks, removed the logic enforcing uniqueness of transaction hashes (excluding signatures). Only the fullHash (including signature) is now unique. For this reason, the "hash" property has been removed from the transaction JSON and only "fullHash" is returned now.
• Use full hash instead of id for referenced transactions. Existing transactions in the database will be reprocessed as part of the database conversion.
• Referencing transactions can refer to transactions not more than 60 days back. This limitation is enforced on the whole length of referenced transactions chain in case the referenced transaction itself refers to a previous one and so on. Also the length of such chains is limited to 10 transactions.
• Removed some NotYetEnabled checks that are no longer relevant. Removed as much as possible any obsolete logic that deals with NXT amounts, as all new transactions will only be created in NQT format now.
• More blacklisting of peers that cause RuntimeExceptions.
• Trades returned by getTrades API are now in reversed order, most recent first.
• Client Updates:
  • Add unconfirmed transactions to dashboard immediately.
  • Show appropriate message during rescanning of blockchain.
  • Limit trade history to last 50 trades.
  • Show asset buy / sell notifications.

Version 1.0.3

May 11th, 2014

• Account.getPublicKey() should return null if the key has not yet been included in a block. Related to blockchain download stuck at height 133933 bug.
• Increased default timeouts in nxt-default.properties.
• Client UI:
  • Fixed NQT parse error.
  • Fixed scrollbar issue in asset exchange.

Version 1.0.2

May 10th, 2014

• Added getUnconfirmedTransactions API, returning the full JSON objects for all unconfirmed transactions, optionally filtered by account parameter.
• Added win-compile.sh script for compiling on windows.
• GetForging also shows "remaining" time to forge a block.
• Clear Generator state on rescan, likely the cause of repeating scans problem.
• Client Updates:
  • Do not forge automatically when downloading the blockchain.
  • Wait until blockchain finished downloading before allowing form submits.
  • Update notification fix.
  • Make blocks and peers page auto-update.
  • Show buy/sell notification of assets.

Version 1.0.1

May 9th, 2014

• Added getAssetsByIssuer API to get all assets issued by an account.
• Added getAskOrders and getBidOrders API calls, returning the full JSON objects.
• Added BlockchainProcessor.getLastBlockchainFeederHeight(), to help determine blockchain download status. Note that this is present only when the current feeder peer also supports it, i.e. starting from this release.
• Added BlockchainProcessor.isScanning() to check for re-scan in progress.
• Added getBlockchainStatus API containing the above status, it is more efficient to use this instead of the getState API.
• Enhanced DebugTrace to log lease begin and end events, and lessor guaranteed balances for each block, in nxt-trace.csv file.
• Added server-side support for Reed-Solomon encoding of account numbers, thanks to ChuckOne who converted the javascript version to java. All API calls that accept account numbers can now recognize either account id's or Reed-Solomon addresses. JSON data responses that contain account numbers now also have them in Reed-Solomon format too.
• Added Crypto.getPrivateKey() and Crypto.curve() methods. Added the Bouncy Castle library, to be used for AES encryption instead of the limited strength default implementation.
• Added Account.getForgedBalanceNQT() to keep track of total forging fees earned by each account, available as forgedBalanceNQT in getBalance and getAccount.
• Increased default database query lock timeout to 10 s, nxt.dbDefaultLockTimeout in nxt-default.properties.
• Re-check unconfirmed pool for double-spending transaction after each block push.
• Support for IPv6 connections, patch provided by ScripterRon.
• Updated jetty to version 9.1.5. Make sure first to delete the old jetty jar files from lib if just unpacking this release on top of an older installation.
• Client Updates:
  • Built-in Reed Solomon support. Not enabled by default yet. Go to settings to change.
  • Added user warning when amount NXT or fee NXT are higher than maximum specified in settings.
  • Added forged balance to dashboard.
  • Asset exchange is now searchable.
  • Blockchain download progress uses new API.
  • Show (unconfirmed) transaction immediately on dashboard after form submit.

Version 1.0.0

April 28, 2014

• The old NRS UI is now disabled by default. Only the new UI is available, at http://localhost:7876
• Added Account lease events, Listeners can be registered for LEASE_SCHEDULED, LEASE_STARTED and LEASE_ENDED. This is of interest to Java API users only.
• Minor bugfixes. Avoid new transaction validation errors during blockchain scan. Removed NotYetEnabled checks for milestone blocks that have already passed.
• Added README.txt file, see that for installation and configuration instructions.

Version 0.9.10e

April 27, 2014

• Added getAllAssets API which retrieves all Assets, and getAssets API which takes a multivalued "asset" parameter and returns the Assets with corresponding assetIds.
• Added signTransaction API which takes unsignedTransactionBytes and secretPhrase and returns the signed transactionBytes, transaction id, full hash, and signature hash. The transaction is not broadcasted.
• To prevent denial of service attacks, transactions that need to stay in the unconfirmed transactions pool, while waiting for their referenced transactions to arrive, will be charged 100 NXT refundable deposit. This is subtracted from the unconfirmed balance of the account when the transaction is accepted into the unconfirmed pool, and is refunded back when the transaction is either confirmed, or expires and is removed from the pool.
• Added Wesley's UI under html/ui, available by default on http://localhost:7876

Version 0.9.9

April 25, 2014

• All http APIs that submit a new transaction now allow an optional "broadcast" parameter. If set to "false", transaction will not be broadcasted, if any other value, transaction will be broadcasted. Transactions that are not signed will of course never be broadcasted. The signed and unsigned bytes are always returned with the transaction JSON, so the signed bytes can be broadcasted manually later.
• Minor bugfixes related to referenced transaction id handling.
• The calculation of full transaction hash (and therefore transaction id too) has been changed, taking effect at NQT_BLOCK. Instead of using signature as part of the bytes over which the hash is calculated, the sha256 hash of the signature is now used.
• After NQT_BLOCK, the above change will allow a simple way of transaction escrow, relying on the referenced transaction feature we already have:
  • Alice prepares and signs a transaction A, but doesn't broadcast it (setting the broadcast=false parameter introduced in this release). She sends to Bob the unsigned transaction bytes, the full transaction hash, and the signature hash. All of those are included in the JSON returned by the API. (Warning: make sure not to send the signed transaction bytes, or the signature itself, as then Bob can just broadcast transaction A himself).
  • Bob prepares, signs and broadcasts transaction B, setting the referencedTransactionFullHash parameter to the full hash of A provided by Alice.He can verify that this hash indeed belongs to the transaction he expects from Alice, by using the new calculateFullHash API, which takes unsigned transaction bytes and signature hash (both of which Alice has also sent to Bob). He can also use the parseTransaction API to decode the unsigned bytes and inspect all transaction fields.
  • Transaction B is accepted in the unconfirmed transaction pool, but as long as A is still missing, B will not be confirmed, i.e. will not be included in the blockchain. If A is never submitted, B will eventually expire - so Bob should make sure to set a long enough deadline, such as the maximum of 1440 minutes.
  • Once in the unconfirmed transactions pool, Bob has no way of recalling B back. So now Alice can safely submit her transaction A, by just broadcasting the signed transaction bytes she got in the first step. Transaction A will get included in the blockchain first, and in the next block Bob's transaction B will also be included.
    • Note that while the above scheme is good enough for a simple escrow, the blockchain does not enforce that if A is included, B will also be included. It may happen due to forks and blockchain reorganization, that B never gets a chance to be included and expires unconfirmed, while A still remains in the blockchain. However, it is not practically possible for Bob to intentionally cause such chain of events and to prevent B from being confirmed.
• Because of the change in transaction id calculation, on test net, NQT_BLOCK has been moved to 76500, which will cause a minor reset deleting blocks after 76000.
• On main net NQT_BLOCK is now set to 132000, FRACTIONAL_BLOCK at 134000, ASSET_EXCHANGE_BLOCK 135000. Any bugs in NQT or AE need to be found and fixed before that.
• The deadline for upgrade to 0.9.9 is block 130000, when the lease balance feature gets enabled. 0.8.13 nodes will be on a fork after that block. 0.7.7 nodes are most likely already on a fork.
• Since the 0.9 branch API accepts amounts in NQT only, any client, website, or exchange still using amounts in NXT, based on the 0.8 API, should upgrade to the 0.9 NQT API before block 130000. Otherwise they are stuck with 0.8.13, which as I said will be on a fork after that block.

Version 0.9.8e

April 20, 2014

• This release is for testnet only. It will also cause another testnet reset,so it is required that all testnet nodes update to it.
• Switched to using full 256-bit hash for referenced transaction ids. The complete switch in the use of full hash will only be implemented after NQT_BLOCK, but as it requires a hard fork again, the change in transaction bytes format from long to 256-bit hash for referenced transaction is now scheduled to happen at NQT_BLOCK.
• First run will perform some database schema updates again, and will also delete testnet blocks after 63000. NQT_BLOCK will now be set to 76000 at testnet, so we have one last chance of testing non-fractional amounts plus the current referenced transaction changes before and after NQT_BLOCK. Balance leasing will be enabled on testnet at block 75000 now. After the reset, testnet will start from block 74590, so we have around 1000 blocks before NQT_BLOCK on testnet.
• The transaction fullHash, which includes the signature unlike the other hash we currently have, is now also available in the transaction JSON. It is also possible to retrieve a transaction based on its fullHash using getTransaction.
• The http API referencedTransactionId parameter has been replaced with referencedTransactionFullHash, a hex-encoded 256-bit full hash.
• The transaction JSON also includes referencedTransactionFullHash, if not null, and for now also includes referencedTransactionId. Until NQT_BLOCK is passed, users of this API should really check both, as for transactions before NQT_BLOCK it cannot be guaranteed that referencedTransactionFullHash is available because it is not a part of the byte array transaction format. After NQT_BLOCK is passed, this will be changed to always include referencedTransactionFullHash in the JSON (also for old transactions), and the referencedTransactionId will be removed.
• Added nxt.usePeersDb to nxt-default.properties, enabled by default. This is to disable use of saved peer addresses, useful for test purposes only.

Version 0.9.7

April 18, 2014

• Added parseTransaction API, which takes transactionBytes and returns the JSON representation of the transaction, including a "verify" boolean whether the signature verified correctly. Note that the interpretation and validation of the bytes is dependent on the current last block height - if it is before or after NQT_BLOCK.
• To avoid becoming dependent on a few centrally controlled public nodes, all known peers are now regularly saved in the database. When created from scratch, the database is seeded with 200-300 public peers hardcoded in the DbVersion code. After that, any time the node fetches new peers from the network, it will also save them to the peer table, and delete those that are blacklisted or unreachable at their announced address.
  • This feature is optional, and the nxt.savePeers parameter can be set to false in nxt.properties, for those who don't want to leave any trace on their hard drive regarding which peers their node has been connecting to, to prevent possible network correlation attacks.
  • The nxt.wellKnownPeers and nxt.testnetPeers parameters are still used, with those peers always added to the database on startup.

Version 0.9.6

April 17, 2014

• Validate that lease recipient account has public key set before accepting lease transaction. This check will cause some minor rollback of testnet as blocks containing such lease transactions will be deleted.
• Optimizations in balance leasing. Keep negative values of guaranteed balance for internal calculations only, effective balance now always non-negative. Other minor bugfixes and improvements.
• Effective balance leasing will be enabled on main net at block 130000. This means all nodes should be updated to version 0.9.6 or later before that, or there will be a fork. We have until then to find and fix any serious bugs in balance leasing. And all clients to be used on main net should have switched to handle NQT amounts before that, as the 0.9 API only accepts amounts in NQT. The actual block of transition to NQT will be decided later.

Version 0.9.5e

April 14, 2014

• Added leaseBalance http API to allow leasing of effective balance. The "period" parameter, defined in number of blocks, determines the length of the lease. Minimum period is 1440 blocks, maximum 32767. The lease starts 1440 blocks after the leaseBalance request is submitted, not immediately. If a lease is currently in progress and a new lease is submitted, the new lease will take effect at the end of the current lease, but no earlier than 1440 blocks from the current block.
• During a lease, the whole guaranteed balance of the leasing account, with at least 1440 confirmations, is added to the effective balance of the recipient account.
• Forging fees are earned only by the recipient (lessee) account, and there is no mechanism in the blockchain to enforce that the lessee account distributes back any part of those fees, so it would be up to the forging pool owners to schedule and perform such redistributions.
• Information about lessees and lessors is added to the JSON result of the getAccount API.
• This feature will be enabled on testnet at block 73000 so that it can be fully tested.

Version 0.9.4e

April 14, 2014

• Added Digital Goods Store, Effective Balance Leasing, and Hub Terminal announcement features. Those are still untested, lack an http API, and are currently disabled even on testnet, so that not to interfere with the testing of the Asset Exchange.
• Enforce canonical signatures and canonical public keys, after NQT_BLOCK.
• Added setAccountInfo http API, which uses an Account Info transaction to set name and description properties of an account. Those fields, if set, will be returned as part of the getAccount JSON. Account Info will be enabled at NQT_BLOCK, so it should be working on test net after this release.
• Fixed a bug in Asset Transfer quantity handling that was preventing transaction confirmations on testnet.
• Two new properties in nxt-default.properties, to make it easier to import nxt.trace as csv file:
  1. Separator character for trace log
     • nxt.debugTraceSeparator=\t
  2. Quote character for trace log
     • nxt.debugTraceQuote="
• Jetty has been updated to version 9.1.4, and H2 to version 1.3.176. Make sure to delete the old versions from the lib directory first, if you do upgrades just by unpacking the zip file on top of an existing installation.
• Bugfixes and improvements in transaction validation. Existing transactions will be checked once at first start of this version, which may cause some turbulence on testnet as invalid blocks will be deleted.

Version 0.9.3.1e

April 09, 2014

• Fixed parsing of Issue Asset transactions. Testnet nodes should upgrade.

Version 0.9.3e

April 07, 2014

• Removed all quantityINT, balanceINT, amountNXT, priceNXT, feeNXT return values from the JSON API, and removed support for parsing of INT and NXT parameters. Only NQT (for amounts) and QNT (for quantities) units are supported now.
• Enabled running on main net. NQT_BLOCK is set to 150000 for main net, until then fractional amounts remain disabled. Integer NXT amounts and fees should work normally on main net too, and this release should be network compatible with 0.8.13 peers. NOTE: 0.7.* peers are no longer supported. Everyone should update to 0.8.13 as a stable version now, and be prepared to update to the 0.9 branch when it is declared stable.
• As the NRS javascript UI will no longer be developed, and nobody has the time to convert it to use a BigInteger javascript library, it still accepts amounts and fees in NXT, which are converted to NQT on the server side. Return values are in NQT, and may result in overflow in the javascript for amounts exceeding 2^53 NQT (around 90 million NXT). Such overflow should only affect the UI, inputs are handled as strings and converted to longs on the server side. Still, for transactions of such size, better stay with the stable 0.8.13 branch, or use a different client.
• At first run on main net, just like it did on test net, the database version code will update the amounts and fees columns in the block and transaction tables to NQT, which will take some time. During that process the database size will temporarily increase a lot, to around 1 GB. It will shrink back at shutdown (which again takes some time), to around 180 MB.

Version 0.9.2e

April 06, 2014

• Fractional asset quantities. Enjoy another reset of testnet.
• When issuing an asset, the maximum allowed number of digits after the asset quantity decimal point can be specified as "decimals" parameter (allowed values 0 to 8). For example, this would be 2 for a currency like EUR, 8 for Bitcoin.
• Similar to prices, asset quantities can be specified either as quantityQNT,expressed in the smallest possible quantity unit ("quant") for the specific asset, or as quantityINT, expressed in whole asset units (which may however contain a fractional part despite its name). For example, 9.97 USD can be expressed as either quantityINT="9.97", or quantityQNT="997", assuming decimals=2 for USD.
• JSON responses containing quantities or asset balances are again returned in both quantityINT and quantityQNT, as strings.
• When placing an ask or bid order, if quantityQNT is specified, the price is interpreted to apply to QNT quantity units (regardless of whether the price itself was specified in NXT or in NQT). If quantityINT is specified, the price is interpreted to apply to INT quantity units.For example, a bid order for quantityQNT="300", priceNXT="2", for asset USD will be interpreted as $3.00 at 1 cent = 2 NXT, i.e. 200 NXT for one dollar, 600 NXT total.If parameters are submitted as quantityINT="7", priceNXT="50", the order will be for $7.00 at 50 NXT for one dollar, 350 NXT total.
• Internally order matching and tracking of account asset balances is always done in quantityQNT. An unfortunate side effect for now is that when placing an order using quantityINT, the calculated price in NQT for one QNT unit must be an integer. So you cannot place an order for quantityINT="1", priceNXT="10.12345678" (or equivalently priceNQT="1012345678"), because then the price of one quantityQNT will be 10123456.78 NQT. The priceNXT will have to be either 10.12345600 or 10.12345700. If this is confusing, specify the order as quantityQNT="100", priceNQT="10123456".

Version 0.9.1e

April 03, 2014

• Always return amounts in both NXT and NQT, represented in the JSON as strings.
• Refactoring of the JSON generating code, removed getJSONObject from Block and Transaction.
• Transactions causing block generation to fail will always be removed from the unconfirmed transactions pool.
• Fixed overflow in hallmark weight calculation.
• Fixed transaction JSON parsing bug.
• All testnet nodes should be updated to this release.

Version 0.9.0e

April 03, 2014

• This is an experimental preview release, which will only run on testnet. It will refuse to start on main net, so don't try it there. However, all testnet nodes should be updated to 0.9.0e, so that we can start testing transactions with fractional NXT amounts.
• All transaction amounts and fees will begin to be handled in NQT, 10^-8 NXT, starting from the NQT_BLOCK, which for test net is set to height 63000. When we do the transition on main net, it will be done in several steps, to preserve compatibility with older versions, and of course not to reset the main blockchain. This should also be tried on testnet first, so expect at least one more reset of testnet later. But for this release on testnet, existing assets will again be deleted, blockchain reset back to block 63000, and fractional amounts and asset exchange enabled immediately at block 63000.
• Implementation details:
  • Internally, all amounts are handled in NQT, using Java longs (64-bit). The database amount and fee columns will also be converted to NQT stored as BIGINT. This change is for both old (before NQT_BLOCK) and new transactions. Only when verifying the signatures, old transactions and blocks are represented in bytes using int (32-bit) instead of long amounts and fees. For peer to peer compatibility, transaction JSON for old transactions will contain amounts both in NQT and in NXT. To prevent overflows, all additions and multiplications of longs are done using precondition testing methods, Convert.safeAdd and Convert.safeMultiply, which check for possible overflow before doing the operation.
  • All relevant Java APIs have been renamed to indicate that the value returned is in NQT, except for getEffectiveBalanceNXT which is only used when forging and there it is needed in NXT.
  • The http API has been changed to accept amounts either in NQT or in NXT, with fractional amounts received as strings in the http request parameters and then parsed directly to longs. The returned JSON objects use NQT only. All relevant http parameter names and JSON parameters have been changed to indicate whether they are in NQT or NXT.
  • Asset prices are also changed to use NQT, instead of NXT-cents. But I have not tested asset exchange transactions at all, I have only tested simple send money transactions, so expect bugs.
  • Fractional asset quantities are not yet implemented.

Version 0.8.13

April 01, 2014

• Prevent duplicate hash transactions in the unconfirmed transactions pool.
• Added a comment field to the Asset Transfer transaction type, up to 1000 chars. This will force a deletion of all blocks on testnet starting from the first one that contains an asset transfer transaction, the first time this new version is started.
• Added optional filtering by account to the getUnconfirmedTransactions API.
• Added getAllOpenOrders API request.* Added AccountAsset Listeners to Account, to receive notification of asset balance changes specifying the asset that changed balance.
• Return an error on trying to broadcast an insufficient funds transaction,and do not try to re-broadcast such transactions.
• Improvements to the DebugTrace and VerifyTrace facility.
• Updated Jetty to version 9.1.3.

Version 0.8.12

March 21, 2014

• This release is only about testing and debugging. There is no need to upgrade if you are not interested in doing testing.
• Added DebugTrace.java, which uses listeners to monitor all changes to account balances and asset balances, and all the events that cause those changes - transactions, block generation fees, order placement, asset issuance, asset transfer, order cancellation, trade.
• This feature uses two new properties in nxt-default.properties:
  • nxt.debugTraceLog=nxt.trace
  • nxt.debugTraceAccounts=
• To enable tracing of account balances, set nxt.debugTraceAccounts to a list of account id's to be tracked, separated by "; " . The output will be saved to nxt.trace, or the file defined in nxt.debugTraceLog. Values in this file are tab-separated, to make it easy to import into a spreadsheet application.
• It is possible to enable tracing of all existing account balances, by setting nxt.debugTraceAccount=* .
• On restart, and also on rescan, the nxt.trace log will be overwritten.
• Added VerifyTrace.java, which can parse the nxt.trace file (or a file specified as a command line argument), and perform some verifications. Currently, it verifies that for each traced account, the final balance matches the total of all changes that affect that account, as recorded in the nxt.trace log. It also verifies that for each asset, the total of asset quantities in all accounts matches the original quantity of asset issued. This verification can be expected to fail if not all accounts that own an asset are included in debugTraceAccounts.
• To run VerifyTrace, use the verify.sh script. The Nxt server should be stopped first, so that the nxt.trace log does not continue to be updated while VerifyTrace is verifying it.
• Unconfirmed balances and unconfirmed asset balances are logged, but not verified by VerifyTrace, because the presence of open or partially filled orders can make that too complicated. It may be easier to program a spreadsheet application to handle such calculations.
• Added TRADE event, triggered when a Trade occurs. Note that the Trade event happens before the update of the account balances.
• Added BEFORE_BLOCK_APPLY and BEFORE_BLOCK_UNDO events, triggered just before the corresponding operations in block processing.

Version 0.8.11

March 19, 2014

• Allow non-unique asset names.*Added getAssetsByName API call returning a list of all assets with given assetName.
• Added getAllTrades API call returning all trades starting from a given timestamp (contributed by Antanst).
• Improved the JSON responses for several API calls: getAsset now also returns numberOfTrades. getAccount now also returns unconfirmedBalance. broadcastTransaction now also returnstransaction hash. getAsk/BidOrder now also returns order height.Performance of getTrades should be greatly improved, and it also returns block id for each trade.
• Explicitly stop all jetty servers when Nxt.shutdown() is called.
• Escape text inserted as peer software or peer announced address in the NRS client html, to prevent cross-site scripting and related attacks by malicious peers.
• Now that Crypto.sign() never produces bad signatures, no need for additional call to verify() after block sign, or for multiple transaction sign attempts.

Version 0.8.10

March 15, 2014

• Better transaction attachment validation. Blocks that incorrectly got accepted but later fail to be processed for any reason, will be deleted from the database.
• Better validation of minimum fee for different transaction type.
• GetAccount API will also return unconfirmed asset balances.
• BroadcastTransaction now verifies the signature of received transaction bytes before broadcasting the transaction.
• Removed forging code no longer in use. Generating blocks below height 30000 (transparent forging phase 1) is no longer supported.
• Made Db.getConnection() public and added Blockchain.getBlocks and getTransactions methods taking PreparedStatement as parameter, for use by Java API clients.
• Added an APITestServlet for manual debugging and testing of the API. All http API calls will now automatically be listed under http://localhost:7876/test or if you need to try only a specific one, e.g. getBalance: http://localhost:7876/test?requestType=getBalance
  • Unlike the admin.html page, this listing is automatically generated and will include all available API calls without having to be manually updated when a new one is added.
• Applied the patch to Curve25519.sign() suggested by DoctorEvil. Block and transaction signing should no longer fail to verify.

Version 0.8.9

March 13, 2014

• Client-side transaction signing support. All http API requests that create a new transaction, now accept either a secretPhrase or a publicKey parameter. If secretPhrase is supplied, transaction is created, signed at the server, and broadcasted by the server as usual. If secretPhrase is not supplied, but a publicKey parameter is, as a hex encoded byte array, the transaction will be prepared by the server and returned in the JSON response as transactionBytes. This byte array can now be signed by the client, and then sent back to the server for broadcasting using the broadcastTransaction API.
• Transaction hashes, which can be used to uniquely identify transactions to avoid transaction signature malleability attacks, can now be obtained using Transaction.getHash(), and are also available in the JSON representation of transactions. The hash can also be used to retrieve a transaction from the server, instead of using transaction id, by supplying a hash parameter to the getTransaction http API instead of transaction parameter.
• For improving performance, getBlockId and getBlockTimestamp Java API methods have been added to the Transaction class, to avoid the need to call getBlock which may require additional database query. Java clients should use those instead of going through getBlock. Similarly, the blockTimestamp field has been added to the JSON returned by getTransaction and the other API calls that return a transaction JSON, so http clients can also avoid unnecessary calls to getBlock.
• Upgrading to 0.8.9 will modify the database to add the hash and block_timestamp columns to the transaction table.
• Transactions that have become invalid will now also be removed from the re-broadcasting pool.
• Moved all global constants to Constants.java.
• Improved transaction validation for Asset Issuance transactions to avoid misleading invalid transaction errors.
• Corrected handling of transactions with identical timestamps in block generation and in the NRS client UI.
• Added ASSET_BALANCE and UNCONFIRMED_ASSET_BALANCE events to Account, fixed possible problem with asset balance calculation.

Version 0.8.8 / 0.7.7

March 7, 2014

• Fixed incorrect setting of genesis block timestamp whenlocal time is in the daylight savings period. This must have been the reason for users in the southern hemisphere being unable to forge.
• Since DST in the US starts March 09, it is critical that at least those in the US upgrade to 0.8.8 or 0.7.7.
• There are no new bugfixes or features in 0.7.7 relative to 0.7.6 other than this daylight savings time fix.

Version 0.8.7

March 6, 2014

• Fixed unconfirmed balance calculations for the genesis block account.
• Fixed the display of the genesis account balance in the NRS UI.

Version 0.8.6

March 5, 2014

• Transaction re-broadcasting has been broken for a few releases, should work again now.
• Fixed the update of the NRS UI transaction confirmation count.
• Check for unconfirmed transaction becoming invalid, and if so, remove them from the unconfirmed transactions pool.
• Added a few more well known testnet peers in default properties.
• Converted run.bat to CRLF line endings format.
• Asset exchange specific bugfixes:
  • Order cancellations should update unconfirmed balances only.
  • On block pop-off, asset balances should not be updated.
  • When a trade is executed at a price lower than the bid order, correct the bidder unconfirmed balance for the difference.

Version 0.8.5

March 4, 2014

• More bugfixes related to unconfirmed balance calculation.
• Minor fixes to avoid some harmless exceptions.

Version 0.8.4e

March 3, 2014

• Several changes in the calculation of unconfirmed balances and unconfirmed asset balances. This is an attempt to fix the negative unconfirmed balance bug and "Not enough funds" error, but hasn't been tested, this is why this release is experimental.
• Enabled use of testnet just by setting nxt.isTestnet property in nxt.properties. No other changes are needed.
• When switching to testnet by setting nxt.isTestnet=true, peer port becomes 6874, UI port 6875, and API server port 6876. Those values are hardcoded to prevent mistakes and take precedence over any custom port values in nxt.properties. Also, when NOT using testnet, the server will refuse to start if peer port is set to 6874, again to prevent accidental mixing of real and test blockchains.
• For testnet, a new subdirectory for the test blockchain will be automatically created, nxt_test_db.
• You need to set nxt.testnetPeers to a list of known public test nodes. I have set up bug.airdns.org with the 0.8.4e code, and a copy of the testnet blockchain, as obtained from holms. I hope other people will also set up test nodes and announce them on the forum.
• In this release, when switching to test net, the Voting and Asset Exchange features will be automatically enabled. On the real net, they will still be disabled. The NRS UI client however doesn't support those features, so you would need to use a different UI, or use the http API directly.
• Added nxt.knownBlacklistedPeers parameter, for manual blacklisting of peers in the nxt.properties file.
• No longer overwrite the peer address with its announced address in the Active peers panel, use only the IP to uniquely identify a peer.
• Allow disabling of the DoSFilter for the peer networking server. Added nxt.peerServerDoSFilter.maxRequestMs=300000 parameter, because the default value for the DoSFilter maxRequestMs forcefully closes peer requests taking longer than 30 s, which breaks blockchain downloads for slow peers. This is very likely the cause for the Jetty error warnings we had back in 0.5.x days.
• Added Generator.getAccount method, and START_FORGING and STOP_FORGING events, of interest to Java API clients.
• Added run.bat script for Windows users.
• Source code is now included in the release package under the src directory. The compile.sh and javadoc.sh scripts can be used to compile the source, and regenerate nxt.jar and the javadoc documentation.

Version 0.8.3

February 26, 2014

• Fixed UI problems with display and updates of My Transactions. Consistent counting of transaction confirmations. Transactions included in the last block are considered having 0 confirmations.
• When a block is pushed, the BLOCK_PUSHED event is now emitted before the REMOVED_UNCONFIRMED_TRANSACTIONS and ADDED_CONFIRMED_TRANSACTIONS events.
• Added BlockchainProcessor.RESCAN_BEGIN and RESCAN_END events, triggered before and after a re-scan (not the regular start-up scan).
• Fixed a few null pointers caused by bad peer data.
• Improved handling of peer addresses and hallmarks.
• Added blacklisted status to peer info.

Version 0.8.2e

February 25, 2014

• Mostly minor fixes for problems reported with 0.8.1e.
• Fixed hallmark string in json peer info.
• Improved Logger, added removeListener methods.
• Don't set Content-length headers when using XMLHttpRequest to send POST requests.
• Added jetty-security jar.
• Moved worker_sha256.js to tools.
• Also add random mynxt.info nodes to default wellKnownPeers.

Version 0.8.1e

February 24, 2014

• Improved handling of peer announced addresses and ports. Setting nxt.myAddress is now optional, which will help users with dynamic IP addresses. When connecting to a peer, as long as nxt.shareMyAddress is enabled, it will at a later time attempt to connect to your announced address, or if not set, to the address your request came from. If successful, the peer will use this address to connect to you in the future, and will share it with others. This also does verification of announced addresses, and considers your node connected only after a successful connection to the announced address is made. This will prevent invalid announced addresses from being spread to other peers too.
• If you need to use a non-default port, the port has to be appended to your announced address too. It does not need to be the same as nxt.myPeerServerPort, so you can run the server on one port but forward a different router port to it. If the port is not set in announced address however, but nxt.myPeerServerPort is non-default, nxt.myPeerServerPort will automatically be appended to the announced address.
• To summarize: For users with dynamic IPs, you don't need to put anything in nxt.myAddress, but still need to set up port forwarding at your router.
• Verification of hallmarks has also been improved to attempt to resolve hostnames to IP addresses. Note that if you use a non-default port, the hallmark should include your address only, without the port.
• Added generateToken API request. Parameters are secretPhrase and website, response is the token string wrapped in JSON. This is also available on the admin.html page.
• Improved handling of init and shutdown. Nxt.shutdown() is now public and client developers can call it. When Nxt is started as a standalone application by calling main(), it will schedule a shutdown hook, otherwise if started using init(), the caller of init() is responsible for calling shutdown() or scheduling a shutdown hook.
• Delayed starting the blockchain scan and the jetty servlets until the initialization of all classes has completed. This should allow registering listeners with those, and will also help prevent errors due to servlets starting to accept requests before the system is fully initialized.
• If nxt-default.properties is not found in the classpath, Nxt will also make an attempt to load it from the file defined in the system property nxt-default.properties, so you can define it on the command line: java -Dnxt-default.properties=conf/nxt-default.properties. This is of interest to client developers only.
• Support use of POST in addition to GET for all API and UI http requests. To enforce use of POST only, for those requests that require the user secretPhrase, the nxt.properties nxt.apiServerEnforcePOST and nxt.uiServerEnforcePOST can be set (default is false for API, true for UI). This way client developers can enforce that only POST requests are used for handling sensitive data.
• The default NRS browser UI has been changed to use POST only, and so have the tools - admin.html, message.html, alias.html. This way the user secretPhrase will no longer be cached in the browser memory.

Version 0.8.0e

February 22, 2014

• This release introduces a major change in the Nxt server architecture. Instead of being a servlet run by Jetty, Nxt is now a standalone application which itself launches Jetty servlets, when needed. This should make it easier to use as a Java library, as it no longer needs to be run inside a servlet container.
• The Nxt configuration has been made more flexible, both for the end user and for application developers. Nxt no longer uses web.xml, or any xml files for that matter. Instead, a user-friendly properties file is used.
• The layout of the distribution has been changed and simplified. Unpacking the zip file will produce the following directory structure:
  • nxt/conf/
    • This is where the configuration files are kept. All default properties are in conf/nxt-default.properties. You should never edit this file, unless you are a packager or client developer who needs different defaults for his distribution. All default values are reasonable, so Nxt can just be started without any configuration. If however the end user wants to customize some parameters, the way to do that is to create another properties file, conf/nxt.properties, containing ONLY the properties that need to be different from the defaults. Nxt will read both nxt-default.properties and nxt.properties, and the values in nxt.properties will override those in nxt-default.properties.
  • nxt/html/
    • This contains the html files needed for the NRS javascript based client, under html/nrs, the html-based tools such as admin.html and update.html under html/tools, and the javadoc documentation for the Java API under html/doc.
  • nxt/lib/
    • This is where all required Java libraries are kept - Jetty, H2 database, and the JSON-simple library. All Jetty libraries that are not used by Nxt are no longer included, which also results in a smaller distribution package.
  • nxt/nxt.jar
    • This jar contains all compiled Nxt classes.
  • nxt/run.sh
    • This script is the simplest way to start Nxt, under Linux:
      
      java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
      
      As you can see, the classpath needs to include nxt.jar, all the jars under lib, and the conf directory.
• Notably missing are start.jar, webapps, and the Jetty configuration directories, which are no longer needed.
• In addition to the switch to embedded Jetty, significant refactoring of the code has been done, which may be of interest to users of the Java API. The changes are too many to describe here, but can be easily seen by comparing the javadoc of 0.8.0 with that of the 0.7 branch. Most notably, interfaces have been defined for the Block and Transaction classes, the Blockchain class has been split into several classes, and the Peer and User classes have also seen some clean up.
• Client developers using the Java API can override any of the default properties by submitting a custom Properties object to Nxt.init().
• The configurable properties in nxt-default.properties are all documented in the comments in that file. Some additional details about those:
• Nxt will start up to three different Jetty servers, if needed.
• The peer networking server accepts http requests from peers. It is only started if nxt.shareMyAddress=true (which is the default). If you are behind a firewall and don't have an externally visible IP, you can set this to false to disable it.
• The port and host interface of the peer server are configurable. If you set a non-default port in nxt.peerServerPort, this will be appended to the address you announce to peers (this address should be set in nxt.myAddress). Using non-default peer networking port hasn't been tested much though.
• For a machine with multiple network interfaces, now you can specify on which interface to bind each server. By default, nxt.peerServerHost=0.0.0.0 so the peer networking server listens on all interfaces.
• There are no hardcoded nxt.wellKnownPeers in the default properties files. You are supposed to set those to your own preferred peers in nxt.properties. However, if none are set, a random selection of nxtcrypto.org and nxtbase.com public nodes will be used.
• The DoS Filter is enabled for the peer server only.
• The API server accepts http/json API requests. By default, now it runs on port 7876, and listens on the local 127.0.0.1 interface only. If you run a public node and want to accept API requests from anyone, set nxt.apiServerHost to 0.0.0.0, and nxt.allowedBotHosts to * (or empty).
• The nxt.apiResourceBase points to a directory of static html files that are also served by the API server. Developers of clients using the http/json API will want to customize this to point to their client html and javascript files.
• The Jetty Cross Origin Filter can be enabled for the API server by setting nxt.apiServerCORS=true (disabled by default).
• The UI server is used for the NRS javascript client UI. By default it runs on port 7875 and accepts requests from localhost only. Client developers using the same API calls as the NRS client (not the http/json ones) should customize nxt.uiResourceBase to point to their client html and javascript files instead.
• SSL can be enabled for both the API server and the UI server (default disabled). If this is done, the corresponding ports will accept https requests only. There is no way currently to have both http and https supported at the same time, but this can be added, I just didn't see the need for it. If you enable SSL, you need to set nxt.keyStorePath and nxt.keyStorePassword, and obviously you need to have your own SSL certificate (self-signed or signed by a CA) in a keystore file. I have only tested this with a self-signed certificate.
• Client developers using the Java API will probably want to disable both the API server and the UI server, and for users without a visible IP address even the peer server.
• Debugging output is now disabled by default, but can be enabled by setting nxt.debug=true. Exception stack traces will still be logged, as long as nxt.enableStackTraces=true. I hope there will be none of those.
• The connection to the database can be completely customized, as the full jdbc url used to connect to it is exposed in the properties file and can be modified. Client developers that insist on being able to access the database from a separate process, while Nxt is running, can do so by appending ;AUTO_SERVER=TRUE to the jdbc url, which will enable automatic mixed-mode. This is disabled by default, but if you enable it and write to the database while Nxt is running, expect things to break.
• It is also possible to have the database in a different location, not just in the current working directory, if you change the jdbc url accordingly.
• To change the amount of memory used for the database cache, use the nxt.dbCacheKB parameter, in kilobytes. If set to 0, by default 50 % of the memory available to the JVM is used for database cache.
• There have been no changes to the database schema, you should use your existing nxt_db directory with this release too, instead of downloading the blockchain from scratch.
• This release is labeled experimental, but please try it. In particular, the client developers and packagers should test it well, and if there are no major issues, expect the 0.7 branch to become obsolete soon.

Version 0.7.6

February 19, 2014

• Compact the database at every shutdown. This should help reduce the size of the nxt_db directory after the first run, check the before and after disk usage.
• Prevent duplicate peer listings in the known peers and blacklisted peers frames.
• Prevent a potential duplicate account key attack, of the type described here: https://bitcointalk.org/index.php?topic=397183.msg4569817#msg4569817
• Added Voting System, not yet enabled.
• Some refactoring of the Block and Transaction classes.
• Asset exchange bugfixes from the test network and more API requests.
• Improved validation of transactions to prevent wrong blacklisting of peers, and to better enforce transaction validity.

Version 0.7.5

February 14, 2014

• Various performance and memory usage improvements.
• Improved validation of peer addresses and handling of peer connection status changes.
• User interface improvements related to peer display.
• Additional optimizations in getMilestoneBlockIds, backwards compatible.
• Further clean up of the core nxt classes from all UI related parameters.

Version 0.7.4

February 13, 2014

• Another bugfix in the transition to Transparent Forging, starting from block 67000. Upgrade before this block, because there will be a fork.
• This release drops support for the old getMilestoneBlockIds protocol. Clients older than 0.7.3 will not be able to request blocks from 0.7.4 nodes. Everybody needs to upgrade to 0.7.4 anyway, before block 67000.
• Some optimizations in the database queries used during unlock account, let's see if this helps Raspberry users.
• Minor other improvements.

Version 0.7.3

February 12, 2014

• The 0.6.x series is no longer supported. Starting with this release, only the database version will be developed.
• Optimized the getMilestoneBlockIds protocol. This is the peer to peer request that currently puts the most load on the public nodes, and is a cause of a large amount of unnecessary outbound traffic. However, for backwards compatibility, version 0.7.3 still supports both the old and the improved getMilestoneBlockIds protocols, so when older clients connect to 0.7.3 nodes they will still cause unnecessary load and extra traffic, unfortunately.
• WARNING: Support for the old getMilestoneBlockIds protocol will be removed in 0.7.4. You don't need to upgrade immediately, but if you don't do it before 0.7.4 comes out, your older version nodes will not be able to request blocks and catch up with the blockchain. Better upgrade sooner than later.
• More and more refactoring. Completely separated the user interface logic from the core business logic. Nothing in the core nxt package depends on the classes in the nxt.user package anymore. Instead, a Listeners framework is used, so that the UI can register to be notified of the events in the core that it needs to know about. This is also intended to be used by Java client API developers.
• Added some more indexes to the database tables to improve performance. These will be created automatically the first time this version is started with your existing database - no need to start from scratch, no need to delete your old nxt_db directory.
• Privacy related change: Before this release, newly generated blocks and new transactions were broadcasted to peers twice. This could allow your peers to deduce that your node was the generator of the block or transaction in question. This is now fixed. Note that somebody with the ability to monitor all your internet traffic will still be able to tell that it was you who generated a block, because the generating node sends the block before having received it from any other peer. I don't see a physically possible way to avoid that, yet. Also note that the transaction re-broadcasting feature will continue to re-broadcast your transactions until they are received back from at least one other node, but will not do that with transactions received from other nodes. This could still be used to deduce that your node was the source of a transaction, in case the initial attempt to send it failed, and it was re-broadcasted (but somebody already observed the failed first attempt).
• Separated block forging logic into a Generator class, which can also be used by Java API clients to start and stop forging.
• Added startForging and stopForging API requests. Parameters: secretPhrase, required for both starting and stopping.
• Fixed minor bugs. Fixed a bug in peer download traffic monitoring.

Version 0.7.2

February 9, 2014

• Improved performance of blockchain scan.

Version 0.7.1 / 0.6.2

February 8, 2014

• Fixed a bug in the calculation of guaranteed balance which could in some cases result in effective balance higher than the actual balance. Since this change can produce a fork, a switch to the correct calculation will happen at block 64000. Everyone should upgrade to either 0.7.1 or 0.6.2 before that block, or we will get forks.
• Improved validation of peer addresses to prevent syntactically invalid or unresolvable addresses from being included in the peers list.
• Enabled logging of all debugging output to a log file. Everything printed out to the console will also get logged to a file nxt.log. This should help with submitting bug reports in case of crashes and errors, as it doesn't matter anymore if your windows console just disappeared. The nxt.log file is overwritten at every server restart.
• Cleaned-up hallmark and authorization token processing. Added Token and Hallmark classes, those can be now used by Java client developers to generate and validate tokens and hallmarks without going through the http interface.
• Improved logging of block push failures and block pop-off events, those will now print out the block id and the reason for block rejection.
• Improved peer blacklisting and logging of reasons for blacklisting. Http requests from blacklisted peers are now completely ignored.
• Made all API request handling classes under the nxt.http package visible in the javadoc documentation, to be used for documenting the parameters and return values of the http API.
• There haven't been any database related bugs in the 0.7 series. All the above changes have been applied to both 0.6 and 0.7 branches. I encourage more people to try the 0.7.1 version, there is no need to continue maintaining the 0.6 branch very long if we don't encounter problems with the database version.

Version 0.7.0e

February 6, 2014

• This is the first release using an embedded java database (H2) to store the blockchain, instead of serialized java object files. Because this is a major change, this version is to be considered experimental.
• The blocks.nxt and transactions.nxt and .bak files are no longer used. Furthermore, they will not be loaded at startup, when you start with empty database the very first time it will need to download the full blockchain from the network.
• The database is stored under the nxt_db directory, as of now it will take around 100 MB when downloaded. If anything goes wrong and you need to start fresh, it is safe to delete that nxt_db directory, it will be recreated.
• There are no changes in the web.xml file compared to 0.6.1. I will add parameters to tweak database settings later, if needed.
• The database will use 50% of the memory available to java for its cache. The actual value is printed out at startup.
• Currently only blocks and transactions are stored in database tables, everything else such as accounts, aliases, assets, orders, messages, is loaded at startup and then kept in memory. The amount of memory those take is still small, relative to what was needed for all blocks and transactions.
• At startup, the blockchain scan takes a bit longer, this is normal. If anything else is unusually slow, I will look into profiling and optimizing it.
• There are no new user-visible features compared to 0.6.1, the code is kept in sync now (including the critical bugfixes). Having both 0.6.1 and 0.7.0e nodes on the network should not result in forks. I will maintain both the 0.6.x and 0.7.x branches for some time, until all major database related issues are discovered and fixed. Please report bugs, including the stack traces.

Version 0.6.1

February 6, 2014

• Fixed a minor bug in the 0.6.0 critical bugfix. Probably not exploitable, but doesn't hurt to upgrade.
• Backported some minor optimizations from 0.7.0.
• Better handling of malformed peer announced addresses.

Version 0.6.0

February 5, 2014

• The critical bugfix will still be disclosed later. This is only to document the other changes from 0.5.12 to 0.6.0, as there are plenty of them.
• The 0.5.x branch is really painful for me to work with, after getting used to the fully refactored code in 0.6.x and 0.7.x. Therefore, I decided to stop maintaining 0.5.x completely and move on to 0.6.x.
• The last bugfix in 0.5.12 was not sufficient, and all forging users should upgrade to 0.6.0 as soon as possible. 0.5.12 is broken and will not be fixed.
• The 0.6.x branch still uses serialized object files, however those are not backwards compatible with 0.5.x. Old blocks.nxt and transactions.nxt files from 0.5.x will be imported automatically and converted to the new format the first time 0.6.0 is run.
• The blockchainStoragePath parameter in web.xml is no longer needed.
• The code has been significantly refactored and is no longer a single java file. All classes previously nested in Nxt have been moved out to their own files.
• Everything is under a top level nxt package, and as a result the servlet-class parameter in web.xml has to be changed to nxt.Nxt. Sorry that I forgot to mention that when releasing 0.6.0:
  
  <servlet-name>Nxt</servlet-name>
<servlet-class>nxt.Nxt</servlet-class>
  
  
• There are three subpackages, nxt.user, nxt.peer, and nxt.http, with request handlers in separate classes for all the UI, peer to peer, and http API requests respectively. This completely replaces the old huge switch/case statements in the servlet doGet and doPost methods.
• All the business logic has been moved out of the Nxt servlet class.
• A new Transaction.Type class hierarchy has been added to handle all logic for transaction validation, transaction attachment handling, and transaction application. This completely replaces the switch statements that used to hold the transaction validation and processing logic.
• Transaction undo, on block pop-off, has been implemented for transactions which can be undone. For all others, an UndoNotSupportedException triggers a full blockchain rescan.
• A custom NxtException exception hierarchy is now used to help with block and transaction validation. Most transaction and block parameters are now enforced to be valid in the Transaction and Block constructors, which makes it sort of difficult to forget to validate them.
• Many minor and not so minor performance and memory optimizations, based on actual profiling measurements, have been applied.
• All field and method access modifiers have been reviewed. No java field or method is more accessible than it needs to be. Everything that can be private, is now private. Everything that should be final, is now final.
• All JSON response and error handling has been cleaned up and optimized.
• Unnecessary to and from ByteBuffer conversions in block and transaction processing have been removed.
• A deadline limit of not more than 1440 minutes for new transactions is now enforced.
• Peers that submit invalid block or transaction data are automatically blacklisted.
• Java API documentation is now available at http://localhost:7874/doc/ , all APIs are subject to change as it is work in progress.
• Minor UI changes: added warnings to the unlock account dialog and message.html, added sendMoney to admin.html.
• New or improved APIs:
  • getAccount
    • parameter: account (the account id)
    • returns: publicKey (if known), balance, effectiveBalance, all asset balances
  • getAsset
    • parameter: asset (the asset id)
    • returns: accountId of the asset issuer, asset name, description and quantity
  • getAssetIds
    • returns: all existing asset id's.
  • getAskOrderIds and getBidOrderIds now require an asset parameter, and return the order id's for that asset only.

Version 0.5.12

February 5, 2014

• Fixed a critical bug. Everybody should upgrade immediately.

Version 0.5.11

January 30, 2014

• Fixed performance problems in getState, getEffectiveBalance and getGuaranteedBalance. The getGuaranteedBalance calculation now uses a different algorithm and may in some cases give different results than the 0.5.10 guaranteedBalance calculation which had some bugs, so it is advisable that everyone upgrades to 0.5.11 to avoid the risk of a fork.
• Fixed a bug with setting the public keys of accounts that forged blocks without having any outgoing transactions.

Version 0.5.10

January 23, 2014

• This is a bugfix release. All users of 0.5.9 and earlier should upgrade.
• Fixed a bug in Transparent Forging. The fix will take effect at block 51000. Users who don't upgrade by this block will be left out on a fork.
• Fixed a minor bug in peer weight calculation.
• Progress report:
  • The refactoring of 0.6.0 is going well. The Nxt project now consists of 86 java files instead of 1. The devs will proceed to work on persisting blocks and transactions in a database some time next week. They do not plan to release 0.6.0 until absolutely necessary, because it does not contain any new user visible features and at this point is likely less stable than the 0.5.x series. Urgent bugfixes and new API's, if needed, will still be added to 0.5.x. Any Nxt clone projects that have been eagerly awaiting the 0.6.x series, so that they can benefit from my refactoring work for free, will have to continue waiting, while the devs make progress.

Version 0.5.9

January 19, 2014

• Resolved all remaining thread concurrency issues in the block and transaction handling. All reported null pointer exceptions, division by zero, and related bugs should not happen anymore. If you see any errors in the log at all, please report them in our bug database: https://bitbucket.org/JeanLucPicard/nxt-public/issues
• Added Asset Exchange related APIs: getAskOrder, getAskOrderIds, getBidOrder, getBidOrderIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds.
• Prevent the Recent Blocks tab in the browser UI from growing beyond 60 blocks. This should help avoid browser slowdown and freeze during downloading of the whole blockchain from scratch.
• Added transaction re-broadcasting. To make sure a new transaction has been received by the network, it is broadcasted every minute, until it shows in the list of unconfirmed or confirmed transactions.
• The debug logs are quiet now, in fact I haven't seen any exceptions in the last 24 h of testing this release. Everybody should give it a try as I hope this is a really stable release. In particular, peers still running the buggy 0.5.7 will get blacklisted if they don't upgrade, because they keep broadcasting malformed JSON blocks and will be treated as zombies.

Version 0.5.8

January 16, 2014

• Fixed a thread concurrency issue which is the likely cause of the OutOfMemory errors some have experienced. This is a critical bugfix, Users of 0.5.7 should upgrade to 0.5.8.
• Added "type" and "subtype" filters to getAccountTransactionsIds API.

Version 0.5.7

January 15, 2014

• After the optimizations in memory and CPU usage, this release is about optimizing the networking. Instead of sending to all peers, data are pushed to only 10 peers by default. The number is configurable in web.xml, the sendToPeersLimit parameter. This should reduce the network traffic, and should also significantly reduce the waiting time the user experiences when sending out a transaction. Furthermore, sends are now done in parallel, using a pool of 10 threads, which means slow peers will not delay the sending to the rest.
• A few of the exceptions found from the debug output have been fixed, and some more networking exceptions known to be harmless will now be ignored. The logs are much more quiet now even with debug enabled, so I have decided to enable the nxt.debug parameter by default in nxt.ini.
• Transparent Forging phase 2 starts at block 47000. Everybody should update to at least 0.5.7 before this block is reached, otherwise we may see forks.
• Added Wesley's send message tool, message.html.

Version 0.5.6e

January 13, 2014

• Cleaned up error logging and exception handling. There are now two system properties that can be set to enable additional debug logging: nxt.debug and nxt.enableStackTraces. Those are defined in start.d/nxt.ini:
  
  # Enable debug messages
#-Dnxt.debug

# Also enable exception stack traces
-Dnxt.enableStackTraces

# Disable all jetty warnings and info
-Dorg.eclipse.jetty.LEVEL=OFF
• By default, nxt.debug is disabled. If you watch your log, please do enable debug output by uncommenting the -Dnxt.debug line in nxt.ini, and report any bugs using our JIRA issue tracker at Bitbucket:
  https://bitbucket.org/JeanLucPicard/nxt-public/issues
  Please avoid submitting duplicate issues, check if a very similar bug has already been reported first.
• The nxt.enableStackTraces parameter activates printing out exception stack traces in the log, independently of the nxt.debug setting, you should leave it turned on.
• With nxt.debug commented out, Nxt will still print some messages to the log, but much fewer. If there is a critical exception, it will be logged even if nxt.debug is not enabled.
• The noisy Jetty logging of warnings is disabled and the log should be much cleaner now. If you enjoy seeing the Jetty warnings, comment out the -Dorg.eclipse.jetty.LEVEL=OFF line in start.d/nxt.ini, but don't report those as bugs.
• The reason this release is considered experimental is that I have upgraded Jetty from 9.1.0 to 9.1.1.v20140108. People are encouraged to try it to see if there are any incompatibilities with different systems and Java versions.

Version 0.5.5

January 11, 2014

• Added getGuaranteedBalance API call:
  
  http://localhost:7874/nxt?requestType=getGuaranteedBalance&account=account&numberOfConfirmations=numberOfConfirmations
  
  returns the balance of an account only considering transactions with confirmation count >= numberOfConfirmations.
• The API requests getAccountBlockIds and getAccountTransactionIds now return sorted results.
• Added getAccountPublicKey and getGuaranteedBalance to admin.html page.
• More performance optimizations.

Version 0.5.4e

January 10, 2014

• Added Arbitrary Messages code, to be enabled at block 40000.
• New API requests added:
  • getAliasId
    http://localhost:7874/nxt?requestType=getAliasId&alias=alias
    returns the id of the alias given alias name
  • getAccountBlockIds
    http://localhost:/7874/nxt?requestType=getAccountBlockIds&account=account&timestamp=timestamp
    returns the blockIds generated by the account after timestamp
  • getState will now also return cumulativeDifficulty and totalEffectiveBalance. This allows the chance of an account to forge a block to be calculated by the user as myEffectiveBalance/totalEffectiveBalance.
• Significant memory consumption and performance optimizations to reduce the load on the GC and the total memory requirements. It should be possible to run with -Xmx512M if needed, more is better but should not be necessary. I hope Raspberry users will be happy with this release.
• This is experimental because of the multiple memory related optimizations, but should perform better than 0.5.3.

Version 0.5.3

January 8, 2014

• Fixed blockchain rescanning. Clear unconfirmed transactions on rescan.
• Better recipient account number validation. Do not accepts account numbers that overflow or negative account numbers. Should prevent at least some cases of transactions being sent to wrong recipients due to user error.

Version 0.5.2

January 7, 2014

• Added validation of numberOfTransactions and payloadLength to prevent

OutOfMemory attacks.

Version 0.5.1

January 7, 2014

• Possible fix for https://bitcointalk.org/index.php?topic=397183.msg4343616#msg4343616; needs more testing. Please report any occurences of negative Recent blocks and balances, and include the log errors if that happens.
• Fixed blacklisting of hallmarked peers.
• Accounts with negative balances can't forge.
• Improved account public key verification.
• Updated update.html to the newest version and changed download url.
• Fixed missing transaction id's in My Transactions.

Version 0.5.0

This is to be considered stable release. Change log:

• Fixed more concurrency issues, performance optimizations and code cleanup. I have fixed all the visible code issues that I consider to be bugs, the remaining TODO's on my list are a matter of code cleanup and refactoring.
• Added a checkpoint at block 30000 (the start of transparent forging block).
• Added wesleyh's update checker: https://bitcointalk.org/index.php?topic=345619.msg4294180#msg4294180
  • Use https://localhost:7875/update.html to check for updates - this feature may still have bugs, but including it in the package is a good way to get people to test it on multiple browsers.
• Devs have not been able to find any possible cause yet for the most critical bug reported so far, transactions being sent to a recipient different than the one selected. I have read through the relevant code again, but don't see any obvious way how this could happen. I am not ignoring those reports and believe it may be a real bug and not a user error, but without a way to reproduce the problem, it is very hard to track it down.

Version 0.4.9e

This is to be considered EXPERIMENTAL release. There are quite a few changes so be careful. Stay with the stable 0.4.8 version if you don't want to take chances. But our flagship NCC-1701-D has been running 0.4.9e since yesterday without issues.

• Many concurrency related fixes and optimization. Those should significantly improve performance and stability and decrease the likelihood of the client being stuck and needing a restart.
• Performance optimizations, reducing the number of temporary objects being created in the peer networking, making sure connections are properly closed. Memory requirements are lower now, my servers never exceed 1.5 GB. You should be able to run it on a 2 GB VPS node with Xmx1536M without problems now. If you don't attract a lot of traffic (don't publish your IP), memory will even stay below 1GB.
• Unlocking an account now makes sure to automatically lock out all other instances of the same account on the same server. In other words, if you open several browser windows to the same server (localhost), you can only be logged in to the same account in one of them at a time. This does not prevent you however from unlocking the same account on multiple machines (but you shouldn't be doing that).
• Generate authorization token will also ask for a secret phrase confirmation again.
• As you may or may have not noticed, Transparent Forging has already started. My last minute decision to start at 32000 somehow didn't make it in the package I released as 0.4.8 (I make mistakes too), so 0.4.8 got released with the switchover still at 30000. So block 30000 it is now, and we are already there.
• Minor changes: Added Get Account Aliases, Get Alias URI, and Get Multiple Account Balances features to the https://localhost:7875/admin.html page. Added a few more well-known nodes to the default in the web.xml.
• There is one serious security issue which is not completely fixed in 0.4.9e. All requests URLs are being cached by the browser, and even though they don't appear in the browsing history (which is why we didn't discover the problem earlier), they are still in the browser cache. Check for yourself using about:cache on firefox.
• This is bad, as it means your secret phrase is being written out to disk as plain text in the browser cache. And I am sure javascript exploits will appear which will try to extract it from there. To really fix that, all API requests from the browser that include the secret phrase have to be sent as POST, rather than GET requests. But this will require some significant changes to the javascript client, which will take some time. As we don't plan to maintain the current javascript client, I am not sure if such rewriting should even be undertaken now. In 0.4.9e I at least added the response headers which prevent caching to disk. Firefox honors those, but still caches the request URLs to memory. To be safe, I strongly suggest using a separate browser profile only for accessing your Nxt client, or private browsing mode. Everybody using 0.4.8 and earlier should immediately delete their browser cache.

Version 0.4.8

• Added Transparent Forging, will be turned on at block 30000.
• Memory leak fixed.
• Send money from the browser now also asks for the secret phrase.
• There is only one new parameter in the web.xml, myPlatform. It is used to announce your platform - PC, Mac, Raspberry, NeXTstation, VAX, zombie...
• as of this version, the zip file does not contain blocks.nxt and transactions.nxt. Make sure you preserve your own *.nxt files before upgrading!

Version 0.4.7e (source code release version)

• The Alias System is not included in the source, as it is an advanced feature.
• The Transparent Forging is also not included, as it was released in 0.4.8 only. Therefore, clients compiled from this source will only be able to reach up to block 30000 on the current blockchain.
• All my memory leak fixes and performance optimizations that went into 0.4.8 and 0.4.9e are also not included.
• For reference only, the downloads section contains the compiled 0.4.7e binary package as originally released. The json-simple and jetty libraries in it will be needed to be able to compile the Nxt.java source. As explained above, this binary package is out of date and will not work against the current blockchain beyond block 30000.

Version 0.4.6

• Only difference from 0.4.5 is content of blockchain files

Version 0.4.5

• Fast fix of the overflow bug.

Version 0.4.4

• Added Jetty DoSFilter (thx to Edward Elric)
• Added myScheme, myPort and shareMyAddress parameters (set them to appropriate values, they will be used in next version)
• Added enableHallmarkProtection, set it to "false" if you wish to switch the protection off blacklistingPeriod is set in milliseconds instead of seconds
• logPeerCommunication replaced with communicationLoggingMask (1 - log exceptions, 2 - log responses with non-200 HTTP response codes, 4 - log responses with 200 HTTP response codes), mask values can be combined in standard way
• Block feeding chunks increased from 128 KiB to 1 MiB.

Version 0.4.2

• Added http://localhost:7874/nxt?requestType=listAccountAliases&account=15436509232181115695
• Added http://localhost:7874/nxt?requestType=getAccountPublicKey&account=15436509232181115695

Version 0.4.1e

• Added support for CORS
• JS-scripts can replace Nxt aliases with corresponding URIs by using XMLHttpRequest and document.links
• Optimized transaction picking algo. Blocks will be filled at max capacity, previous algo didn't pick low-fee transactions to fill small gaps.

Version 0.4.0

• Added Alias System that will be activated after block 22000
• Added https://localhost:7875/alias.html to make it easier to assign aliases
• Added connectTimeout and readTimeout parameters to tweak outbound requests
• Added https://localhost:7875/nxt?requestType=getAccountId&secretPhrase=123
• Added http://localhost:7874/nxt?requestType=getAccountTransactionIds&account=23847569283756&timestamp=0

Version 0.3.20

• Added http://localhost:7874/nxt?requestType=getAccountId&secretPhrase=123
• Changed "sendMoney" API call (now it returns transaction bytes as well)
• Fixed "unconfirmedBalance" issue for transactions lost in limbo.
• Fixed "getBalance" API call for the genesis block account , now total supply of NXTs can be determined by invoking http://localhost:7874/nxt?requestType=getBalance&account=1739068987193023818 (someone should tell this to the coinmarketcap owner)
• Added http://localhost:7874/admin.html developed by Jean-Luc
• Added "pushThreshold" and "pullThreshold" parameters in web.xml, they are used to determine min allowed weight for peers to send/receive data to/from (if you send a lot of payments you should set pushThreshold to 1 or higher, but this increases chance that transactions won't be seen by most of peers)
• Removed peers.nxt file to fit BCNext's security standards

Version 0.3.19e

• Added "peerScheme" and "peerPort" in web.xml. This is for migration to HTTPS and different ports.
• Added "maxNumberOfConnectedPublicPeers" in web.xml. Your node will keep connecting to public peers until this number is reached. Previous version does it until total number of public and private peers < 100.
• Removed code related to Colored Coins (to prepare source code for review). Now you don't have to copy so many .class files.
• Made an attempt to fix blockchain downloading issue related to stuck "Catching up..." message. I removed it from .html files completely, so you won't see it anymore... It's a joke, I also changed a few lines of server code. Now blocks are downloaded faster (2 mins vs 30 mins in previous version) and you don't need to lock/unlock account to unfreeze Recent blocks widget (I hope). I wasn't able to check how the changes handle blockchain reorgs when orphaned blocks appear, that's why this version is experimental. If you can, please, install it and report if you see at least one orphaned block or the blockchain stops growing.

Version 0.3.18

December 11, 2013

• Enabled hallmark protection for outbound requests
• Added code for migration to non-standard ports for peer communication
• Added code for migration to other blockchain file format (check "blockchainStoragePath" in web.xml, you can use absolute paths)
• Added http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds
• If you announce address of your host via "myAddress" you must set it to your "host" value. In one of the next versions, nodes will begin checking to see that it matches the address returned by http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
• More info about the hallmark protection
  • Now marked hosts will attract more traffic. There are 2 types of outbound requests - Send (for getting unknown unconfirmed transactions, for blockchain downloading) and SendToAll (for pushing blocks and transactions). Send picks one of the connected peers depending on their weight (weighted random hit is made), peers with weight = 0 are considered as having weight = 1. SendToAll sends data to peers according to their weights in descending order.

Version 0.3.17

December 10, 2013

• Removed accounts.nxt, the data are generated on the fly. If you see incorrect balance then rerun the client (but still report this bug, I can't reproduce it).
• Enabled blacklisting, now it uses "blacklistingPeriod" (in seconds) in web.xml to automatically "unblacklist" nodes.
• Added http://localhost:7874/nxt?requestType=getPeers to list all peers. Details of a peer can be obtained via http://localhost:7874/nxt?* requestType=getPeer&peer=88.198.210.245.
• Trash icon now works for remote users if allowedUserHosts is set to anything except "*".

Version 0.3.16

December 8, 2013

• Enabled "allowedUserHosts"
• Added "logPeerCommunication" in web.xml
• Added http://localhost:7874/nxt?requestType=getPeer&peer=88.198.210.245 to get peer info
• Added http://localhost:7874/nxt?requestType=getConstants to get peer state values with description
• Disabled blacklisting (to test changes in peer picking mechanism)
• Added peer weight visualization

Version 0.3.15

December 7, 2013

• The list of well-known peers is not hardcoded in 0.3.15. Look at "wellKnownPeers" in nxt/webapps/root/WEB-INF/web.xml. Feel free to change it.
• Added "myHallmark" in web.xml. If you are an owner of non-trivial amounts in NXT you should run your own node(s) accessible on the Internet to protect the network. Hallmark is used to mark such nodes

Version 0.3.14

December 6, 2013

• Fixed Opera rounding issue

Version 0.3.13

December 5, 2013

• Added warning for secret phrases < 30 symbols.
• Added extra transaction validation (@hacker: attempt your trick again)

Version 0.3.12

December 5, 2013

• Upgrade only if you have 0.3.11 installed and want to generate blocks. Contains a quick work-around against unconfirmed double-spending transactions.

Version 0.3.11

December 5, 2013

• Enabled "sendMoney" API request.
• Fixed expired unconfirmed transactions issue (@anonymousHacker: check it plz).
• Fixed some issues related to memory leaks.

Version 0.3.10

December 4, 2013

• API now available on 7874 (http) and 7875 (https) ports.
• API request format changed from localhost:7876/?request=XXX to localhost:7874/nxt?requestType=XXX
• 2 parameters in web.xml added:
  • "allowedUserHosts" (not enabled yet) and "allowedBotHosts". An example of "allowedBotHosts" value - "*" for all hosts or "173.194.70.102; 204.79.197.200" for some of them.
• As a quick trick web interface can be "disabled" by deleting all *.html files in "nxt/webapps/root" directory.

Version 0.3.8

December 4, 2013

• Rewritten web interface networking.
• Now HTTP & HTTPS can be used (http://localhost:7874 & https://localhost:7875). The latter is preferable if you use "online" wallet. Browsers will show warning coz TLS certificate is self-signed, try to add it into the certificate vault to get rid of the warning.

Version 0.3.6

December 3, 2013

• Added blacklisting and some interface changes.
• There is a little bug in the interface, sometimes it's not refreshed, use F5. Unfortunately, I can't fix it now, someone crashed my node using Jetty vulnerability. I'm going to solve the Jetty issue first.

Version 0.3.5

December 3, 2013

• Reduced peer timeout from 10 to 2 seconds. This is a work-around for missing blacklisting.

Version 0.3.4

December 3, 2013

• Update if you see a lot of unconfirmed transactions.
• An anonymous hacker did us a favor and spammed with double-spending transactions. New version has a quick work-around to get rid of such transactions. Luckily block validation code was OK and didn't let to include blocks with double-spending transactions into the chain.

Version 0.2.20

December 1, 2013

• Contains only a quick fix proposed by Come-from-Beyond.

Version 0.2.19

November 30, 2013

• Interface fix for very long peer address.

Version 0.2.18

November 30, 2013

• Changed direct buffer allocation mechanism for peers and API bots

Version 0.2.17

November 29, 2013

• Some minor changes in interface, now you can see transaction ids. Install it if you have disappearing transactions issue.

Version 0.2.16

November 28, 2013

• For developers only.

Version 0.2.15

November 28, 2013

• Two API requests were added

Version 0.2.13

November 28, 2013

• Minor changes related to *.nxt files corruption.

Version 0.2.12

November 27, 2013

• Should fix stalled "Catching up..."
• If it still stalls then remove all Active peers one by one, after removing the one you were downloading the blockchain from, it should continue bootstrapping from other peer.

Version 0.2.10

November 26, 2013

Version 0.2.9

November 25, 2013

• Mandatory for everyone who stuck on 303th block.

Versions 0.2.8 through 0.2.3

November 25, 2013

Version 0.2.1

November 24, 2013 {{#css: .mw-headline-number { display: none; } }}