NRS 1.11.7 release notes

This release adds the ability to submit a JLRDA purchase transaction from the IGNIS Token Sale page even before the sell offer has been published.

Such transactions are not broadcasted immediately, but held in memory and only sent out when the expected sell offer arrives in the unconfirmed transaction pool.

For this to work, you must keep the node running after submitting the purchase transaction, until the sell offer has been received and processed.

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

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

More IGNIS Token Sale UI bugfixes and improvements:

Add paging buttons to the exchange history table on the Ignis page.

Initialize the JLRDA units field to 0.

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

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

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

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

Other fixes and improvements:

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

Fixed printing of paper wallet for passphrases containing special characters.

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

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

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

FAQ

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.

The Nxt Client is easy to install. Use the 1-click installers for Linux, Mac and Windows or read this INSTALLATION GUIDEto launch the NRS .zip from terminal.

ICO Release FAQ

Q: What's the priority to execute these buy orders when they will hit blockchain? Same as usual?

A: As soon as the node scheduler storing the scheduled transactions sees the exchange offer as an unconfirmed transaction, it will immediately broadcast your currency buy transactions.

And they will compete with the rest of the transaction for inclusion in the next block, according to the usual transaction priority.

Q: So, if I understand correctly, this new stuff is for users to make buy transaction in advance, instead of lurking near PC and try to be fast?

A: Exactly

Q: And if my advanced buy order is not filled, I need to repeat the same before the next batch? Am I right, this new stuff do not solve MAAC problem?

A: It does solve it, since MAAC found a way to submit his transaction while the Jelurida exchange offer was still unconfirmed and invisible to the UI.

With 1.11.7, every scheduled transaction will do exactly that.

Q: When does Jelurida exchange offers become valid? Only when approved or broadcasted?

A: When the Jelurida exchange offer is still unconfirmed the scheduler will submit the buy orders

Q: Will not wait for approval of it?

A: They will all approve in the same block, the exchange offer will have the earliest arrival time so the currency buy transactions will match it in the same block just like MAAC did it manually

Q: But looking at history, approval account approves exchange offer few block later. I feel some confusion here. Always thought, that without approval any transaction is not "valid".

A: The exchange offer will no longer be phased, just a regular transaction

Q: And if my scheduled buy order is not filled, I need to repeat the same order before the next batch?

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 GUIDEto launch the NRS .zip from terminal.

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 GUIDEto launch the NRS .zip from terminal.

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 GUIDEto launch the NRS .zip from terminal.

ARDR Snapshots

Snapshotting will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12). Relevant reading: Ardor distribution

To get your ARDR tokens, it is recommended that you keep your NXT balance in your own account.

For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

The 3 major exchanges for NXT;Poloniex, BTC38, andBittrex will all run internal snapshots of their customers' NXT balances synchronized with the main blockchain. The Ardor tokens will then be distributed to their rightful owners at a ratio of 1 Ardor token for 1 NXT. The exchanges are prepared for new customers outside the Fintech and investment world looking to purchase Nxt tokens for future Ardor tokens with the introduction of fiat currency exchange. Retail customers will now be able to access the Ardor platform and purchase tokens using fiat currency.

NRS 1.9.2 release notes

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

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 GUIDEto launch the NRS .zip from terminal.

The 3 major exchanges for NXT;Poloniex, BTC38, andBittrex will all run internal snapshots of their customers' NXT balances synchronized with the main blockchain. The Ardor tokens will then be distributed to their rightful owners at a ratio of 1 Ardor token for 1 NXT. The exchanges are prepared for new customers outside the Fintech and investment world looking to purchase Nxt tokens for future Ardor tokens with the introduction of fiat currency exchange. Retail customers will now be able to access the Ardor platform and purchase tokens using fiat currency.

NRS 1.9.0e release notes

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

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

On testnet, the snapshot will start at block 649400 and end at block 779000 (June 24).

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

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

To get your ARDR tokens, it is essential that you keep your NXT balance in your own account. There is no need to run a node or forge. It is the confirmed NXT balance that is used for the snapshot, not the unconfirmed (available) balance, so having some NXT locked in open AE bid orders, shufflings, etc, will not affect your ARDR distribution.

For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

