NEM Beta 0.6.93

NEM Beta 0.6.93

##There will be a fork at height 1250000 (which is roughly August 20th).


1) Fee Fork:

The long awaited lowering of fees is near. From height 1250000 on the new fee structure is available.
Here are the basic changes, we probably should have a blog post explaining in more detail.

a) Message Transfer transactions:
The fees for transfer transactions are lowered by a factor 20. That means:
i) a message costs 0.05 xem per commenced 32 message bytes, no message means no fee.
ii) a xem transfer costs 0.05 xem per 10_000 xem transferred, capped at 1.25 xem, so for example transferring 45000 xem costs 0.2 xem.
The transfer of mosaics is following the same formula like before but is also a factor 20 cheaper.
The minimum fee for a transfer transaction is 0.05 meaning even if you transfer 0 xem, no mosaics and attach no message you will have 0.05 xem fee.

b) MultisigAggregateModificationTransaction:
This transaction type has a flat fee of 0.5 xem, no matter what modifications you make.

c) ProvisionNamespaceTransaction and MosaicCreationTransaction:
sink fee for root namespace provisioning: 100 xem
sink fee for sub-namespace provisioning: 10 xem
sink fee for mosaic creation: 10 xem

The transaction fee for the above is 0.15 xem.

d) Other transactions like MosaicSupplyChangeTransaction, ImportanceTransferTransaction, SignatureTransaction…
The transaction fee for those transactions is 0.15 xem.

2) Added batch historical account data retrieval:

This will be helpful for the Nano Wallet voting sytem.
It is not yet documented, if you are interested using it you can ask the developers.
Only nodes that have the HISTORICAL_ACCOUNT_DATA flag set in the NIS config provide support for the request.
Setting the flag means that NIS will need lots of RAM, a minimum of 9GB for the NIS java process is recommended!

This upgrade is mandatory.

If you’re using the installer, make sure to stop running NIS before running the installer!

NEM requires Java 8
Remember the installer requires 64-bit Java
You can download Java from official page:

You can start NIS with an installer from the following link:
Standalone version:


Has NCC been discontinued?
It will be no longer possible use it after fee fork?

yea ncc is discontinued.

why ncc discontinued ?

The js side of NCC is not actively maintained any more. No new features are added.
So it is only a millstone arounds our (devs) neck.

For Supernodes, is there a new version that displays the wallet in the web browser - like the NCC standalone (windows)?

We have Nano Wallet.

Oh ok For some reason I didn’t think it was suitable for supernodes

I previously bookmarked the guide to update from the old wallet to the Nano Wallet, is there anything else I need to do?

well you only need to export all wallets from NCC and import into Nano Wallet i think. (and make backups!)

Ok I will give it a try tomorrow thank you :smiley:

But NCC is still included in nis-0.6.93.tgz package, isn’t ? So, will be possible to use (this) NCC among with NIS 0.6.93, or not, or it will, but just until the fork happens ?

It is not yet documented, if you are interested using it you can ask the developers.
Only nodes that have the HISTORICAL_ACCOUNT_DATA flag set in the NIS config provide support for the request.

I would like to try this. Is this the proper way to set the flag?

nis.historical_account_data = true

I thought it was this.

# Optional features supported by the local node (pipe-separated).
# TRANSACTION_HASH_LOOKUP: transactions can be retrieved by supplying the transaction hash.
# HISTORICAL_ACCOUNT_DATA: historical account data can be retrieved.
### nis.optionalFeatures = TRANSACTION_HASH_LOOKUP
nis.optionalFeatures = HISTORICAL_ACCOUNT_DATA
#  ↑ or ↓ 
nis.transactionHashRetentionTime = -1

That’s great ! I think many nembers are waiting for this version. Thanks for our developers !:+1::clap::v:

What kind of data are contained in blockchain messages?

In 0.6.91:
4e545903 – Apostille header
b9724a15f75c4f8fce078fb84fbcf535a5f9465f6b51667e505b9c42a876370a – sha-256 hash of the file
0000626f622e6e656d2e6e696e6a612f696e7374616c6c65722f6e69732d6e63632d302e362e39312e74677a – what is this?…

In 0.6.93:
4e545903 – Apostille header
41429325bb368ddee0d6c6e63417bf4b835d218fbb05512e5ce7a13f6cbae05a – sha-256 hash of the file
0000626f622e6e656d2e6e696e6a612f696e7374616c6c65722f6e69732d302e362e39332e74677a – what is this?…

Thanks for the answer.

hex ascii. Reads “”

see @mizunashi’s post.
If you support HISTORICAL_ACCOUNT_DATA you can support TRANSACTION_HASH_LOOKUP as well and set
nis.transactionHashRetentionTime = -1
in the config. This only need a few hundred MB more RAM.

The node won’t start after I added those options. I assume I need to allocate more memory?

I’m using this right now:

java -Xms1408M -Xmx1408M -cp “.:package/nis:package/nis/:package/libs/” org.nem.deploy.CommonStarter

What do you recommend?

Presuming this is the usual Jar file update for SNs. In regards to the client, I have been using the NCC with delegated harvesting pointing at my SN. What is the least intrusive way to get my NCC wallet across to Nano, and delegated harvesting to continue?

I’m still not sure, if will or will not be possible [after the fork] to use NCC just for monitoring (and set up delegated harvesting) due to current version of NIS (If this still will be possible, I guess it’s not necessary to migrate into NanoWallet, just for these purposes). BR, could you get some explanation for us, please ? Thanks.