Nxt Software Change Log/it

From Nxt Wiki
Jump to: navigation, search
This page is a translated version of the page Nxt Software Change Log and the translation is 18% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎русский • ‎українська

Contents

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

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

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

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

5 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%+).

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

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

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

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

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

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

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

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

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

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

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

17 Version 1.4.14

February 9, 2015

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

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

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

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

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

22 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

48 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).

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

50 Version 1.1.5

June 20, 2014

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

51 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).

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

53 Version 1.1.2

  • Avoid unnecessary fork processing resulting in too many scans.

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

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

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

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

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

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

60 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

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

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

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

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

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

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

67 Version 0.9.3.1e

April 09, 2014

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

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

69 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".

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

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

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

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

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

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

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

77 Versione 0.8.8 / 0.7.7

7 Marzo 2014

  • Risolto l'impostazione erronea del timestamp del blocco genesi legato all'ora legale. Questa deve essere la ragione che porta degli utenti dell'emisfero sud all'incapacità di forgiare.
  • Visto che l'ora legale negli US comincia il 9 Marzo, è di vitale importanza che quelli negli US aggiornino alla versione 0.8.8 o 0.7.7.
  • Non ci sono nuove funzionalità o correzioni rispetto alla versione 0.7.6 oltre a questi problemi legati all'ora legale.

78 Versione 0.8.7

6 Marzo 2014

  • Risolto il calcolo del bilancio non confermato per l'account del blocco genesi.
  • Risolto il problema legato a come viene mostrato il bilancio dell'account genesi nell'interfaccia di NRS.

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

80 Versione 0.8.5

4 Marzo 2014

  • Ulteriori bugfix legati al calcolo del bilancio non confermato.
  • Correzioni minori per evitare delle eccezioni innocue.

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

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

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

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

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

86 Versione 0.7.6

19 Febbraio 2014

  • Compatta il database ad ogni chiusura. Questo dovrebbe ridurre la grandezza della cartella nxt_db dopo il primo uso, controlla la grandezza prima e dopo l'uso.
  • Prevenire la presenza di doppioni nella lista dei nodi conosciuti e quelli nella blacklist.
  • Prevenire l'attacco potenziale di duplicazioni di chiavi, del tipo descritto qui: https://bitcointalk.org/index.php?topic=397183.msg4569817#msg4569817
  • Aggiunto il sistema di votazione, non ancora abilitato.
  • Refactoring delle classi Block e Transaction.
  • Bugfix dell'Asset exchange del test network e altre richieste API.
  • Migliorata la verifica delle transazioni per prevenire di aggiungere dei nodi alla blacklist erroneamente, e per meglio far rispettare la validità delle transazioni.

87 Versione 0.7.5

14 Febbraio 2014

  • Diversi miglioramenti sulle prestazioni e l'uso della memoria.
  • Migliorata la verifica degli indirizzi dei nodi e la gestione dei cambiamenti di stato nella connessione dei nodi.
  • Migliorie sull'interfaccia utilizzatore in relazione ai nodi.
  • Ulteriori ottimizzazioni di getMilestoneBlockIds, retro compatibile.
  • Ulteriori pulizie delle classi fondamentali da tutti i parametri legati all'UI.

88 Versione 0.7.4

13 Febbraio 2014

  • Un altro bugfix nella transizione al Transparent Forging, che comincia col blocco 67000. Aggiorna prima di questo blocco, se no ci sarà un fork.
  • Con questo rilascio viene terminato il supporto al protocollo getMilestoneBlockIds. I client più vecchi del 0.7.3 non saranno in grado di richiedere blocchi da nodi versione 0.7.4. Tutti devono in ogni caso aggiornare alla versione 0.7.4 prima del blocco 67000.
  • Alcune ottimizzazioni alle query del database durante lo sblocco dell'account, vediamo se aiuta gli utenti che usano un Raspberry.
  • Altri miglioramenti minori.

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

90 Versione 0.7.2

9 Febbraio 2014

  • Migliorata la performance dello scan della blockchain.

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

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

93 Versione 0.6.1

6 Febbraio 2014

  • Risolto un bug minore presente nel bugfix critico della versione 0.6.0. Probabilmente non può essere abusato, ma non costa niente aggiornare.
  • Ripreso delle ottimizzazioni minori dalla versione 0.7.0.
  • Migliore gestione degli indirizzi malformati annunciati dai nodi.

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