A new getFxtQuantity API has been added, which allows retrieving the already accumulated ARDR quantity for each account during the snapshot, and an estimate for the quantity yet to be obtained. While snapshots are done every 60 blocks, the numbers that this API returns are updated once every 720 blocks only.

Snapshot balances used for the ARDR distribution for a specific account can be recorded in the log by setting the nxt.logFxtBalance property to that account number, and performing a rescan if the snapshot has already started.

Added some additional transaction bytes validation, and phasing parameters validation, to take effect after the hardfork.

Added getAssetDividends API, to retrieve the dividend payment history for an asset. It can be viewed in the client by clicking on the new "View Asset Dividends" link on the asset exchange page. Dividend payments made before a node is updated to 1.9.0e will not show in this history, unless a blockchain rescan is forced manually.

After the hardfork block, asset dividend payment transactions will be limited to not more than one per asset every 60 blocks.

Added a new Messages table in the client UI. Allowed uploading a file as a message attachment, plain or encrypted, and downloading such messages as files.

All create transaction APIs that support prunable message attachments now also optionally accept multipart file uploads as messageFile or messageToEncryptFile parameters, or when using client-side encrypted data the data part can also be uploaded using encryptedMessageFile parameter. As the test API page does not support multiple file upload parameters, upload buttons for those are not currently available there.

Added client UI support for decrypting messages using a shared key, to allow disclosing the shared key for a specific encrypted message to a third party in order to decrypt it without having to reveal the account passphrase.

Forging optimization to reduce block skipping when switching forks.

Minor other bugfixes and UI improvements.

Updated H2 library to version 1.4.192, tika to 1.13, and slf4j to 1.7.21. If
installing manually, make sure to delete the old lib folder first.

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 GUIDEto launch the NRS .zip from terminal.

Nxt Client (NRS) 1.7.4

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.

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.

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.

NRS 1.7.4 release notes

Change log:

This is the first stable release in the 1.7 series. It is a mandatory update
for everyone. There is a hard fork scheduled for block 621000, estimated to occur around Jan 21, 2016, at which new features will be enabled. Nodes that do not update to 1.7.4 or later by this date will be left on a fork.

On testnet, the hard fork block is already passed, and all new features are fully functional.

There were incompatible API changes introduced in the 1.6 series. API users still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs and forum announcements, before upgrading to 1.7. These changes do not affect regular end users who just run the NRS client on their desktop or VPS node.

The new features and improvements in the 1.7 series have been documented in the 1.7.0e through 1.7.3e changelogs, available in the changelogs directory.

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

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.

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 GUIDEto launch the NRS .zip from terminal.

New features

Coin Shuffling

Coin shuffling can be used to perform mixing of NXT, MS currencies (unless created as non-shuffleable), or AE assets. Any account can create a new shuffling, specifying the holding to be shuffled, the shuffle amount, number of participants required, and registration deadline. This is done using the shufflingCreate API.

The subsequent shuffling steps can be done either manually, by using the shufflingRegister (for accounts other than the
creator), shufflingProcess, shufflingVerify or shufflingCancel APIs, or, much more conveniently, by starting an automated Shuffler, using the startShuffler API.

Once started, the Shuffler monitors the blockchain state for transactions relevant to the specified shuffle, and automatically submits the required transactions on behalf of the user, performing shuffle processing, verification, or cancellation as needed. To do this, the Shuffler is required to keep the user secret phrase in memory, therefore it should be run on a trusted local machine only.

A restart or a crash of the node requires the shuffler to be started again using the startShuffler API, as it should never save the user secret phrase on disk.

To participate in a shuffling, a deposit of 1000 NXT is needed, in addition to the amount of currency or asset being shuffled. Or if shuffling NXT, the amount of the shuffle must exceed this 1000 NXT minimum. If the shuffling completes successfully, this amount is added to the recipient account balance, to allow it to send outgoing transactions (as it is required that only new, unused accounts are specified as recipients). If the shuffle fails due to a registered participant failing to participate as required, or intentionally submitting false data, the participant responsible for the shuffle cancellation is penalized by retaining this deposit and sending it to the forgers of the shuffle finish block and the previous three blocks instead.

