Nxt Client (NRS) 1.7.4
The NRS 1.7.4 hardfork is coming!
IMMEDIATELY UPDATE YOUR NODE or you WILL be left on a fork!
The long awaited hardfork which is programmed into the Nxt Reference Software 1.4.7 is finally approaching with block 621000, estimated to occur around January 21, 2016, at which new Nxt features will be enabled.
Download the NRS 1.7.4 release here:
Digital signature: "Stichting NXT"
.sh Sha256: bf135f9d7280860b59fb69d4753e436ed23ebbcf95e1e4112cb707c7a64a20b4 nxt-client-1.9.2.sh
1.9.2 .zip sha256: 4fe0520e5b4d0fe244dc9d8ab7943c1a107a7e4227ce4ae9f3236ae1dcc1a8ab nxt-client-1.9.2.zip
Incompatible API changes
Incompatible API changes were introduced in the 1.6 series. API users still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs and forum announcements, before upgrading to 1.7. These changes do not affect regular end users who just run the NRS client on their desktop or VPS node.
A detailed list of all affected APIs is posted at: https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199198/#msg199198, and the changes are also discussed in the 1.6.0e, 1.6.1e and 1.6.2 changelogs. Please do read the information in these changelogs.
Summary of the API changes
EvilDave / Nxt Foundation posted this summary of the changes:
1. A number of API calls, which in 1.5.15 and previous releases return additional information, at a performance cost, have had their defaults modified not to return those extra fields unless specifically requested. The format of the API response has not changed, only what fields are returned by default. If your code uses any of those APIs and in some invocations needs the additional fields, make sure to add the corresponding "include" parameters in those places.
2. The getAccountTransactions and getAccountTransactionIDs APIs, deprecated in 1.5 have been removed in 1.6. Use getBlockchainTransactions instead and make sure to handle correctly the phased transactions. Some enhancements to getBlockchainTransactions, such as being able to get only executed phased (or not phased) transactions, introduced in 1.6.1e, should make that easier.
3. Some APIs no longer do a detailed error checking of the user input. Any APIs that accept an object id such as account, asset, or currency, but do not need to retrieve the actual object, no longer check for its existence. Such APIs will now return an empty result list instead of an error, when supplied for example with non-existent asset id.
4. Asset transfers to the Genesis account are now treated as deletion of asset shares, and as such are not retrievable using the getAssetTransfers API. The quantityQNT in the asset JSON returned by APIs such as getAsset now corrects for such share deletion. The original asset quantity issued is returned as initialQuantityQNT in the asset JSON.
The above API incompatibilities must be taken care of on upgrade from 1.5.15 to 1.6.2. The 1.7 API will be consistent with 1.6.2 and will require no further adjustments.
Other than the API tweaks, there are two major changes to take effect in the 1.7 hardfork, that require taking action now and preparing in advance:
1. For virtually all transaction types in 1.7, fees charged will no longer be constant (currently 1 NXT), but based on the actual transaction size. As it is not possible to hardcode the logic for fee calculation in each client of the API, the approach suggested is to let the server determine and use the minimum fee required, which happens when a new transaction is submitted with feeNQT=0 parameter. This feature is fully supported in 1.6.2, and therefore a migration to using server-side calculated fees can be started now.
2. The maximum allowed size of permanent message attachments (plain or encrypted) has been significantly reduced, from 1000 bytes to 160 bytes. If you use permanent messages, regardless of the transaction type they are attached to, you need to make sure their size does not exceed 160 bytes. As fees for permanent messages have also been increased significantly and are proportional to the actual message size, it is strongly recommended to switch to using prunable messages instead. To create a message as prunable, the only change required is to add messageIsPrunable=true parameter to the corresponding transaction creation API call. The format of the transaction JSON is the same for permanent and prunable messages (this is why they can't both coexist in the same transaction), therefore no changes in parsing the JSON response are needed. Prunable messages are also deleted by default after 90 days. If your application needs to have them available longer, or indefinitely, this can be configured in the nxt.properties file, and it is also possible to automatically retrieve such expired prunable messages from archival nodes running on the Nxt network. Prunable messages have been supported since 1.5, and archival nodes are introduced in 1.6.2, so again the migration from permanent to prunable messages can be started now, without waiting for the 1.7 stable release.
Please see this forum thread for information and discussions regarding the transition to prunable messages and the fee calculation changes.
We have also set up a mailing list, to allow better direct communication with the Nxt dev team, so if you are responsible for an Nxt-based project, sign up here:
NRS 1.7.4 release notes
This is the first stable release in the 1.7 series. It is a mandatory update
for everyone. There is a hard fork scheduled for block 621000, estimated to occur around Jan 21, 2016, at which new features will be enabled. Nodes that do not update to 1.7.4 or later by this date will be left on a fork.
On testnet, the hard fork block is already passed, and all new features are fully functional.
There were incompatible API changes introduced in the 1.6 series. API users still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs and forum announcements, before upgrading to 1.7. These changes do not affect regular end users who just run the NRS client on their desktop or VPS node.
The new features and improvements in the 1.7 series have been documented in the 1.7.0e through 1.7.3e changelogs, available in the changelogs directory.
Here is a high level summary of the new features to be enabled after the
Coin Shuffling, a fully decentralized coin mixing, to improve account privacy.
Account Control for phased transactions, the Nxt equivalent of multisignature.
Immediate release of certain types of phased transactions on approval.
Improved block times, 60 s average, long block times now extremely unlikely.
Account Properties, assigning arbitrary name/value metadata to user accounts.
Singleton Assets, useful for representing single tradeable objects.
Dynamic fees, proportional to the relative transaction size.
Improved Exchange Booth UI.
Data Cloud, adding a UI and multiple enhancements to the existing Tagged Data feature, to allow decentralized, censorship-free and tamper-proof publication and retrieval of small files, documents, or arbitrary data. This feature is not dependent on the hard fork and will be fully usable immediately on update to this release.
Changes added since the 1.7.3e release:
Added detectMimeType utility API, allowing auto-detection of the mime type of uploaded file or data, using the Apache Tika library.
The uploadTaggedData API now uses such mime type auto-detection to determine the mime type of uploaded data when the user has not explicitly provided a type parameter. It also automatically sets the isText property to true for data of type text/plain only.
Made the maximum permitted number of forgers or shufflers running at the same time configurable, default 100 each, using the nxt.maxNumberOfForgers and nxt.maxNumberOfShufflers properties.
The default value of includeCounts parameter in the searchDGSGoods API is now also false, this API was inadvertently missed when globally changing the defaults to false in the 1.6 branch.
Various UI improvements.
Updated Bouncy Castle library to version 1.54.
The NRS (Nxt Reference Software) Client is the Nxt core developers’ official wallet release.
NRS is a locally hosted client server application. By default it downloads the Nxt blockchain, but from version 1.10.0e you can run it as a light client as well as a full node. To forge and earn forging fees from processing transactions on the network you must run the Nxt Client in full mode, which is possible even on small devices like laptops, or on a Raspberry Pi. There are also bounties for running public nodes.
The Nxt Client is easy to install. Use the 1-click installers for Linux, Mac and Windows or read this INSTALLATION GUIDE to launch the NRS .zip from terminal.
Managed the development and implementation of Nxt's visual brand in 2014, with web design bureau Ideenfrische.
Issued the NXTP asset in 2014, a profit sharing asset given to early contributors to Nxter.org that helped turn the site into a magazine, publishing news and articles in several languages, and running faucets, contests and social media campaigns for Nxt. ESMA based a report on Nxter.org's coverage of the Nxt AE in 2015.
Arthur is still one of the driving forces behind Nxter.org. He compiled the acclaimed book about Nxt 'SNAPSHOT', which got published in early 2017.
Latest posts by apenzl (see all)
- Nxter News – August 2018 (II): There Is Nothing Better Than A Friend, Unless It Is A Friend With Chocolate - 14/08/2018
- Nxter News – August 2018 (I): The Real Voyage Of Discovery Consists Not In Seeking New Landscapes, But In Having New Eyes - 07/08/2018
- Nxter News – July 2018 (V): All That Is Gold Does Not Glitter, Not All Those Who Wander Are Lost - 31/07/2018