95 Versione 0.5.12

5 Febbraio 2014

  • Risolto un bug critico. Chiunque dovrebbe aggiornare immediatamente.

96 Versione 0.5.11

30 Gennaio 2014

  • Risolto problemi di performance legati a getState, getEffectiveBalance e getGuaranteedBalance. Il calcolo di getGuaranteedBalance utilizza ora un algoritmo diverso e può in certi casi dare un risultato diverso dal guaranteedBalance della versione 0.5.10 che aveva certi bug, quindi è consigliato che chiunque aggiorni alla versione 0.5.11 per evitare rischi di fork.
  • Risolto il bug di impostare la chiave pubblica di account che hanno forgiato blocchi senza avere transazioni in uscita.

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

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

99 Versione 0.5.8

16 Gennaio 2014

  • Risolto il problema legato ai thread in parallelo che probabilmente causa gli errori OutOfMemory che alcuni hanno riscontrato. Questo è un bugfix critico, gli utenti aventi la versione 0.5.7 devono aggiornare alla 0.5.8.
  • Aggiunto i filtri "type" e "subtype" all'API getAccountTransactionsIds.

100 Versione 0.5.7

15 Gennaio 2014

  • Dopo le ottimizzazioni alla memoria e all'uso della CPU, questo rilascio ottimizza le connessioni di rete. Invece d'inviare i dati a tutti i nodi, vengono spediti di default solo a 10.

Il numero è configurabile in web.xml, il parametro sendToPeersLimit. Questo dovrebbe ridurre il traffico e dovrebbe altrettanto ridurre il tempo di attesa durante l'invio di una transazione. In più, l'invio è fatto ora in parallelo, usando 10 threads, questo significa che i nodi più lenti non ritardano l'invio ad altri.

  • Alcune delle eccezioni scoperte sono ora risolte, ed altre in relazione alla rete che sono considerate innocue saranno ignorate. Il log è ora molto più tranquillo pur avendo debug attivato, quindi ho deciso di attivare il parametro nxt.debug di default in nxt.ini.
  • La seconda fase del Transparent Forging comincia col blocco 47000. Tutti devono aggiornare almeno alla versione 0.5.7 prima che questo blocco sia raggiunto, se no ci si può aspettare diversi fork.
  • Aggiunto lo strumento di Wesley per l'invio di messaggi, message.html.

101 Versione 0.5.6e

13 Gennaio 2014

  • Ripulito il logging degli errori e la gestione delle eccezioni. Vi sono ora due impostazioni di sistema che possono essere attivate per logging addizionale: nxt.debug e nxt.enableStackTraces. Questi sono definiti 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
  • Di default, nxt.debug è disabilitato. Se dai un'occhiata al log, per favore abilita questo output rimuovendo il commento dalla linea -Dnxt.debug in nxt.ini e facci sapere se ci sono problemi usando JIRA issue tracker su Bitbucket:
    https://bitbucket.org/JeanLucPicard/nxt-public/issues
    Per favore evita d'inviarci dei doppioni, controlla prima se un bug molto simile non sia già stato inviato.
  • Il parametro nxt.enableStackTraces mostra le eccezioni della stack nel log, indipendentemente dall'impostazione nxt.debug dovresti lasciare questa attivata.
  • Con nxt.debug commentato, Nxt mostrerà comunque dei messaggi di log, ma molti meno. Se vi è un'eccezione critica, sarà registrata anche se nxt.debug non è attivo.
  • Gli avvertimenti di Jetty sono disabilitati e il log dovrebbe essere molto più pulito ora. Se ti piace vederli, commenta la linea -Dorg.eclipse.jetty.LEVEL=OFF nel file start.d/nxt.ini ma non spedirceli come bug.
  • La ragione per cui questa versione è considerata sperimentale è che ho aggiornato jetty dalla versione 9.1.0 alla 9.1.1.v20140108. Vi incoraggio a testare se vi siano delle incompatibilità con altri sistemi e versioni di Java.

102 Version 0.5.5

January 11, 2014

103 Versione 0.5.4e