If a shuffle is cancelled because the required number of participants is not met, nobody is penalized and all deposits are refunded. On testnet, the deposit and penalty is 7 NXT only.

After shuffling registration is complete, participants must submit processing data within a 100 blocks period each (10 blocks on testnet). For the verification and blame phase, the total allowance for all participants is 100 + numberOfParticipants blocks (again reduced to 10 + n blocks on testnet).

Full blocks are not counted towards the limit. If at any stage the deadline is reached without some participant submitting the next required transaction, the shuffling is cancelled at this participant’s fault. It is therefore critical that after registering for a shuffling, the shuffler started is left running until its successful completion. If the node must be restarted, all previously running shufflers must be started again manually.

If desired, finished shufflings can be automatically deleted from the database if the nxt.deleteFinishedShufflings property is set to true (default is false).

The fee for creating a shuffling or registering in one is 1 NXT, for the
shuffling process or shuffling cancel transactions 10 NXT, and for the verify transaction 1 NXT.

Account control for phased transactions

Any account can be restricted to only be allowed to issue phased transactions subject to a specific voting model.

This is achieved by the account submitting a setPhasingOnly transaction using the setPhasingOnlyControl API. The getPhasingOnlyControl API can be used to retrieve the status of an account phasing control, and getAllPhasingOnlyControls to get all accounts subject to phasing control with their respective restrictions.

Once set, the phasing only account control can only be disabled or changed with another setPhasingOnly transaction, itself subject to the currently set phasing restrictions.

Note that by-transaction and by-hash voting models are not allowed for phasing control, and setting voting model to none is used to disable the control.

To prevent deadlocks due to cyclic account control restrictions, approval transactions themselves (PhasingVoteCasting) are not subject to phasing only account control.

When setting phasing account control, a maximum fees total can be specified, limiting the total fees for currently pending phased transactions of the controlled account, and limits can be placed on minimum and maximum phasing duration allowed.

Transactions of accounts subject to phasing account control with restriction on maximum fees are throttled at one per account per block.

Immediate release of phased transactions on approval

Phased transactions with a voting model that does not depend on account balance (such as by-transaction or by-hash), or by-account with no minimum balance and with a whitelist, will be released before their finish height as soon as approved (in the block in which the transaction causing their approval is executed), if possible.

Such early finish is guaranteed for transaction types known to be phasing safe. For others, if the early finish does not succeed due to the transaction failing validation at this height or conflicting with another transaction in the same block, a second, final release attempt will be performed at finish height.

New base target adjustment algorithm

Average block times will be 60 s, with 1440 blocks per day. Block times should practically never exceed 10 min.

Limit of 1000 NXT on minimum forging balance

This applies to the total of the account own guaranteed balance plus any balances leased to it, but not to each individual balance lease. An account with balance lower than the limit can still lease its balance to another.

Account properties

Those are name / value pairs that can be set on any account (except Genesis), by either the account owner, or by another account. Names are limited to 32 characters, and values to 160 characters. Names are unique per account and per setter account, but not globally unique. Account properties cannot be transferred between accounts.

The setter of an account property can edit it by replacing its value with another. Either the setter, or the recipient (if different) of an account property can delete it. There is no limit on the number of properties an account can have. Fee for setting account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee for every 32 chars after that.

Account properties are managed using the setAccountProperty and
deleteAccountProperty APIs. To query the properties of an account, or those set by an account, the getAccountProperties API can be used.

Singleton assets

Issuing an asset with a quantity of 1, decimals 0, and description length not exceeding 160 characters, will require a base minimum fee of 1 NXT only, instead of the regular 1000 NXT asset issuance fee. For description of more than 32 chars, an extra 1 NXT fee is added for each 32 chars. Asset name for singleton assets is limited to 10 chars, same as for regular assets.

Throttling of unique resource allocation transactions

Asset issuance (excluding singleton assets), monetary system currency issuance, and alias assignment (excluding re-assignment), will be limited to only one transaction of each type accepted per block.

Spreading back block fees for asset and currency issuance

The transaction fees for asset (excluding singleton assets) and currency issuance will be split between the forgers of the current and the previous three blocks in a 4:3:2:1 ratio.

Prunable plain and prunable encrypted message attachments both allowed in the same transaction