10 Gennaio 2014

  • Aggiunto il codice per Arbitrary Messages, viene abilitato con il blocco 40000.
  • Nuove richieste API aggiunte:
  • Ottimizzazioni significative sulla performance e la consumazione di memoria per ridurre la carica sul GC e memoria totale richiesta. Dovrebbe essere possibile eseguire il client con -Xmx512M se necessario, più memoria è meglio ma non dovrebbe essere bisogno. Spero i possessori di Raspberry Pi ne siano felici.
  • Questa versione è sperimentale viste le ottimizzazioni in relazione alla memoria, ma dovrebbe funzionare meglio della 0.5.3

104 Versione 0.5.3

8 Gennaio 2014

  • Risolto il rescan della blockchain. Svuota le transazioni non confermate durante un rescan.
  • Migliore verifica dell'account ricevente. Non accetta numeri account che provocano un overflow o che sono negativi. Dovrebbe prevenire in parte alcuni casi in cui le transazioni vengono spedite alla persona sbagliata a causa di errori da parte dell'utilizzatore.

105 Versione 0.5.2

7 Gennaio 2014

  • Aggiunta la conferma di numberOfTransactions e payloadLength per prevenire attacchi OutOfMemory.

106 Versione 0.5.1

7 Gennaio 2014

  • Possibile risoluzione per https://bitcointalk.org/index.php?topic=397183.msg4343616#msg4343616; richiede test ulteriori. Per favore facci sapere se Recent blocks e balances appaiono negativi, e includi qualsiasi errore mostrato se ciò succede.
  • Risolto il problema dei nodi dotati di hallmark che finiscono nella blacklist.
  • Account aventi un bilancio negativo non possono forgiare.
  • Migliorata la verifica della chiave pubblica di un account.
  • Aggiornato update.html alla nuova versione e cambiato l'url di download.
  • Risolta la mancanza degli ID delle transazioni sotto My Transactions.

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

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

109 Versione 0.4.8

  • Aggiunto Transparent Forging, sarà attivo col blocco 30000.
  • Risolto problemi di memory leak.
  • Spedire nxt dal browser ora richiede nuovamente la passphrase.
  • Vi è un nuovo parametro nel file web.xml, myPlatform. Viene utilizzato per annunciare la tua piattaforma - PC, Mac, Raspberry, NeXTstation, VAX, zombie...
  • con questa versione, l'archivio .zip non contiene blocks.nxt e transactions.nxt. Assicurati di tenere i tuoi file *.nxt prima di fare l'aggiornamento!


110 Versione 0.4.7e (versione con rilascio del codice sorgente)

  • Il sistema Alias non è incluso nel codice sorgente, in quanto è una funzione avanzata.
  • Transparent Forging non è incluso, in quanto è stato rilasciato con la 0.4.8. Quindi i client compilati da questo codice sorgente potranno solamente raggiungere il blocco 30000 della blockchain.
  • Tutti i memory leak e ottimizzazioni di performance che sono stati apportati alla 0.4.8 e 0.4.9e non sono inclusi.
  • Come riferimento, la sezione di download contiene la versione compilata di 0.4.7e come rilasciato in origine. Il json-simple e le librerie jetty incluse saranno necessarie per poter compilare Nxt.java. Come spiegato sopra, questo pacchetto non è aggiornato e non funzionerà dopo il blocco 30000 della blockchain.

111 Versione 0.4.6

  • La sola differenza dal 0.4.5 è il contenuto dei file della blockchain

112 Versione 0.4.5

  • Risolto problema di overflow.

113 Versione 0.4.4

  • Aggiunto Jetty DoSFilter (grazie a Edward Elric)
  • Aggiunto i parametri myScheme, myPort e shareMyAddress (impostali in modo appropriato, saranno usati nella prossima versione)
  • Aggiunto enableHallmarkProtection, impostalo a "false" se desideri rimuovere la protezione
  • blacklistingPeriod è impostato in millisecondi invece che secondi
  • logPeerCommunication rimpiazzato con communicationLoggingMask (1 - log exceptions, 2 - log responses with non-200 HTTP response codes, 4 - log responses with 200 HTTP response codes), mask values possono essere combinate nel modo standard.
  • Block feeding chunks incrementato da 128 KiB a 1 MiB.

114 Versione 0.4.2

115 Versione 0.4.1e

  • Aggiunto il supporto a CORS (http://publicnxtnode.com:7874/nxt?requestType=getAliasURI&alias=Google solo la richiesta, abilitato come proof-of-concept)
  • JS-scripts possono rimpiazzare gli alias Nxt con il corrispondente URIs usando XMLHttpRequest e document.links
  • Ottimizzato l'algoritmo per la scelta delle transazioni. I blocchi saranno riempiti a capacità massima, l'algoritmo precedente non prendeva le transazioni aventi delle tasse basse per riempire gli spazi vuoti.

116 Versione 0.4.0

117 Versione 0.3.20

118 Versione 0.3.19e

  • Aggiunto "peerScheme" e "peerPort" in web.xml. Questo è per la migrazioni a HTTPS e porte diverse.
  • Aggiunto "maxNumberOfConnectedPublicPeers" su web.xml. Il tuo nodo continuerà a connettersi a nodi pubblici fino a che questo numero non è raggiunto. La versione precedente continua fino a che il numero di nodi pubblici e privati < 100.
  • Rimosso il codice in relazione ai Colored Coins (per preparare il codice sorgente ad essere controllato). Ora non devi più copiare così tanti file .class
  • Tentativo di risoluzione del problema dell'interruzione del download della blockchain e il conseguente messaggio "catching up...". L'ho rimosso dai file .html completamente, quindi non lo vedrai più... È uno scherzo, ho pure cambiato alcune linee del codice del server. Ora i blocchi sono scaricati più velocemente (2 minuti vs 30 minuti della versione precedente) e non devi più sbloccare/bloccare l'account per far funzionare il widget Recent Blocks (spero). Non ho avuto modo di controllare come il cambiamento gestisce la riorganizzazione della blockchain quando vi è un blocco orfano, per questa ragione questa versione è sperimentale. Se puoi, per favore installala e facci sapere se vedi almeno un blocco orfano o se la blockchain smette di crescere.

119 Versione 0.3.18

11 Dicembre 2013

  • Abilitato protezione hallmark per richieste in uscita.
  • Aggiunto codice per passaggio a porte non standard per la comunicazione dei nodi.
  • Aggiunto codice per il passaggio ad un altro formato della blockchain (vedi "blockchainStoragePath" sul file web.xml, puoi usare un path assoluto)
  • Aggiunto http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds
  • Se annunci l'indirizzo del tuo host via "myAddress" devi importarlo al valore di "host" ritornato da http://otherserver.com:7874/nxt?requestType=getMyInfo. Nelle prossime versioni i nodi cominceranno col controllare che questo ritorna l'indirizzo dato da http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
  • Ulteriori informazioni sulla protezione data da hallmark.
    • Gli host marcati attrarranno più traffico. Vi sono due tipi di richieste in uscita - Send (per ottenere transazioni sconosciute non confermate, per il download della blockchain) e SendToAll (per annunciare blocchi e transazioni). Send sceglie uno dei nodi in funzione del loro peso (scelta casuale ma proporzionale al peso), nodi con weight = 0 sono considerati come aventi un weight = 1. SendToAll invia le informazioni ai nodi in funzione del loro peso in ordine decrescente.

120 Versione 0.3.17

10 Dicembre 2013

  • Rimosso accounts.nxt, le informazioni sono generate in tempo reale. Se ottieni un bilancio errato rilancia il client (tuttavia faccelo sapere, non posso replicarlo).
  • Abilitato blacklisting, ora usa "blacklistingPeriod" (in secondi) su web.xml per rimuovere nodi dalla blacklist automaticamente.
  • Aggiunto http://localhost:7874/nxt?requestType=getPeers per ottenere una lista dei nodi. Dettagli su un nodo possono essere ottenuti attraverso http://localhost:7874/nxt?* requestType=getPeer&peer=88.198.210.245.
  • L'icona del cestino ora funziona per utenti remoti se allowedUserHosts è impostato con qualsiasi cosa eccetto "*".


121 Versione 0.3.16

8 Dicembre 2013

122 Versione 0.3.15

7 Dicembre 2013

  • La lista di nodi conosciuti non è più prestabilita nella versione 0.3.15. Dai un'occhiata a "wellKnownPeers" sotto nxt/webapps/root/WEB-INF/web.xml. Sentiti libero di cambiarlo.
  • Aggiunto "myHallmark" in web.xml. Se possiedi una quantità importante di NXT dovresti avere un nodo in esecuzione per proteggere il network. Hallmark è utilizzato per marcare tali nodi.

123 Versione 0.3.14

6 Dicembre 2013

  • Risolto problema di approssimazione con Opera.

124 Versione 0.3.13

5 Dicembre 2013

  • Aggiunto avvertimento per passphrase aventi meno di 30 simboli.
  • Aggiunto una validazione ulteriore per le transazioni (@hacker: tenta il tuo attacco nuovamente)

125 Versione 0.3.12

5 Dicembre 2013

  • Aggiorna solo se hai installato la versione 0.3.11 e vuoi generare blocchi. Contiene una correzione temporanea contro transazioni double-spending non confermate.

126 Versione 0.3.11

5 Dicembre 2013

  • Abilitato la richiesta API "sendMoney".
  • Risolto il problema delle transazioni scadute non confermate (@anonymousHacker: controllalo per favore).
  • Risolto alcuni casi di memory leak.

127 Versione 0.3.10

4 December 2013

  • API ora disponibile sulle porte 7874 (http) e 7875 (https).
  • Formato per la richiesta API modificato da localhost:7876/?request=XXX a localhost:7874/nxt?requestType=XXX
  • 2 parametri aggiunti a web.xml:
    • "allowedUserHosts" (non ancora abilitato) e "allowedBotHosts". Un esempio del valore di "allowedBotHosts" - "*" per tutti gli host oppure "173.194.70.102; 204.79.197.200" per alcuni in specifico.
  • Una scorciatoia per disabilitare l'interfaccia web consiste nell'eliminare tutti i file *.html nella cartella "nxt/webapps/root".

128 Versione 0.3.8

4 Dicembre 2013

  • Riscritto l'interfaccia web
  • Ora HTTP e HTTPS possono essere usati (http://localhost:7874 e https://localhost:7875). L'ultimo è da preferire se usi un portafoglio online. I browser mostreranno comunque un avvertimento in quanto il certificato è stato firmato da te, aggiungilo come eccezione per farlo sparire.

129 Version 0.3.6

3 Dicembre 2013

  • Aggiunto il blacklisting e alcuni cambiamenti all'interfaccia.
  • Vi è un problema con l'interfaccia, talvolta non viene aggiornata, usa F5. Sfortunatamente non posso risolverla ora, qualcuno ha crashato il mio nodo usando una vulnerabilità di Jetty. Innanzitutto risolverò il problema con Jetty.

130 Versione 0.3.5

3 Dicembre 2013

  • Ridotto il tempo di sospensione dei nodi da 10 a 2 secondi. Questo è un fix temporaneo in assenza del blacklisting.

131 Versione 0.3.4

3 Dicembre 2013

  • Aggiorna se vedi molte transazioni non confermate.
  • Un hacker anonimo ci ha fatto un favore e ha spammato con transazioni a doppia spesa. La nuova versione ha un fix temporaneo per sbarazzarsi di queste transazioni. Fortunatamente il codice per la validazione dei blocchi ha funzionato OK e non ha incluso blocchi con queste transazioni nella blockchain.

132 Versione 0.2.20

1 Dicembre 2013

  • Contiene solo un fix proposto da Come-from-Beyond.

133 Versione 0.2.19

30 Novembre 2013

  • Risolto problema con l'interfaccia per degli indirizzi dei nodi molto lunghi.

134 Versione 0.2.18

30 Novembre 2013

  • Cambiato il meccanismo di allocazione diretta dei buffer per nodi e bot API.

135 Versione 0.2.17

29 Novembre 2013

  • Cambiamenti minori dell'interfaccia, ora puoi vedere gli ID delle transazioni. Installalo se hai problemi con la scomparsa di transazioni.

136 Versione 0.2.16

28 Novembre 2013

  • Solo per sviluppatori.

137 Versione 0.2.15

28 Novembre 2013

  • Aggiunte due richieste API.

138 Versione 0.2.13

28 Novembre 2013

  • Modifiche minori in relazione alla corruzione dei file *.nxt.

139 Versione 0.2.12

27 Novembre 2013

  • Dovrebbe risolvere i "Catching up..."
  • Se si blocca ancora rimuovi tutti i nodi attivi, uno per uno, dopo aver rimosso quello da cui stavi scaricando la blockchain, dovrebbe continuare tramite gli altri nodi.

140 Versione 0.2.10

26 Novembre 2013

141 Versione 0.2.9

25 Novembre 2013

  • Obbligatorio per chiunque sia bloccato al blocco 303.

142 Versione 0.2.8 dalla 0.2.3

25 Novembre 2013

143 Versione 0.2.1

24 Novembre 2013