The maximum data size for each such attachment is 42 kbytes, but when coexisting in the same transaction the sum of the two is still being limited by the maximum payload size of 44880 bytes.

Peers that provide http or https API access open to anyone are labelled as providing a service

Peers that provide http or https API access open to anyone, configured with nxt.apiServerHost=0.0.0.0 and nxt.allowedBotHosts=* , are now labelled as providing a service, API or API_SSL, and can be found using the getPeers API with the corresponding “service” parameter. This API has been modified to
accept multivalued “service” parameter, returning peers that match all requested services. The ports on which the open API access is running are included in the peer info of peers providing those services as apiPort and apiSSLPort fields.

Incompatible changes

Deletion of asset shares

Deletion of asset shares will be performed as a separate AssetDelete
transaction type instead of as sending the shares to Genesis. Sending shares to Genesis will no longer be allowed. A new API, getAssetDeletes has been added to retrieve asset deletions, as using the getAssetTransfers API to find transfers to Genesis account no longer can be used for that purpose.

There is also a new API, getExpectedAssetDeletes, to get asset deletes expected in the next block, analogous to getExpectedAssetTransfers.

Messages

Since both prunable plain and prunable encrypted messages can now be added to the same transaction, the APIs getAllPrunableMessages, getPrunableMessage, and
getPrunableMessages cannot continue to use just a single “isText” boolean field in the JSON response to indicate if the prunable message is text or binary.

For all prunable plain messages, a new “messageIsText” boolean field is added, and for all prunable encrypted messages, a new “encryptedMessageIsText” boolean field is added in the response of the above APIs, for each message.

For backwards compatibility, the “isText” field will continue to be added, but only for transactions that have either plain, or encrypted, prunable message attachment, not for those that have both.

This change does not affect the attachment JSON returned from getTransaction API, as there are already separate messageIsText and encryptedMessage.isText fields there.

Fees and size limit changes

Several transaction types or attachments will have new fees and size limits, to encourage users to utilize the prunable versions when available, and to make fees proportionate to actual blockchain space consumed.

Aliases

Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus URI total length, after the first 32 chars. Name and URI size limits remain at 100 and 1000 chars respectively.

Messages and EncryptedMessages (non-prunable)

Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the first 32 bytes. For encrypted messages, the length is measured excluding the nonce and the 16 byte AES initialization vector, and to account for those there is an extra fee of 1 NXT.

Fees and size limit for prunable messages remain unchanged.

AccountInfo

Base fee 1 NXT, with 2 NXT additional fee for each 32 chars of name plus description total length, after the first 32 chars. Name and description size limits remain at 100 and 1000 chars. AccountInfo transactions throttled at one per block.

Polls

Base fee 10 NXT for polls with up to 20 options, and total size of poll name plus poll description plus total option length not exceeding 320 chars. For each option above 20, an additional fee of 1 NXT, and for each 32 chars after 320, an additional fee of 2 NXT. Poll creation throttled to one per block.

DGS Listing

Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus description total length, after the first 32 chars. Name and description size limits remain at 100 and 1000 max. DGS Listing throttled at one per block.

Phasing

In addition to the current fee for phasing (1 NXT for balance independent, 20 NXT otherwise), 1 NXT will be added for each 32 bytes of hashedSecret or linkedFullHash fields.

Referenced transactions

An extra fee of 1 NXT for the 32 byte referencedTransactionFullHash if set, i.e. if the transaction is using the referenced transactions feature.

To facilitate migration of legacy client code to the new fees, if the property nxt.correctInvalidFees=true has been set in nxt.properties (default is false), the server will automatically replace insufficient fees for submitted unsigned transactions with the minimum fee needed, depending on the transaction, as if feeNQT=0 has been specified. Fees exceeding the minimum, or fees for already
signed transactions, will not be corrected.

Quote from: mael on Today at 07:53:25 pmother thing: the adress who got my NXT (NXT-XVBJ-B8VA-Q7MB-HGZXQ) has received a lot of transactions the same day, same hour. What's this ?This appears to be someone run...

yes, I will do that for Ignis snapshot.I just trusted bter when they announced they will take the Ardor Snapshot.Look, this is what you can find looking on archive.org a version of bter main site on September, 18th, 2016[url=https://web.archive.org/...