Nxt 2.0 – should investors and asset issuers be afraid? [video]

Here’s some great listening for you – Nxt core developer Riker chatting about Nxt, other cryptos and investing with Marc De Mesel, an investor who has 35% of his investments in NXT.

Marc wants to learn about Nxt’s anonymous lead developer Jean Luc, about where Nxt is now, compared to Ethereum and other blockchain ‘competitors’, and also about the recently proposed changes to the Nxt protocol (the NXT 2.0 proposal).

Riker explains how Nxt 2.0 aims to solve the blockchain bloat problem and make Nxt the first ever globally scalable crypto platform.

Also: how Nxt, if version 2.0 were to proceed, would become a sidechain and how, with version 2.x, more sidechains could be added. Instead of implementing Some Asset < > Some Asset trading, Nxt 2.0 would make all Nxt AE assets tradeable across all sidechains, globally.

Having a sidechain pegged to a fiat value, and other sidechains pegged to crypto coins like Bitcoin, Nxt assets would become tradeable on several new markets thereby, in effect, creating a fully decentralised, multi currency, low fee, globally scalable asset market, powered by Nxt AE.

[youtube id=”tN4FjZ-31uk” width=”600″ autoplay=“no”]

Nothing is yet set in stone, but as the Nxt 2.0 design has been discussed and refined for at least 6 months already among the Nxt core developers, there is every indication that Nxt 2.0 in its essence will be programmed as proposed, with all the remaining details hammered out in cooperation with the users, the active Nxt Community.

Riker mentions how Nxt 2.x could also be of benefit to companies, a user category which has shown a lot of interest in the Nxt Monetary System (MS) but been reluctant to use it because of the current need for users to pay transaction fees in NXT.

Now, with Nxt 2.0, they would be able to launch fully secured sidechains with Nxt features but without the sidechain users having to buy NXT to use it. As an example, Nxt MS tokens could be used as concert tickets, and only the business running the sidechain would have to pay fees to the Nxt main chain forgers.

Another obvious use case, via the Nxt MS’s crowdfunding feature,  would be to run crowdfunding campaigns in the sidechain currencies, such as fiat or Bitcoin.

Some organisations would probably want their own private blockchains, and ask the Nxt core developers for their help. But would any such private work which the Nxt core devs might get paid to do ever benefit the Nxt investor? Should we be looking for companies which would be willing to pay for the core development of the open sourced Nxt? Or would such companies get too much power over development?

Also read: Jelurida Q&A; Nxt core devs mean business

Is there a risk that, if Nxt became a sidechain with Nxt 2.0, the value of NXT would CRASH bringing down with it all AE asset prices, as some people have been claiming in the ongoing discussion regarding the design proposal? If so, should AE asset issuers and asset investors run away from the Nxt blockchain asap?

You’ll have to decide for yourself, of course. The crypto market is volatile and unpredictable, so who can really tell.

Lots of noise on this video, lots of good information too.
Thanks to Marc and Riker for doing this interview in Amsterdam.

Discuss the Nxt 2.0 design proposal in Nxtforum

To follow Marc De Mesel on Youtube, you can subscribe to his channel.


The Sound Key – helping you stay financially sound!

Whatever method of storing and transferring monetary value you use (cash and cheques; digital fiat money or cryptocurrency) there will always be someone trying to steal from you. How to stop them succeeding is a constant battle and each technology has its particular inherent vulnerability or vulnerabilities.

In the case of cryptocurrency, or more specifically the blockchain technology on which it is based, one such vulnerability has, until now, been how the “private key” is stored.

The private (or secret) key is a sort of password that is used to digitally sign transactions that are then entered onto the blockchain. If a private key gets stolen, the thief can sign on behalf of the original owner and post irreversible transactions in the blockchain in his own favour.

No matter how securely you store your private key on your computer or smartphone, it always has to be exposed in the device’s memory when it’s used (to digitally sign something). That’s the inherent vulnerability and it just takes a virus with some malware or spyware to sniff the memory at the right moment, and the damage is done.

This is where the Sound Key comes in. It is a device, very similar to banks’ OTP devices, to store your private key outside your computer or smartphone’s memory, and to digitally sign documents or blockchain transactions offline and therefore safely.

How the Sound Key works:

  • The Sound Key connects to computers or cellphones through the headset port.
  • The transaction data, as yet unsigned, are sent to the Sound Key via the audio port on your computer or smartphone.
  • Having verified that the unsigned data in the Sound Key display is correct, type your password in the device to safely digitally sign the transaction.
  • That’s it. Your transaction is signed, sealed, and ready to be delivered.
  • The Sound Key will then transmit the signature back to your device through the audio or speaker port.
  • At no stage does your secret key ever leave its safe place inside the Sound Key.

It’s anticipated that within a few years this kind of device will become widespread and popularly regarded as a necessity.

The Sound Key is currently a prototype, and we want to bring you the best of what it can do. We are therefore working not only on the device itself, but also on the accompanying software development kit, to be backed by good customer support, so that innovators and users alike can benefit from it as much as possible.

10 Reasons to support the Sound Key:

  • It’s the first device of its kind.
  • It’s backed by private investors, so even if we don’t reach our pre-order goal, you will get your Sound Key when we start shipping.
  • You can brand it with your own logo thanks to our whitebox option (minimum order applies).
  • It comes with a development kit, to integrate its features into any app and website!
  • It can be used with any cryptocurrency and other digital signatures (more signature algorithms will be implemented with time).
  • It can encrypt and decrypt any kind of data (size limit applies based on model).
  • It keeps your private key physically out of reach of malicious programs and people, as it NEVER leaves the device (the signature and encryption/decryption take place IN the device).
  • The top model of the Sound Key can encrypt voice messages, without supplementary software, to be decrypted by a specific public key, and thanks to the audio connections, the encrypted messages can be sent via email, IM, or other apps.
  • It can be used to identify users on websites or over the phone.
  • Oh, and it talks 🙂

If you want to see this idea come to life, come and give us a hand with our crowdfunding campaign.


You can learn more about the Sound Key project at: www.TheSoundKey.com.

And here!

Like us on Facebook.

Follow us on Twitter.

SuperMesh.io test release


Nxters, get your Raspi2 running;
Grewalsatinder has pushed a SuperMesh.io test release.

Grewalsatinder writes: ‘SuperMesh.io Test Release is a small bundle of applications and services which provides easy access to various decentralized technologies like MeshNET, NXT Full Client, Decentralized DNSs, TOR websites/services (e.g. onion websites).

It’s a basic feature build/OS which enables any person with some technical knowledge to build their own Raspberry Pi device and use it as a smart router providing easy access to MeshNET and Decentralized technologies’.

You can find an updated grewalsatinder’s roadmap for SuperMesh.io HERE.

You can find build updates on SuperMesh’s Github repo https://github.com/satindergrewal/SuperMesh and official forum thread till the official website gets ready.

Note that there aren’t any .nxt websites to explore in the meshnet yet, as we just entered it. Eventually there will be, for example nxter.nxt will be set up soon for you to enjoy in the meshnet. Until then, you can find a list of useful meshnet websites related to the Hyperboria (CJDNS) network here: http://hyperboria.be/.
SuperMesh.io and Nxt are not related to CJDNS and Hyperboria in any way.
This first test release is for Raspi2 users only and will not be stable on older Raspberry Pi models. Upcoming releases may support all the old RasPi models.

SuperMesh.io test relase 0.01

Included Features:
1. NXT Full Node.
2. Updates NXT automatically.
3. Access to .nxt DNS.
4. Decentralized DNS with IPv4 & IPv6 Support.
5. HotSpot WiFi.
6. Access MeshNET services as SuperMesh.io WiFi client with ease.
7. Access TOR services (.onion) as SuperMesh.io WiFi client with ease.
8. Run NXT Full Client using TOR Network.
9. Run NXT Full Client with IPv6 Support Enabled.
10. Easy access to NXT client via web page.
11. Auto Configure CJDNS and connect it to Hyperboria network.
12. Easy access to MeshNET websites/services as SuperMesh.io WiFi client.

NOTE: This test release is still experimental. So, please evaluate it, test it, and if possible break it and/or improve its security features. Then share your findings and any solutions with the community as part of the ongoing process to optimise security and efficient usage. If you do enhance its security, please share your solution, so I can include that in the next build and put your name in credits.

SuperMesh.io Test Release:
Version: Beta 0.01
Date: 12 July 2015
File: SuperMesh.io-beta-0.01-12-07-2015.img
MD5: 7627b0ad853f4989baefc6ee844e8b7b
SHA256: fe52125928e8126cff128d3fe8937731e3fce395d8cf999e07bd04bb80ff3e1c

File Download Link: https://mega.nz/#!rUsiGQRB!6eFNsoUCAnnlnz8wQCM4vBe8iTUEdIa43h6wCtdFpdw

Recommended Hardware:
1. Raspberry Pi 2.
2.1 Edimax WiFi Adaptor – Model EW-7811UN (for WiFi Access Point).
2.2 An additional Edimax WiFi Adaptor – Model EW-7811UN (for connecting your node to existing WiFi connection)
3. Monitor.
4. USB Keyboard & Mouse.
5. HDMI cable.
6. You can use micro USB Charger from most phones and cameras to power your Raspberry Pi.
7. microSD Card (8GB or 16GB) – I used SanDisk Extreme Plus. Little bit faster than usual.

You can follow the standard instructions from Raspberry Pi website to install SuperMesh.io image on microSD card: https://www.raspberrypi.org/documentation/installation/installing-images/README.md

SSH and Terminal Access Details
SSH/Terminal Login:
Username: pi
Password: SpaceMesh

#### IMPORTANT: Change the default Password ####
It’s very important to change your SuperMesh.io node’s default login password to something different and stronger. You can change the password after logging in to SSH or Terminal using command ‘sudo raspi-config’. Use arrow keys and select second option ‘Change User Password’ to enter new password.

WiFi Access Point Access Details 
WiFi Access Point Info:
Default SSID: SuperMesh.io WiFi
Default Password: SpaceMesh.org

#### How to change your default WiFi Access Point’s Password ####
Default password of WiFi Access Point can be changed from file /etc/hostapd/hostapd.conf
Open the file and change the value of ‘wpa_passphrase’.

#### How to connect your SuperMesh.io node to existing WiFi connection ####
For that you’ll need to edit ‘/etc/wpa_supplicant/wpa_supplicant.conf’ file as root user. Use the following command:

sudo nano -c /etc/wpa_supplicant/wpa_supplicant.conf

If your existing WiFi connection does not need any password to connect to just enter its SSID on line 6. Replace word ‘YOUR_WIFI_ID_HERE’ with your SSID.

If your existing WiFi connection needs to be connected using a password, I have configured common settings there. Go to line 13 and update your WiFi SSID where it says ‘YOUR_WIFI_ID_HERE’, and replace the string ‘YOUR_WIFI_PASSWORD’ with your existing WiFi connection’s password.

Save the file, and restart networking service:

sudo /etc/init.d/networking restart

Or just reboot your system with command ‘sudo reboot’. Next time you boot up your system, it should connect to WiFi. If not, you have to find your correct settings for WiFi configuration. Search ‘How to setup WiFi on Raspberry Pi’. That might be of some help. 🙂

TOR Network and Access Details
System by default connects to clearnet. It does not enable TOR access for WiFi clients by default. There are two ways to enable TOR access to WiFi clients:

1. Enable line 21 from file /etc/network/iptables.ipv4.nat. Remove ‘#’ from the line, save it and restart network interface, or just reboot the system. This will route all traffic of WiFi connected clients by default through TOR. Whatever service they access will pass through TOR network. You can visit website ‘ipchicken.com’ and it will show you your public IP and a hostname if there’s one for that public IP.

But, some people still don’t trust the TOR service. That’s why I set it not as default to route all traffic of connected WiFi clients through TOR. In case you do not want to mess with iptables, you can use the second option.

2. Use SOCKS Proxy setting for your browser or applications to access TOR services or route through TOR network. The SOCKS Proxy details are as follows:
Code: [Select]
SOCKS Proxy Port: 9050

With the second option you do not need to make any changes to iptables or anything else. Just connect to WiFi Access Point of SuperMesh.io node and use proxy settings to surf internet through TOR.

NXT Full Node Access Details 
NXT Full node is accessible via all network interfaces of SuperMesh.io node. If you do not know what IP address the SuperMesh.io node got when you plugged the LAN cable into it, you can just connect to its WiFi Access Point, and visit On that web page click on ‘NXT Full Node’ link and access your NXT Client’s Web interface.

The web page is static. This test release does not give any dynamic information, e.g. internet/TOR/MeshNET/LAN network conectivity info. However, future builds may do so.

NXT Full node by default connects to peers through clearnet/internet. It does not route through TOR. If you want to enable TOR for NXT Full Node, you can edit the file ‘/home/pi/nxtpi/nxtrun.sh’. Open the file and remove ‘#’ from 3rd line and add ‘#’ to 4th line. Save the file and reboot the system. Next time SuperMesh.io node boots up it will be connecting your NXT Full node to internet through TOR network.

NOTE: TOR settings for NXT Full node are exclusive to NXT only. Any changes made to iptables for WiFi clients will not enable NXT Full Node to route through TOR network.

CJDNS MeshNET Access Details 
When you boot your system for the first time SuperMesh.io node by default generates a new CJDNS configuration file and populates it with a CJDNS Public Peer. You do not need to do any single settings or change your CJDNS Settings. If you still want to play with it, or want to see what’s inside your CJDNS settings you can check the file /etc/cjdroute.conf.

If you want to see what your MeshNET IPv6 address is, enter command ‘ifconfig tun0’ or ‘ip addr show tun0’. The line with ‘inet6’ shows your IPv6 address.

If you want to confirm if you are connected to CJDNS MeshNET you can ping to my CJDNS Public Node IPv6 ‘fcdc:1bde:c1f4:4b9c:5a91:d33b:d771:d492’.

On Mac and Linux use command:
Code: [Select]
ping6 fcdc:1bde:c1f4:4b9c:5a91:d33b:d771:d492

On Windows use command:
Code: [Select]
ping 6 fcdc:1bde:c1f4:4b9c:5a91:d33b:d771:d492

HyperBoria Websites Access Details
The build is now able to access Hyperboria websites, as the SuperMesh’s own temporary CJDNS public peer got some nodes connected which connects us further to existing Hyperboria only websites like ‘uppit.us‘ or ‘socialno.de‘ or ‘nodescan.hype’ (by slothbag).

If any of you get access to a peer which connects to existing Hyperboria websites/services you can update/change your CJDNS config file (/etc/cjdroute.conf) by following this guide: https://wiki.projectmeshnet.org/How_To_Add_Peers

By adding that peer you’ll be able to connect to Hyperboria websites. But, maybe others still won’t.

#### How you can help NXT and SuperMesh.io Nodes to connect to Hyperboria network? ####
If you have made your SuperMesh.io node a public node, and your CJDNS is peered with a node which connects to Hyperboria, you can share your peer info with me, and I’ll add it to my CJDNS Public Peer. That will help other SuperMesh.io nodes out there connect to existing Hyperboria websites.

Make your own website/service exclusively available on CJDNS MeshNET

Yes, having this SuperMesh.io node gives you a very easy platform to build your own website or service and make it available on MeshNET. This test release of SuperMesh.io node comes with ‘NginX Web Server’ installed with it. It’s a very lightweight web server. Do your research and check out how you can use your Raspberry Pi as a website server or for any other kind of services.

Decentralized DNSs on SuperMesh.io node
This test release has everything set up to access services accessible through Decentralized DNS .nxt.

You can setup your NXT Aliases to be used as Decentalized DNS. All existing NXT Aliases can be used with .nxt.

Example: If I have NXT Alias name ‘satinder’ registered in my NXT Account, I can set it with type ‘Other’ and use following JSON data in ‘Data’ field:
Code: [Select]

Once the changes are saved and confirmed on NXT Blockchain, I can access my website using ‘satinder.nxt’ or ‘www.satinder.nxt’.

If you need to set up your NXT Alias as a Decentralized DNS for IPv6 address (as for your MeshNET node), you can use the following JSON string:
Code: [Select]
{“ip6”: [“your_ipv6_address_here”]}

Grewalsatinder writes: ‘I had issues while testing NXT Alias as Decentralized DNSs. Mostly the issues were due to wrong JSON formatting. You can copy your JSON string to the following online JSON editor and verify if your JSON string is valid: http://www.jsoneditoronline.org/. Once confirmed, only then use your JSON string as Data for NXT Alias to make a Decentralized DNS.

It’s thanks to communities like NXT, CJDNS, Raspberry Pi, DNSChain, SuperNET and so many developers from related communities that this build was possible. I hope you’ll like this SuperMesh.io test release, and join this project to improve it further’.

toenu – for adding .nxt support to DNSChain.
slothbag – for making base of Decentralised DNS on NXT Blockchain

If you want to support grewalsatinder for his efforts you can send some love in the form of NXTs.
His NXT address NXT-QK5L-7YM9-YPVF-55GL5

Ramchains: Ultra-fast blockchain operations


SuperNET developer jl777 has created ramchains: a compressed, memory-mapped implementation of the blockchain that is capable of blazingly fast operations. The innovation solves a critical problem with cryptocurrencies, and opens the door to completely new applications.

The blockchain is the foundation of cryptocurrencies: the decentralised ledger technology pioneered by Bitcoin that makes trustless online money possible. Blockchains, however, have some serious problems. Because they contain all the information about every transaction ever made, they are large, unwieldy objects. Bitcoin’s blockchain runs to 28 GB and accessing these files, stored on the hard disk of users’ computers, is a slow and resource-heavy process.

By storing only the most immediately relevant information from the blockchain in memory, ramchains allow for ultra-fast, random access queries to essential blockchain information, while keeping resource usage at a minimum. This is possible because the majority of operations do not require the full blockchain.

Ramchains were developed by Nxt and SuperNET developer jl777 in response to performance issues on the Multigateway (MGW), a distributed cryptocurrency exchange built on top of the NXT platform. MGW forms a critical component of the SuperNET – the ambitious project to bring together the best technology and services that the cryptocurrency ecosystem has to offer.

‘A lot of the time consuming blockchain operations simply involve scanning the blockchain for unspent outputs,’ comments jl777. Creation of the ramchain – essentially a distillation of the most often-required information from the blockchain – is a one-time event. Once the historical blockchain has been processed, new blocks are added to the ramchain in real time.

The ultra-lightweight ramchain files can then be accessed directly, bypassing slow coin daemons entirely. Because the file is memory-mapped, query speeds are dramatically reduced. If enough memory is available, the ramchain is stored in RAM; if not, virtual memory is used.

Performance gains

Early indications are that startling performance gains are possible. For example, 220 MB of the BitcoinDark blockchain is reduced to an active memory footprint of 80 MB. ‘That is with a fully loaded ramchain and all the code, data structures and everything else… to have all that at one third the size of the raw blockchain is a fantastic result. If needed, it can shrink down to 40 MB or even less, dynamically based on system usage.’

Ramchains has been deployed with the beta launch of SuperNET

Ramchains is already deployed in the SuperNET beta Client (MGW), a distributed multicoin wallet currently supporting Bitcoin, BitcoinDark, DOGE, NXT, VeriCoin, OpalCoin, Litecoin, FibreCoin, VPNcoin and BitStarCoin.

More than the space savings, it is the speed with which ramchains function that offers the greatest advantages. ‘It is a matter of proper allocation of data according to usage,’ states jl777. ‘The CPU can gain access to the data many, many orders of magnitude faster than if it was stored on the hard drive. From the limit of about 500 RPC calls per second to bitcoind, ramchains can probably do 100,000 to 500,000 internal requests per second.’

To take the example of a resource-intensive task like calculating a rich list: ‘For BTCD it takes a few seconds to load the files, a few seconds to rescan entire blockchain and create RAM-resident data structures so any query can be made totally from RAM without any searching. Calculating the balance for all accounts and sorting a rich list could take around seconds. That is from scratch, each time.’

SuperNET will make use of this new technology, along with a series of other innovations – realtime decentralised crypto trading (InstantDEX), corporate-level privacy, marketplaces, games and other services – but Ramchains have applications far beyond this. ‘When you make the process 100 times faster, things you could never have considered suddenly become possible.’

SuperNET is an association of the most reliable blockchain technologies today, giving you access to all their innovation from one place. You can follow the innovation and get the latest updates by subscribing to the SuperNET Newsletters, and try the SuperNET beta client: http://www.supernet.org

Introducing: NxtVault

NxtVault is an open source Android application, which stores your Nxt passphrases encrypted in isolated secure storage. You will never need to enter your Nxt passphrase again, and you will no longer be at risk of viruses or keyloggers infecting your machine. Not only is it encrypted but Android’s security sandbox prevents other processes on your device from accessing the apps’ isolated storage.

After three bad attempts at entering your pin you will be locked out for 1 hour. Another bad attempt and you are locked out for 24 hours. Another bad attempt and the application will wipe out all of its data and shut down.

NxtVault is built on top of Jones’ “Jay Framework”, a javascript library created to interface with the Nxt network using dynamically discovered public nodes, allowing for the creation of our first suite of Nxt thin clients that don’t rely on a single developers centralized server!

Let’s make this even simpler:

NxtVault pincode NxtVault transactions NxtVault account 

NxtVault add account NxtVault view account NxtVault setting

For every web transaction, NxtVault pops up and displays a detailed report of exactly what the transaction intends to do, giving you a chance to review and then either confirm or deny it. The goal of the developer isn’t hard to grasp: ‘To have every third party web application support this type of transaction’.

NxtVault can be downloaded here: https://play.google.com/store/apps/details?id=jay.nxtvault

Using NxtVault with JayClient

NxtVault supports the ability to scan a qr code of a JayClient transaction.

Read more about the Jay Client.

Jay includes http://jnxt.org/jayex/ which enables you to watch and trade your Nxt assets from a web browser; transactions are secured by the Jay framework and/or NxtVault.


JayEX is allowing for a Nxt AE trading with the security of the localhost NRS client, the inspiration of SecureAE, and the chart ideas and layout idea from Poloniex.’

The full Nxt NRS Client is available at http://jnxt.org/nxt/ as a website (and a downloadable .zip to host locally, if you prefer). Update: The jnxt.org site and the Jay Client + framework is no longer maintained. The source code can be downloaded from https://github.com/jonesnxt/

Nxt JayNxt NRS Client
Sign in with your Nxt account, not your secret passphrase.

Nxt Jaywallet NRS
Do what you like.

Nxt Jaywallet transaction tx
Send your tx’s by scanning the qr code with NxtVault, or sign it with the Jay localhost client on your desktop. 

Nxt Android apps on top of NxtVault

NxtVault developer, mr_e, writes:

Other Android applications can raise an intent to NxtVault to request for it to sign and broadcast transactions on it’s behalf. I have created an API so that Android developers can create third party applications that are not required to be open source, nor will you need to worry about trusting them with your passphrase!

NxtVault can handle both signing the transaction, and broadcasting the transaction to light nodes that are detected on the network, in a decentralized way.

I hope that this will unleash a whole new suite of trustless android apps.

The NxtVault source code has been reviewed by Jones. https://github.com/mr-e-/NxtVault

To integrate NxtVault, you need to implement its intents (i.e. the messaging objects used to request an action from another app component).

There are three key intents you can raise for NxtVault to pick up:

nxtvault.intent.action.REQUESTACCOUNT (request an access token along with the users nxt address – this will pop up nxtvault allowing the user to select an account to share)

nxtvault.intent.action.SIGNANDBROADCAST (signs transaction and broadcast – will pop up a transaction summary screen allowing user to confirm)

nxtvault.intent.action.SIGN (signs transaction and returns bytes to calling application – will pop up a transaction summary screen allowing user to confirm)

An example of how to raise these intents and respond to their results is located in the code base here:

You can add nxtvault client lib as a library to your project. This gives you a JavaScript interface for all jay calls, as well as the code to raise the correct intents.

Click on the link below for the Jay interface and look at the test wallet to see how they are called: (the jinterface is using interop with javascript and will allow you to make any NRS request to a public node. With this you can make calls to getAccount, getAsset etc without needing a centralized server of your own)

For more info + to talk to mr_e:

Shareholders Meeting via Blockchain

It seems we are witnessing a revolution in the corporate world caused by blockchain technologies. We’re moving quickly towards a new business ecosystem of virtual corporations, distributed autonomous corporations, smart contracts, new models of funding and so on. This article is about the exciting possibility of having distributed shareholders’ meetings where results are public and counted in a trustless way.

Since late April last year, I’ve been working on the NXT cryptocurrency as a core developer. NXT is a 100% proof-of-stake cryptocurrency aiming “to transform a cryptocurrency into a decentralised financial platform that supports a thriving and fast-growing digital economy” (unlike hybrid Ripple’s approach which isn’t fully decentralized).

Since 12 May, NXT has had the Asset Exchange (NXT AE) as a core feature. Anyone can now issue assets on this totally decentralized and uncontrolled exchange and trade them.

You can monitor your Nxt asset purchases either via your client or via a number of independent web sites: NextBlocks, NXTReporting and SecureAE  (where you can also purchase Nxt and issue assets).

Read the asset descriptions and you’ll quickly gain an appreciation of the wide range of different applications and services that have already been built on top of the Nxt platform and they’re just the beginning; the start of what is set to evolve into an entire financial and economic ecosystem.

The key feature of the NXT AE for businesspeople is that they can fund their business via asset issuance, getting money from anyone (not just angels/VCs, as with KickStarter), and they can do so from day one and for a low fee.

Imagine getting funding directly from a community needing your product. And, wouldn’t it also be awesome to get feedback and community-powered decisions?

With the voting system I have finished recently that will all be possible. The voting system will be introduced in NRS (NXT Reference Software) 1.5. The latest release version is 1.4.16, so voting API & GUI is already accessible. I can share some API details right now as they will likely remain unchanged.

Also see: Nxt Voting Teaser video (GUI and functionality)

Consider the example of an indy developer making a game. First, he got some funds via the asset exchange. Then he made a promising v.1 of the game. Both the concept and its implementation are still raw but the fans are excited! So he wants to ask the community whether he should polish v.1 or instead build v.2 on the basis of a better concept, or… Having decided on the different options, he starts the poll:

    val question = "Further directions in game development. "
    val description = "I got some great reviews. I have 10000 NXTs left. How should I spend them?"

    val finishBlockHeight = Nxt.getBlockchain.getHeight + 1440 // ~= 1 day
    val options = Array("Improve graphics and release it ASAP", "Start to work on v.2 to get funds for it's development", "Better ask experts, e.g. attend GameDev Conference", "Game is abortive. Stop working on it.")

    val optionModel = Poll.OPTION_MODEL_CHOICE
    val votingModel = Poll.VOTING_MODEL_ASSET

    val pb = new PollBuilder(question, desc, options, finishBlockHeight, optionModel, votingModel)
    val assetId: Long =  // assetId here
    pb.optionsNumRange(1, 1) // only 1 option to choose

    issueTxToGodId(new Attachment.MessagingPollCreation(pb), phrase1)

A vote could be sent with following code:

    val poll = Poll.getByName(question).head
    val vote = Array(0.toByte, 1.toByte, 0.toByte, 0.toByte)
    val attachment = new Attachment.MessagingVoteCasting(poll.getId, vote)
    issueTxToGodId(attachment, phrase2) 

1440 blocks after starting the poll we can get and print to console poll results (where 1 asset=1 vote):

    val pr = PollResults.get(poll.getId).get
    pr match {
        case cpr: nxt.PollResults#Choice =
            val m = cpr.getResults.toMap

So, we are soon going to have fair, cheap, public and distributed shareholders voting! Just imagine how that could change the world of business.


1. This blog post (as revised) was first released by Kushti on 2. The minimum fee to issue an asset on the NXT AE is 1000 NXT. The transaction fee is currently 1 NXT.

Latest NRS Release

NRS 1.11.7

By apenzl | 07/08/2017 | 0 Comments

Nxt Client (NRS) 1.11.7 Get it Get it Get it Exe and dmg digital signature: “Stichting NXT” .sh Sha256:dca642ffa8a2508c72af9246dc224af3f4e523427b77b1e7a026fe0ea57e05cd  nxt-client-1.11.7.sh Release 1.11.7: https://bitbucket.org/Jelurida/nxt/downloads/nxt-client-1.11.7.zip 1.11.7 .zip sha256: bfed4c5c2df82e876f88885c1d0501810edf49fc4998d694e74852d6ab176d57  nxt-client-1.11.7.zip 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 … Read more

NRS 1.11.5

By apenzl | 04/04/2017 | 0 Comments

Nxt Client (NRS) 1.11.5 THIS IS THE LATEST NRS RELEASE Get it Get it Get it Digital signature: “Stichting NXT” .sh Sha256:863fadaedf11ca9f0317b724c0e68e549703482c30fdb07e90f16d0f1f7195bd  nxt-client-1.11.5.sh Release 1.11.5: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.11.5.zip 1.11.5 .zip sha256: facb359f2a4fae62b5e2cbb2f5a41bd8cface8090ba72d3ddcba22a904fb23d3  nxt-client-1.11.5.zip NRS 1.11.5 release notes Added firstIndex, lastIndex parameters to the getUnconfirmedTransactions and getUnconfirmedTransactionIds APIs to support pagination. Minor performance optimizations and UI improvements. Updated … Read more

NRS 1.11.4

By apenzl | 05/03/2017 | 0 Comments

Nxt Client (NRS) 1.11.4 THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE Get it Get it Get it Digital signature: “Stichting NXT” .sh Sha256: 5f8caea32c659c63580e68f61b2d666685f2e162e8d341aa1980abae0126028b  nxt-client-1.11.4.sh Release 1.11.4: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.11.4.zip 1.9.2 .zip sha256: 8e7d5115e1664ae70cc46ff2a9d914ed50052b4352bf8ce5bd76118d63c84817  nxt-client-1.11.4.zip NRS 1.11.4 release notes Added Node JS module, see html/www/js/README. Minor UI and desktop application bugfixes, ported from … Read more

NRS 1.11.3

By apenzl | 11/02/2017 | 0 Comments

Nxt Client (NRS) 1.11.3 THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE Get it Get it Get it Digital signature: “Stichting NXT” .sh Sha256:ff67155c541df52fef3db6ca85643cc1814452847a14793c3c2f7e37acec53be  nxt-client-1.11.3.sh Release 1.11.3: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.11.3.zip 1.11.3 .zip sha256:ecfc181f8085c21142fa9ffe74979a16d8d87c49f325e5a28e57990c0beb4c42  nxt-client-1.11.3.zip Bugfix release To learn more about the upcoming public Ardor testnet release, see the latest screenshots, help test, and follow … Read more

“Ardor snapshot” release – Nxt NRS 1.9.2

By apenzl | 13/07/2016 | 0 Comments

Nxt Client (NRS) 1.9.2 THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE Get it Get it Get it Digital signature: “Stichting NXT” .sh Sha256: bf135f9d7280860b59fb69d4753e436ed23ebbcf95e1e4112cb707c7a64a20b4  nxt-client-1.9.2.sh Release 1.9.2: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.2.zip 1.9.2 .zip sha256: 4fe0520e5b4d0fe244dc9d8ab7943c1a107a7e4227ce4ae9f3236ae1dcc1a8ab  nxt-client-1.9.2.zip ARDR Snapshots Snapshotting will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12). Relevant reading: Ardor … Read more

Nxt [ANN]: NRS 1.9 experimental (updated)

By apenzl | 20/06/2016 | 0 Comments

Nxt Client (NRS) 1.9.1e THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE Get it Get it Get it Digital signature: “Stichting NXT” .sh Sha256: 4e21c830f43d9d842c7005252b2a75983a4a5a067994c1b49ac1339f8ac5ed2c  nxt-client-1.9.1e.sh Release 1.9.1e: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.1e.zip 1.9.1e .zip sha256: 097f2d10589b43bf5882f1e0d06f83740f09ca6f037ae73252eb6c555819b212  nxt-client-1.9.1e.zip NRS 1.9.1e release notes Fixed a client UI bug affecting some form submission. Source: https://nxtforum.org/nrs-releases/nrs-v1-9-1e/ For further information about 1.9 … Read more

Release 1.5.11

Hash: SHA1


bd5054abc528099f890051f92557b9cfbb03f7f891861650b37b9da80ab92eb0  nxt-client-1.5.11.zip


cdde0dc9dcf3f48611785bb8ec1cf91959e87df7ddfc3d740d6439c790502df2  nxt-client-1.5.11.jar

Change log:

This release removes compatibility with peers older than version 1.5, and no
longer accepts connections from them.

Conditional logic dependent on block 445000 has been removed where no longer
necessary, as block 445000 has been passed now.

Parallel blockchain download using 36-block segments is now the default
regardless of height. Returning more than 36 blocks at a time by getNextBlocks
is no longer supported.

The maximum WebSockets message size and the maximum allowed response size to a
getNextBlocks request have been reduced from 192 MB to 10 MB.

A checksum at block 445000 has been added.

Added isDownload field to the getBlockchainStatus and getState API response,
indicating if blockchain download is in progress. This gets set to true when
a batch of more than 10 blocks at once has been downloaded from a peer, and
gets reset to false when an attempt to download more blocks from a peer does
not result in any new blocks added.

The peer requests getUnconfirmedTransactions, getMilestoneBlockIds,
getNextBlockIds, getNextBlocks, processBlock, processTransactions,
getCumulativeDifficulty, are being rejected while a blockchain download is in
progress, as indicated by the above isDownloading property.

The timestamp of the last connect attempt to a peer is now included in the peer
JSON object.

Added a connect parameter to DumpPeers debug API, to force a connection attempt
to each known peer first, adminPassword required if needed.

The run.bat script on Windows no longer uses the -server flag by default.

Updating nodes of version older than 1.5 to this release will delete blocks
after height 445000, to make sure such nodes are not left permanently stranded
on the 1.4 fork.

Version: GnuPG v1


NRS 1.5.11 Windows installer

Hash: SHA1

Windows installer

6f1d248b9c17cacaf62a5faba96d408cd14c8145952e12383580ea10e7d72795 *nxt-client-1.5.11.exe

To verify the installer executable:
Right client the exe file, in the Digital Signatures tab verify the signer name is "Stichting NXT", you can view additional information by clicking the "Details" button.

Version: GnuPG v2.0.22 (MingW32)


Windows 32 bit users can either install from the zip or from the jar. 'Since we decided to distribute a 64 bit JRE there is no point to distribute a 32 bit executable', writes lyaffe.

Nxtforum NRS 1.5.11 thread: https://nxtforum.org/nrs-releases/nrs-v1-5-11/

Release 1.5.10

Hash: SHA1


07737a52c843f10067c77171a89342cc6aa613fc87fc2442eaee71fc6448792b  nxt-client-1.5.10.zip


6735d643893833319222e64ce40a050bf4acd6ca2dd9716bf574d17270b36193  nxt-client-1.5.10.jar

Change log:

Create installer package for Windows and Linux using the IzPack installer.
See https://bitbucket.org/JeanLucPicard/nxt/issue/283

Added separate linux and windows (cygwin) build and release scripts.

Track and log database query execution times. The new properties:
nxt.statementLogThreshold, nxt.transactionLogThreshold, and
nxt.transactionLogInterval can be used to configure logging of slow queries.

Database performance improvements and optimizations. The account leasing data
has been moved from the account table to a separate account_lease table.
More table indexes have been added or existing ones modified.

Improved JSON encoding performance.

Outbound websockets connections are no longer initiated when using a socks or
http proxy (if system property socksProxyHost or http.proxyHost is defined).

Include expired prunable JSON in API transaction JSON, if available.

To protect public nodes from unneeded extra load, the getState API does not
include counts even if includeCounts=true, unless the adminPassword is either
provided as a parameter, or is not needed.

Added numberOfAccountLeases and numberOfActiveAccountLeases to getState,
showing the total number of scheduled (first lease only) or currently active
account balance leases.

Limit peer details length to 10 characters for version, 20 for application,
30 for platform, and 100 for announced address.

Client UI improvements:

Fixed a bug sometimes not showing notification badge after login.

Improved Bulgarian and Slovak translations.

Fix local signing of upload tagged data and approve transaction

This release will perform a full blockchain rescan on first start.

Updated jetty to version 9.2.11. If unpacking on top of existing installation,
delete the old lib folder first.

Version: GnuPG v1


Release 1.5.9

Hash: SHA1


144c9ecfc5d2b3540dec4eb0a5d94ac67a9142645be858236315cfee0777a03e  nxt-client-1.5.9.zip

Change log:

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

Updated some translation files, added Bulgarian and Catalan translations.

Other minor bugfixes and improvements.

Important licensing change:

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

Version: GnuPG v1


Release 1.5.8e

Hash: SHA1


f08df2cc050512f5d49cac62767aa7715b4021db4dccec082d68cad8b55ea9f3  nxt-client-1.5.8e.zip

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

Change log:

This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.

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

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.4.18

Hash: SHA1


05e0357f092e372daa03885489b00255bdf4821c797763e1aac04bfcc2fcacf8  nxt-client-1.4.18.zip

Change log:

This is a bugfix release. Everyone is required to update.

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

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.7e

Hash: SHA1


a5e318ee4422a46f1347891b2b71be7553739b1b768398b82696a011fe2b6d05  nxt-client-1.5.7e.zip

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

Change log:

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

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

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

Client UI improvements:

Implemented client side signing of the tagged data transactions.

Added File Upload form, accessible from the settings menu. Allow extending a
tagged data transaction from the transaction info modal.

Integration of current status of client translations for new 1.5 features,
new "experimental" state for languages with translation status at 40-50%+,
added Czech, Greek, Hindi translations in experimental state, updated translation
state for other languages (Beta: 70-80%+, Stable: 90-95%+).

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.6e

Hash: SHA1


e9733f755961468bd7684862394bd564c1e80c1a7f1af075c490bf9e54a37985  nxt-client-1.5.6e.zip

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

Change log:

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

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

This release will perform a full rescan on test net.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.5e

Hash: SHA1


fdb91461a6b39f7604442d36b341b22692452f60ef1cd329f9254406a8103dec  nxt-client-1.5.5e.zip

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

Change log:

This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.

Fixed processing of unconfirmed ExtendTaggedData transactions.

AddPeer and BlacklistPeer APIs now require POST and admin password.

This release will perform a full rescan on testnet.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.4e

Hash: SHA1


70876b7b78e1494c4d46597ca9d73858e0c6e6484f238d592e0a02b19644607d  nxt-client-1.5.4e.zip

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

Change log:

This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.

Fixed a bug in parsing ExtendTaggedData transaction json which prevents such
transactions from propagating between peers.

Added permanent message option to most send transaction dialogs.

Other minor bugfixes.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.3e

Hash: SHA1

Release 1.5.3e


393a71bc869b7dafb2830eef2d29665f24c7c1c64741f3ecc103a088c4f85ac3  nxt-client-1.5.3e.zip

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

Change log:

This is an experimental release. It is a required update for all testnet nodes,
but is also possible to run on main net.

This update adds the Prunable Tagged Data feature, planned to be enabled at the
voting system block too.

Prunable tagged data are similar to prunable plain messages with no recipient,
but with additional searchable metadata fields added. This feature can be used
for decentralized and trustless distribution of small (up to 42k, including
the metadata) pieces of data, which are by default stored for two weeks only
(24h on testnet), but can optionally be stored longer or indefinitely by some
nodes, and can be verified against the blockchain even after their expiration.

Currently each tagged data can have the following fields, in addition to the
data itself: name (required), description, tags, type, isText, filename.

Name, description and tags are indexed and searchable using Lucene. All data
and metadata is prunable, after pruning only a single 32 byte hash remains.

Fee for either uploading or extending tagged data is based on the total data
size (including metadata), and is 1 NXT for up to 1k bytes, 0.1 NXT for each
1k above, up to the limit of 42k.

New APIs:

UploadTaggedData - create and broadcast new tagged data.

ExtendTaggedData - extend the expiration time of already uploaded tagged data.
If the data is still available, only the transaction id is needed. If not,
already pruned data can be resurrected by including (in addition to the
original transaction id) all of its fields too, i.e. name, description, etc.
Anyone can submit an extension, not only the original uploader. Each extend
transaction increases the expiration deadline by two weeks (24 h on testnet).
Extending an existing tagged data from another account does not change the
original submitter account id by which it is indexed and searchable.

VerifyTaggedData - used to verify expired tagged data downloaded from another
node, against the hash in the current blockchain.

SearchTaggedData - full text search on name, tags, and description, optionally
filtered by submitter account.

GetTaggedData - retrieve tagged data by transaction id.

GetAccountTaggedData - retrieve all tagged data submitted by a given account.

GetAllTaggedData - retrieve all existing tagged data.

GetDataTags - returns the distinct tags of all tagged data, with the number
of data having each tag.

GetDataTagsLike - prefix search of data tags.

GetDataTagCount - the total number of distinct tags.

All the Get* and Search* APIs above can only retrieve tagged data that has
not been pruned yet.

There is no client UI support for any of these APIs. It is expected that
specialized third party plugins will be developed for specific tagged data
use cases, depending on file type and target user group.

Currently the pruning of tagged data is controlled by the same configuration
properties that are used for prunable messages expiration.

Same as with prunable messages, when using broadcastTransaction API to submit
an already signed tagged data upload transaction, the prunable parts must be
in the prunableAttachmentJSON parameter in case transactionBytes parameter is
used. If submitting transactionJSON, it already has the prunable parts.

New debug APIs:

GetAllBroadcastedTransactions - if transaction rebroadcasting is enabled,
returns the unconfirmed transactions that have been broadcasted from this node
but have not yet been received back from a peer.

GetAllWaitingTransactions - returns the unconfirmed transactions that are
currently temporarily kept in memory during transaction processing.

RebroadcastUnconfirmedTransactions - if transaction rebroadcasting is enabled,
causes transactions currently in the unconfirmed pool to be broadcasted to
peers again, until received back.

Other changes and bugfixes:

Improved handling of invalid transactions during block generation. Fixed
validation of AE order cancellation transactions. Fixed a memory leak in
processing of unconfirmed transactions. Set the default limit on waiting
unconfirmed transactions nxt.maxUnconfirmedTransactions to 1000.

The DGS goods delivery data size will be limited to 1000 bytes after VS block.

Bugfixes in prunable messages processing.

Fixed phasing with whitelisted approval accounts.

On testnet, this release will perform a full rescan on first start with
rollback to height 263895.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.4.17

Hash: SHA1


baf2eed8fb1b677b735c04a4b34efc506e8e9a091ae0c66e5dab767a31d60f6e  nxt-client-1.4.17.zip

Change log:

This is a critical bugfix release. Everyone is required to update.

Fixed validation of asset exchange order cancellations.

Fixed excessive memory usage in unconfirmed transaction processing.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.2e

Hash: SHA1

Release 1.5.2e


464e8d6433ed6cc0051e039d60b914b2cd5ec44477a8841571ef4edd313fc3f1  nxt-client-1.5.2e.zip

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

Change log:

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

Added requeueUnconfirmedTransactions debug API.

Added support for uncompressed non-prunable encrypted messages and encrypted
to self messages, as a new appendix version, to avoid the need to specify the
compression status as a request parameter when reading them.

Added setLogging API, to allow changing log levels without having to restart
the server.

Added eventRegister and eventWait APIs, to be used for registering listeners
and waiting for server events instead of polling.

Changed the parameters accepted by broadcastTransaction. The prunable parts
must be submitted either in the transactionJSON, or, if using transactionBytes,
in a new prunableAttachmentJSON parameter, which has the same format as the
transaction attachment json. The prunableAttachmentJSON is also returned by
the signTransaction and getTransactionBytes APIs now.

Added support for prunable plain and encrypted messages in the client UI.

Added optional buyer parameter to getDGSGoodsPurchases API.

Voting system UI improvements and bugfixes.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.1e

Hash: SHA1

Release 1.5.1e


7f56babc8bce1ab12117dea86c0225611bb6eb86796de6c7869438a575523722  nxt-client-1.5.1e.zip

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

Change log:

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

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.


BroadcastTransaction has been modified to optionally accept all parameters that
are needed to create a prunable plain or encrypted message (client side
encryption only). This is required because the data for such messages is never
a part of the transaction bytes themselves, so trying to broadcast a transaction
that has a prunable part by only submitting its bytes to broadcastTransaction
WILL FAIL, unless the corresponding parameters necessary to add the prunable
parts are also supplied. Note that they need to exactly match the original
parameters with which the transaction bytes have been created and signed.

For non-prunable messages, broadcastTransaction behaves as before, but users
are encouraged to start switching to prunable messages in view of the planned
size restrictions and fee increases.

The EncryptedData java class no longer handles compression internally, this is
left to the caller of the encrypt and decrypt methods to do.

Other changes:

GetPolls now supports an optional includeFinished parameter (default false).

Multiple bugfixes and improvements in the Voting System and Phasing UI.

The limit on transaction deadline of 1440 minutes has been removed. It is now
possible to create a transaction with a deadline of up to 32767 minutes. This
has been done because many use cases of phasing require that the transaction
bytes are prepared much earlier than the actual broadcasting of the transaction
to the blockchain.

This release will perform a database upgrade with a full rescan on first start.
On testnet, it will cause a rollback to block 256935.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.5.0e

Hash: SHA1

Release 1.5.0e

da89d5d7641b9dcfba725ad618fd5b98da39254d7bcdad129c2affcc9a3826e8  nxt-client-1.5.0e.zip

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

Change log:

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

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

Updated Jetty to version 9.2.10 and Bouncy Castle to version 1.52. If unpacking
on top of a previous installation, delete the old lib folder first.

This release will perform a database upgrade with a full rescan on first start.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.4.16

Hash: SHA1

Release 1.4.16


6ef76c029d96b9c689298ba1c43f561417779ac6796f94ebdff6b10a93ff871b  nxt-client-1.4.16.zip

Change log:
Updated jetty to version 9.2.9 due to a critical security bug:


There are no code changes, only the jetty libraries have been updated.
Delete the old lib folder before unpacking on top of a previous installation.

Version: GnuPG v1.4.12 (GNU/Linux)


Release 1.4.15

Hash: SHA1

Release 1.4.15


17bd3776a5c603fc347e4e492d540d721024f540a8ee29ef40a90b1dfee1d121  nxt-client-1.4.15.zip

Change log:

Possible fix for the invalid CurrencyMint counter exception.

Made URLs in descriptions clickable and fixed potential XSS exploit problem.

Version: GnuPG v1.4.12 (GNU/Linux)



Release 1.4.14

Hash: SHA1

Release 1.4.14


dca307494ebf4053572cf02273c76e8046f352f604f834f47360274cca39a70a  nxt-client-1.4.14.zip

Change log:

Added debugging output for failing currency mint transactions.

Reduced default numberOfForkConfirmations to 2.

Version: GnuPG v1.4.12 (GNU/Linux)



Release 1.4.13

Hash: SHA1

Release 1.4.13


58ab52f0e49e344fde5f2ba7447c43d1f3ab5ff3aaad9c93ba4900bd55ba41ed  nxt-client-1.4.13.zip

Change log:

Peer networking improvements, better logging, bugfixes.

News page now loads correctly when the wallet uses https.
Nxt forum message updates are displayed instead of new topics.
Feed refresh is performed whenever the news page is refreshed.

Minor UI bugfixes.

Version: GnuPG v1.4.12 (GNU/Linux)



Release 1.4.12

Hash: SHA1

Release 1.4.12


cbfe586bc4459efda5f973f32e0c9d8dcef222d9695092aa5b0dcab3c518ec9e  nxt-client-1.4.12.zip

Change log:

Improved fork resolution by allowing a better difficulty block pushed from a
peer to replace the current last block.

When forging, do not accept a peer block with hit time after the next hit time
of a currently forging account (i.e. prevent front-running in forging).

Removed the possibility of a forger to miss his turn. Even if late, the block
will still be generated and submitted.

Delay forging and submission of blocks by 20 s, configurable via the
nxt.forgingDelay property, in order to be able to accumulate more transactions
in the forged block. The arrival of a front-running block from a peer however
cancels that delay and the next block is generated up to 3 s earlier instead,
which can be controlled via the nxt.forgingSpeedup property.

The above time shifts apply to the physical time of block generation and
submission only. Block timestamps are always fixed by the forging algorithm
within 1 s accuracy, and are not possible to modify.

Better logging of peer networking errors. Log, but do not blacklist missing or
malformed JSON responses.

UI for adding and blacklisting peers. Blacklisting from the UI is possible
only when admin password is not needed (disabled or running on localhost).

Database optimization. Moved the public key of accounts, transaction senders,
and block forgers to a separate table, resulting in 15% reduction of total
database size. This change will be performed at first start and will take some
time. A shutdown after the first start is recommended to compact the database.

Forging API improvements: getForging and stopForging now allow access using
admin password instead of account secret phrase. This respectively retrieves
the status of, or stops the forging of, all currently forging accounts. As
with other admin password protected APIs, password is not required when the
API server is listening on the localhost interface only. The getState API now
also returns a needsAdminPassword boolean, to indicate this.

Enforce that the nxt-default.properties file used matches the version of the
current release.

Added currency distribution dialog invoked using a link from the currency
transaction info dialog.

Version: GnuPG v1.4.12 (GNU/Linux)



Release 1.4.11

Hash: SHA1

Release 1.4.11


c821163d386304e0c5e12ad217e9d28eeb34ad79062b3fb01c772fbfe9071d46  nxt-client-1.4.11.zip

Change log:

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

Version: GnuPG v1.4.12 (GNU/Linux)



Hash: SHA1

Release 1.4.10


114349601aa8bf9f700a99963677d61ce98cc7fa545295fefea7b44ed2a3beaa  nxt-client-1.4.10.zip

Change log:

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

Improved database performance by storing currency supply and reserve per unit
data in a separate table.

This release will perform a rescan on first start.

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

Version: GnuPG v1.4.12 (GNU/Linux)



Hash: SHA1

Release 1.4.9


60137e4b1e3c89a3f646d979d0959cea3caecb9f76ada1a0f4f1fdd104370514  nxt-client-1.4.9.zip

Change log:

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.

Added nxt.mint.stopOnError property, default false. Minting will now continue,
by default, even after an error occurred when sending the mint transaction to
the server.

Minting transactions are now signed locally and sent to the server using the
broadcastTransaction API. Thus the secretPhrase for the minting account is never
sent to the server, and the server or the connection to it do not need to be
trusted. The secretPhrase is also not logged to the log output anymore.

User Interface
Added second row of info boxes on Dashboard.

Notifications for incoming messages.

Reworked page navigation.

Account leasing dialog now displays the number of blocks until lease expiration.

Fixed named account links on the transaction info dialog.

Client Translation
Added language selection to welcome screen.

Added translations for monetary system for different languages.

Stable: English, Spanish, French, Lithuanian, Portuguese (Brazilian), Russian,
Chinese (Simplified), Chinese (Traditional)

Beta: German, Finnish, Galician, Croatian, Indonesian, Italian, Japanese, Dutch,
Slovakian, Portuguese, Serbian (Cyrillic), Serbian (Latin), Ukrainian

Version: GnuPG v1.4.12 (GNU/Linux)


A few upcoming Nxt features explained

True to form, the NXT Core Developers continue to deliver groundbreaking new features for Nxt.

Because of their uniqueness and many possible use cases, I am especially excited about these ones (expected to be released within the next few months): the Monetary System, Voting System, and 2-phased Transactions.

Monetary System

UPDATE: Nxt Monetary System is released 

The Monetary System is the feature closest to being released and, at the time of writing, it will be brought to the mainnet at block 330000 (roughly Jan. 10th). This is a way for anyone with a few NXT to create a fully fledged digital currency. MS has a unique property: namely its ability to mint currencies. Minting is very similar to mining with the key distinction that it is used solely for the distribution of a currency and the MS currency doesn’t need to rely on its miners for blockchain stability unlike the typical alt-coin.

The minting property has four main advantages:

  1. It helps miners of other cryptocurrencies to feel at home on a PoS system like Nxt.
  2. There is a steady and ongoing distribution and therefore now a way for minters to create value on Nxt’s blockchain, thereby providing another powerful answer to the negative comments often made about Nxt’s initial distribution (to stand alongside this one: the supposedly unfair distribution was, in fact, a deliberate move to create a sustainable system).
  3. A mintable currency doesn’t depend on the minters for the blockchain’s security, a MS currency that no one mints being just as safe as one with a large hashrate. Every MS currency is backed by the stability of the Nxt network.
  4. With mintable currencies, there will be a way, in effect, to transfer electricity costs into the value of a MS currency which can be directly traded for NXT, allowing for NXT to be exchanged without having to deal with exchanges at all.

Also, MS currencies have the advantage of being controllable and, as such can be pegged, for example, to USD, or backed by gold or silver, thereby helping to ensure a degree of stability. This would bring us closer to solving the common cryptocurrency problem of volatility and allow for an MS currency to be used to purchase items without the fear of drastic price drops or rises.

Voting System

UPDATE: Nxt Voting System is on public testnet, ask for testNXT here.

Next we have the Voting System, scheduled to be released in Nxt version 1.5, once the MS has been fully integrated. The voting system allows for polls to be created, voted in, and counted, all from within the Nxt blockchain. You are also able to weigh the voting, either by the amount of NXT owned, or by the amount of a specific Nxt asset owned. The most interesting subset in my opinion is weighing a poll by the amount of an asset owned.

With this, a number of things are possible:

  1. Asset owners can seek a consensus from asset holders about a specific question.
  2. Assets can be created and distributed in order to create decentralized voting committees that are given polls to vote on created by any member in the community.
  3. Polls can be created without fear of a Sybil attack (one person pretending to be many people to vote more than once) because one person with, for example, a holding of 100 jl777hodl has the same voting weight as 100 people who each have a holding of 1 jl777hodl.

Also see: Nxt Voting System Teaser Video


UPDATE: Nxt Phasing is on public testnet, ask for testNXT here.

Finally we have the most abstract of the soon-to-be-released features: 2-phased transactions. This doesn’t yet have a definite release date, but will hopefully be launched around the same time as the Voting System, as parts of it rely on VS.

2-phased transactions are Nxt’s implementation of multisig, but extend the definition of multisig to include many more functions and use cases. Basically, a user is able to define a transaction in two phases: the first phase being when the details of the transaction are defined (e.g. the amount of NXT to send and the recipient), and the second being when the transaction is released into the system. 2-phased transactions will also enable the account-holder to make a transaction dependent on the results of a poll. This greatly widens the range of possible use cases of 2-phased transactions:

  1. Asset holders can now vote to veto or accept payments made by the asset issuer or company on whose behalf the asset was issued.
  2. Trust-less escrow is possible by phasing two transactions in parallel.
  3. Joint accounts can be run with ease.

As these features become operational, thereby allowing people to have control over making their own currencies, polls, and phased transactions, the use cases of Nxt as a platform will start to increase exponentially and Nxt will have moved still closer to achieving its goal of being a viable decentralized economic platform.

Nxt is in the process of giving financial power back to the people. With this power in their hands, who knows what will be created next.

Other links:

The Nxt [CORE] article series
Nxt – The Economy Platform – Usecases for everybody

Nxt Monetary System NRS client 1.4.8

UPDATED January 11, 2015 (details below)

Get the client.
NRS installation tutorial here.
A guide to the NRS Client interface is found here, or watch the video tutorials.

Read more about Nxt Monetary System

Latest NRS client: 1.4.8

Hash: SHA1

Release 1.4.8


253b2b2cdafbe80627997bfebc3c667ec4df80d0435f8e5e5e472cb27d9bbfe4  nxt-client-1.4.8.zip

Change log:

Removed some validations and logic no longer needed after the Monetary System

Added a checkpoint at block 330000.

Various minor UI bugfixes.

Fixed currency search. Fixed handling of very high minting difficulties.
Fixed concurrency issues with Scrypt minting, can use multiple threads now.

Allow use of https for submitting minting transactions, set
nxt.mint.useHttps=true. Note that this will accept any SSL certificate as valid,
therefore will not protect you against man-in-the-middle attacks when minting.

Allow no more than one unconfirmed minting transaction per account and minted
currency to be accepted in the unconfirmed pool.

Improvements in translations handling, documented in DEVELOPERS-GUIDE.md.

Better validation of hallmarks for peers with multiple addresses. Do not
blacklist peers with invalid hallmarks but just treat them as not hallmarked.

Blacklist peers with versions older than 1.4.

As more than 720 blocks have passed since the MS block, nodes older than 1.4
are now on a fork that will not be resolved by itself. To fix that, upgrading
such nodes from a version older than 1.4 to this release will cause deletion
and full download of the blockchain.

Version: GnuPG v1.4.12 (GNU/Linux)



UPDATED, January 6, 2015 :

NRS client: 1.4.7

Hash: SHA1

Release 1.4.7



1965173efb65925828a629154a404782e3a9ad9d3e64e7093bf78734342825d3  nxt-client-1.4.7.zip

Change log:

This is a mandatory update. Everyone should update to 1.4.7 or later before
block 330000.

The Message Pattern in AccountInfo feature, introduced in 1.4.0e, has been
disabled, and will not be activated at block 330000. This is to prevent
possible denial of service attacks by malicious regular expression patterns
which can cause excessive CPU load with certain inputs. This feature will
probably be introduced again in 1.5, but with a predefined set of allowed
well behaved regex patterns.

Multiple minor UI improvements and bugfixes.

Enhanced nxt.allowedBotHosts property to also accepts a range of addresses
using CIDR notation.

This release will perform a rescan on first start, on testnet only.

Version: GnuPG v1.4.12 (GNU/Linux)


UPDATE, January 01, 2015: NRS 1.4.6

Hash: SHA1

Release 1.4.6



817445f7407e0f4e3eb43163e53c9eb2eb46804ee4be3d107c9d8fb229ce2901  nxt-client-1.4.6.zip

Change log:

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

Version: GnuPG v1.4.12 (GNU/Linux)


NRS 1.4.5 

Hash: SHA1

Release 1.4.5



9292e785c394cb951fc7bf26160137a00896e59764439455abca0da580bb5758  nxt-client-1.4.5.zip

Change log:

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

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

Version: GnuPG v1.4.12 (GNU/Linux)


You can test Nxt Monetary System on Nxt testnet.

For more information see

To verify SHA256:

To verify GPG software fingerprint:

Also you can verify the signed post from Jean-Luc matches his GPG fingerprint:


Nxt [CORE]: Monetary System

Nxt’s Monetary System allows users to create new decentralized currencies on top of the secured Nxt blockchain. New coins are highly customisable, with a wide range of parameters that can be set to govern their properties and use.

The Nxt Monetary System (MS) enables the launch of altcoins without going through the trouble of bootstrapping the currency with its own blockchain and network, thereby removing a major impediment to easy, real-world adoption and use of different customized cryptocurrencies.

The ultimate value of a new coin is determined by the market, depending on adoption and demand, and by the parameters set by the issuer. However, coins may also be created by ‘locking’ a certain amount of NXT, thereby giving a floor value to the issued currency at which they can be redeemed for NXT if desired.

With Nxt, new coins are highly customisable, with a wide range of parameters that can be set to govern their properties and use. It is possible to launch an MS coin that is distributed by proof-of-work, but secured by Nxt’s PoS algorithm. It is also possible to create fiat- and commodity-backed tokens for particular real-world applications.

These allow for the creation of bespoke and niche currencies for highly specific applications, crowdfunding coins, ‘regular’ altcoins, reward points, coins pegged to fiat currencies or precious metals, while also being a stepping stone to new future Nxt features, such as p2p loans, meaning that Nxt can become the underlying tech for a completely decentralized banking system.

When? Now!

MS can be explored in the Nxt testnet, ask for testNXT here.

The main net NRS release that will implement the MS System has also been released. Monetary System will be activated with block 330000, and nodes not running 1.4.5 or later will be on a fork.

mscoins_testnetTestnet screenshot

Read an NRS installation tutorial here or on nxt.org.
A guide to the NRS Client interface can be found here – or watch the video tutorials.

Potential impact and significance

Monetary System offers greater exposure to NXT as the machinery that powers financial transactions, over and above its utility as a currency; however, this does not imply that NXT itself will become worthless. NXT remains a ‘decentralised store of value’, with fixed supply. MS currencies may become something akin to a decentralised credit system, meaning that users transact with MS coins but all of them depend on NXT for their ultimate utility.

Of course, this does not mean that MS will not catalyse a shake-up of the NXT ecosystem, providing an impetus for the redistribution of existing NXT wealth, as Come-from-Beyond writes:

‘In the beginning we will have an epoch of instability when hundreds of currencies will pop up every day. After a while some currencies will become more and more popular, but the whales will have their wealth dispersed among thousands and they will get only a fraction of initial wealth in the most popular currency.’

The Monetary System is necessary because different currency properties are suited to different applications. Having a series of currencies that fit the needs of the market are the obvious solution to the one-size-fits-all problems of both fiat and any single cryptocurrency. For example, as Come-from-Beyond also writes:

‘Having a fixed currency supply (like Bitcoin and NXT) isn’t ideal for all situations. Fixed currency supplies make a great ‘store of value’, but they make lousy credit systems. The Monetary System is simply another tool to allow people to create local currencies to break free of centrally controlled fiat.’

NXT will be bought by those looking to create currencies – it will not be used to purchase alternative currencies (as is presently the case).

ChuckOne writes:

‘NXT will have one specific use case only: to enable transactions. Nxt Monetary System is about separating power from economy. So, we can basically move the NXT Economy from this platform to another one if something is wrong with NXT or to penalize forgers if they misbehave.’

MS enables a series of far-reaching developments, including:

  • Coin shuffling. Claimable currency units can be shuffled and returned at the same exchange rate, allowing for anonymous transactions without potential loss of value in the process.
  • Fiat-backed tokens. Once USD, GBP, EUR or other fiat currency-backed coins are trading, it will be possible to send fiat money using the NXT infrastructure. This brings the benefits of speed and very low transaction costs to international money transfers. Unlike with Bitcoin and other cryptocurrency transactions at the moment, there would be no volatility, and exchange rates would be negligible (or zero, since these tokens could simply trade internally within the NXT system indefinitely, until the recipient wanted to redeem them against fiat).
  • Local currencies and exchange trading systems to benefit specific economies.
  • Niche loyalty tokens issued by businesses to reward customers. These tokens would also be freely and globally tradeable, meaning the market would set their value beyond what they could be redeemed for within the business in question.

ms_testnet2The NRS Client exchange, testnet screenshot

Monetary System: specifications

The following descriptions are taken directly from MS documentation as it stands at the time of writing. Documentation may change without notice. Latest version can be found here: https://bitbucket.org/JeanLucPicard/nxt/issue/205/monetary-system-documenation


The ‘Currency’ entity is the basic building block of the NXT Monetary System, currency has a unique name and code and uniqueness is guaranteed by the protocol, currencies can be deleted and their code can be reused under certain conditions.

The total currency supply is divisible into currency units. Like assets, currency units support decimal positions implemented as a client side feature. The maximum number of currency units which can be issued per currency is similar to NXT: i.e. 10^9 * 10^8. The actual maximum units supply is set by the currency issuer. The currency issuer is the account which issues the currency and pays the issuance fee. The issuer is responsible for setting the currency properties and in some configurations has additional control over the currency usage. Like asset balance, currency units can be transferred between accounts.

Currency Properties

The currency entity supports several properties. Properties can be mixed and matched in various ways to compose the currency type. The currency type then controls the inner workings of the currency. The list of available currency properties is as follows:

EXCHANGEABLE – the currency can be exchanged with NXT. Holders of the currency can publish an exchange offer specifying the buy and sell rate of the currency, in much the same way as banks or currency exchanges publish their exchange rates. Each account can publish only a single exchange offer at any given time. Exchange offers have an expiry block after which they are no longer in effect.

Buyers and sellers can issue exchange requests to match published exchange offers. Unlike asset bid/ask orders, exchange requests are not saved, they are either executed immediately (fully or partially) or not executed at all. A match of exchange offer with a buy or sell exchange request creates an exchange entity which represents the transfer of currency units, in return, to NXT balance and causes the relevant account balances to update. Issuing an exchange offer reduces the NXT and currency balance of the offering account temporarily until the offer expires. Exchange offers also specify a limit on the number of exchanged units which can be larger than the number of units offered. When a buy exchange request matches an exchange offer the number of units offered for sell is reduced and the number of units offered for buy is increased as long as the limit has not been reached. Once the exchange limit of an exchange offer has been reached, this exchange offer can no longer be used.

CONTROLLABLE – currency property suitable for currencies which need to track an external entity. It imposes the following limitations on the currency: (1) Currency can be transferred only to/from the issuer account (2) only the issuer account can publish exchange offers. The issuer account can issue a large (practically infinite) supply of units in advance, then transfer units to accounts, or offer to exchange units, to reflect actual transactions which take place in an external system. The large supply of units in the issuer account can be used to mimic the effect of creating units out of nowhere to support features such as creating new units and interest payments.

RESERVABLE – currency units are not issued immediately. Instead the currency issuer sets a block height by which the currency is to be issued and a limit of NXT per unit needed in order to issue the currency. Currency ‘founders’ then spend their NXT to reserve their currency stake. If the amount of NXT per unit needed in order to issue the currency is not reserved before reaching the block height the issuance is cancelled and funds are returned minus fees. If the required reserve is allocated, the currency is issued and units are split between founders according to their proportional stake of invested NXT. In case of rounding, leftovers are sent to the issuer account. See below for a discussion of usage scenarios for Reservable currency.

CLAIMABLE – currency units of reservable currency can later be claimed at the same NXT per unit rate reached when reserving the currency. The ability to claim a currency at a certain rate imposes some practical limits on the rates at which users would want to exchange it. However claimable currency can also be exchanged if only for the purpose of exchanging the whole currency supply, so that the currency can be deleted.

MINTABLE – currency can be minted using proof of work algorithms in much the same way as Bitcoin. Unlike Bitcoin mining, minting currency does not secure the network (this is done by NXT). Minting is used solely for creating new currency units and serves as the only mechanism to increase the number of available units after the currency issuance.

NON_SHUFFLEABLE – this property indicates that in the future this currency cannot participate in coin shuffling. By default currencies are allowed to participate in shuffling.

Properties are combined into an Integer bit mask designated as the Currency type.

Currency Exchange

For exchangeable currency, each currency holder account, can publish a single exchange offer specifying the buy rate and sell rate vs NXT and the number of units she is willing to exchange (which cannot exceed her available currency units and NXT balance). Users can observe all currency exchange offers (intuitively similar to fiat exchange offices) and try to match them with buy/sell exchange requests. An exchange offer has an expiration height, as well as a limit on the total number of units which can be exchanged. When units are bought from an exchange offer the number of units to sell increases automatically and vise versa. The publisher can also limit the total transaction volume of currency units traded for a specific exchange offer.

Deleting a Currency

Since the available currency codes are limited to 3, 4 or 5 uppercase letters, the total number of codes is limited to 26^3 + 26^4 + 26^5 – 1 = 12355927 unique values (The code “NXT” is reserved), it is likely that some of these codes will have value in themselves. Therefore deleting a currency is possible under certain conditions depending on the currency type. Users may re-issue a currency, or delete a currency and then issue a new currency, with the same code but with different properties. In order to delete or re-issue a currency an account must poses all the currency units (and additional conditions apply based on the currency type)

Creating new Currency Units

The only way to create new currency units after issuing a currency is using proof of work minting. Other methods of creating units are susceptible to denial of service attacks and/or sock puppets and are therefore not allowed. The controllable currency type provides a partial solution for creating new units, by allowing the currency issuer account to treat her supply as a treasury and only consider units outside of this account as the total currency supply. This approach requires users to trust the currency issuer which can increase the currency supply at any time.


Users can issue minting requests in order to mint additional currency units. Each minting request triggers a hash calculation based on the submitted data and the currency hash algorithm. The resulting hash code is compared to the target value derived from the current currency difficulty. Minimal and maximal currency difficulty values and minting algorithm are specified when issuing the currency and cannot be changed later. The expected number of hash calculations (i.e. difficulty) of minting the first unit is 2^minDifficulty while the difficulty of minting the last unit is 2^maxDifficulty. Difficulty increases linearly from min to max based on the ratio between the current number of units and the total supply. Difficulty increases linearly with the number of units minted per CurrencyMint request, small minters can mint only a few units per request while large minters can mint large number of units per request.

The number of units per minting request is limited to 1/10000 of the total unit supply. Minting is limited to a single minting transaction per block/account/currency. Currency issuers can specify initial supply of units as a ‘pre-mint’ supply assigned to the issuer account then use crowd funding by making the currency RESERVABLE and EXCHANGEABLE.

Once the currency becomes active the delta between the current supply (reserved supply) and total supply can be minted. The NRS provides a Java based, reference implementation minter, which can be used for minting. In practice we expect users to enhance this minter to calculate hash codes using their Asics or GPUs, trying to match the current target, and when solving a hash, to submit a currency mint transaction (thus paying a fee).

However the hash code is smaller than the target, the currency units are credited to the sender account.

See the documentation for the reference implementation ‘Mint Worker’ utility here #207

Store of Value

The combination of RESERVABLE and CLAIMABLE properties can be used to allocate initial value for a currency by locking NXT. Once the currency is activated the reserved NXT are locked and the only way to release them is to claim back the currency units in return for NXT. This provides the currency with a value based on the locked NXT balance. Note: locked NXT do not participate in forging, therefore, in theory its possible that a large amount of NXT becomes locked as a currency store of value thus reducing the amount of NXT used for securing the network; we are aware of this problem and will monitor it closely. We do not expect this to become a major problem any time soon.

Crowd Funding

The combination of RESERVABLE and EXCHANGEABLE properties can be used for crowd funding; in this configuration the NXT balance reserved by founders is not locked, instead it is sent to the currency issuer account once the currency becomes active. The issuer can use these NXT for its operations and the founders cannot claim back their currency units, only exchange them based on the published exchange offers. Currency issuers can specify the initial supply as ‘pre mine’ and the founders get to share the difference between the reserve supply (also named ‘pre-activation’ supply) and the initial supply.


Currency issuance fee is based on the length of the currency code:

3 Letters – 25000 NXT

4 Letters – 1000 NXT

5 Letters – 40 NXT

Re-issuing an existing currency with different properties costs 40 NXT regardless of the currency code length. All other currency transactions (as of today) have a fee of 1 NXT.

Unit conversion

Currency is measured in units and like assets has decimal positions, however the blockchain maintains currency balances as a whole number (QNT). Therefore, for example, in the case of a currency which has 2 decimal positions and the client has reserved 123.45 units, the ‘units’ value submitted in the API call should be 12345. APIs using NXT balances should send the value measured in NQT as usual. When specifying ‘rate’ in the API, it calculates the ratio between NXT balance in NQT and currency balance in QNT.

Example: For a currency with 2 decimal positions. When submitting a buy exchange request for 12.34 units at a rate of 5.6 [NXT/Unit] the values submitted to the currencyBuy transaction should be: units = 1234 i.e. units without decimal position or 12.34 * 10^2 rateNQT = 5600000 i.e. rate converted to NQT then divided by decimal position or 5.6 * 10^8 / 10^2

In order to prevent rounding problems when submitting information to the server, the UI enforces the following rule: If a currency has D decimal positions. Unit values cannot have more than D decimal positions and rate values cannot have more than (8-D) decimal positions. Therefore when issuing a currency, we do not recommend specifying more than 4 decimal digits so that conversion rates are also divisible to at least 4 decimal digits.


  1. Before issuing a currency we recommend issuing a currency with the same properties on the testnet and experimenting with all parameters since these cannot be changed without deleting the currency.
  2. This documentation reflects the actual code implemented as of this date.

API Documentation

This section is relevant to API and client developers.

Nxt Monetary System is only one Nxt CORE feature.

Read other articles from the Nxt [CORE] article series.

Also see: Nxt – The Economy Platform – Usecases for everybody

Nxt [CORE]: Marketplace

Nxt Marketplace (formerly known as the Digital Goods Store, or DGS) is a decentralized mall created for buying and selling digital goods. Like the Asset Exchange, it is built into the Nxt client and enables direct peer-to-peer trading. Although it was designed for buying and selling digital merchandise – music, ebooks, software, and so on – physical items have also been listed for sale.


The Marketplace was a planned feature from the start, detailed by Nxt creator BCNext before Nxt was launched. As BCNext remarked, the workflow is relatively simple:

1] A developer sends a message describing a product (it’s stored on the blockchain).
2] A user sends a payment to the developer’s account.
3] The developer sends an encrypted message with a link or a code (stored on the blockchain as well).
4] The user decrypts the message and uses the code to unlock premium in the application. *

Key points

1] Developer publishes their account on their webpage to prove they are the legitimate owner (or uses Reputation System of NXT).
2] All actions are public and can be audited (the encrypted message can be audited if one of the parties reveals the key).
3] Only transaction fees are charged, 100% profit goes to the developer.
4] No one can shut the store down nor they can DDoS it.

(* Note: ‘to unlock premium in the application’ means, in effect: to obtain the product).

Nxt’s decentralised Marketplace was released at block 210,000, on 1 August 2014.

Using the Marketplace


Now, large parts of the workflow described by BCNext have been automized in the NRS client.

You can list your digital (or physical) goods with ease, set a price, change or cancel the listings if you wish, and communicate safely with your customers through encrypted private messages on the Nxt blockchain. Costs are limited to the transaction fee and the cost of exchanging messages (both currently 1 NXT). Listing and selling goods through the Marketplace is free, except for transaction fees.

Buyers are able to search goods by issuer ID (account), item name or by tag (category). Buyers can set an order expiration date, and also leave private or public feedback after receiving the product.

There is a video tutorial available here.

3rd party use cases

The launch of Nxt Marketplace was met with great enthusiasm in the Nxt Community, but since then relatively little community energy has gone into developing it further. There are few user-friendly solutions (like Secureae.com for the Nxt Asset Exchange).

Melodius.me is the most promising announcement so far.

Due in Q1 of 2015, Melodius is a website for independent artists, built on top of the Nxt Marketplace. A partnership with crypto exchange CCEDK allows users to buy and sell their music, concert tickets, merchandise and shares not only with cryptocurrency (NXT and BTC) but also with fiat money in their local currency.

This significantly enhances the buying process, since Nxt remains very much in the background. The attraction for indie artists is the low commission fees; whilst iTunes and Google Play take substantial percentages of artists’ sales, Melodius charges only the standard transaction fees required by Nxt Marketplace. Every penny earned goes directly to the artist. Interestingly, the CEO of CCEDK, Ronny Boesing, worked in the music industry for many years, selling music around the world for major brands. His partnership with Melodius brings together two areas of interest and expertise.

A possible concern with having a decentralized and unregulated global marketplace may be that it attracts people seeking to circumvent the laws of their particular country. Nxt has chosen not to censor goods, but 3rd party sites like Melodius.me can easily filter listings according to their niche, their users’ choices or their local laws.

When buying and selling goods online there is, as in the real world, a chance of getting scammed. There are far too many sad stories about people (and not all of them anonymous) in the crypto world who turned out to be scammers. The solution is to be on your guard at all times, preferably only deal with people you know, always do your due diligence and, if possible, use a trusted escrow for larger transactions.


There is currently no escrow or reputation system implemented in the Nxt core (Reputation System is a feature planned for future development), but a solution for 3rd party clients or websites could be to implement CONCORDE, the escrow system developed by blackyblack, which is currently being tested on Nxt Testnet. Concorde will be included in the next release of FreeMarket, a 3rd party marketplace built on top of Nxt’s Arbitrary Message feature, but can be integrated into any Nxt system.

If you you want to help with the testing, make yourself known in this thread: https://nxtforum.org/freemarket/ann-concorde/, where further information about how Concorde works can also be found. Concorde is open-source and a direct download link can be found in Concorde’s nxtforum thread. As blackyblack writes:

‘It is an escrow system opened for all NXT users. Feel free to build your own projects on top of it or use for your daily needs.’


At present, Nxt Marketplace is being used, but mostly through the Nxt NRS Client. It remains a hidden gem of Nxt: an almost undiscovered secret, ready to be put to wider use.

A few listing sites are available, which detail all the goods for sale on Nxt Marketplace; users can see and search the goods, but everything must still be bought and sold with a Nxt Client. An example of such a listing site is http://jnxt.org/market/.

The goods sold are up to the imagination of the sellers. A house has been put up for sale, ebooks and articles are sold, domains, oil paintings, screensavers, a NXT faucet organised (NXT-55AK-82KK-DK3Q-6U4RN), crowdfunding has been attempted, NXT node operation services arranged (NXT-9TNK-QXJ6-YPMY-32CTA), NXT lapel pins (NXT-WBFF-3UMJ-RMLD-7VWS4) are available, even home-made maple syrup is offered (118670936523580125). Also, Nxter.org has its own store, NXTER STORE (NXT-EAVH-SLEV-KSEE-EE2KP).

The low fees and decentralized nature of Nxt Marketplace mean that it can solve real problems, not least for writers, musicians, developers and other digital content creators. Nxt Marketplace can easily be made the backbone of an app store, a decentralized crypto exchange, a subscription-based payment system for magazines, game updates, or even a full-featured crowdfunding platform. Only the imagination of the developer – or the business ordering the use case – sets the limits.

As one new Nxt developer wrote in early March 2014, ‘This [Nxt] is almost like building with lego bricks again’ – this person ended up coding SuperNET.

Nxt Marketplace is only one of the Nxt [CORE] features available.

Read other articles from the Nxt [CORE] article series.

Also see: Nxt – The Economy Platform – Usecases for everybody

Monetary System on public testnet


December 23, 2014, 07:40:06 pm

If you use testnet, an upgrade to this release is required, otherwise your node will stay stuck at block 161375.

Hash: SHA1Release 1.4.3ehttps://nxtforum.org/nrs-releases/nrs-v1-4-3e/

ac54498c9246593d3aab6f5a2b6f651baa08851856dc0d70402048925f4269f3  nxt-client-1.4.3e.zip

Change log:

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 search for currencies based on code, name, or description keywords.

Fixed bugs in unconfirmed balance handling in currency exchange and currency

This release will perform a rescan, on testnet only.

Version: GnuPG v1.4.12 (GNU/Linux)



Hash: SHA1

Release 1.4.2e


85d5a5dc18a4ab603657da4cf77d39aa31e723e11971f0cdecf77c128a0ef420  nxt-client-1.4.2e.zip

Change log:

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

Version: GnuPG v1.4.12 (GNU/Linux)



Hash: SHA1

Release 1.4.1e



2777a11b701170d7decc01bb82a9049abc37bd293374f852d1810c8195d9842b  nxt-client-1.4.1e.zip

Change log:

This is a bugfix release following 1.4.0e.

Fixed Currency Exchange Booth not working. Fixed currency decimals issue.

Fixed minor bugs in MS transaction validation.

Show total alias count in aliases page. Alias deletion and dividend payment
UI fixes.

Version: GnuPG v1.4.12 (GNU/Linux)



Nxt NRS 1.4.0e

This is an experimental release!


Hash: SHA1

Release 1.4.0e



9322c03f7e9ddc97278de25a4f14006f00d0c88974c10fabef8d3f031f1aa668  nxt-client-1.4.0e.zip

Change log:

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

New features:

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

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

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

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

API changes:

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

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

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

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

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

Internal changes:

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

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

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

Improvements in the processing of unconfirmed transactions.

This release will perform a rescan on first start.

Version: GnuPG v1.4.12 (GNU/Linux)


NRS release 1.3.5


Hash: SHA1

Release 1.3.5



53ae6b17052024e7f1b8d1eba898f4e67f7f4ccf5dc80a6edc89aded826c9a76  nxt-client-1.3.5.zip

Change log:

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

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

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

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

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

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

Include cumulativeDifficulty in the block JSON.

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

Allow sending messages with no recipient.

Automatically blacklist peers with version older than 1.2.0.

UI improvements of the API /test page.

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

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

Version: GnuPG v1.4.12 (GNU/Linux)


Nxt [CORE]: Arbitrary Messages

The Arbitrary Message (AM) feature enables Nxt users to send small amounts of data to the Nxt blockchain. A simple concept in theory, but the applications for this feature are extensive.

Arbitrary Messages commonly take the form of SMS-length communications between users. This was the first application and is still one of the most popular uses for AMs, but the term ‘message’ is a loose one: as well as being used to send public or encrypted text messages to each other, AMs can also be used to send up to 1,000 bytes of any form of data.


At its simplest, messaging involves sending a string of text from one NXT account to another. These messages can be viewed within the client. There is also an option to encrypt messages. If they are left unencrypted, they can be read by anyone since the blockchain is a public record of every transaction. Like a regular transaction, AMs are subject to standard tx fees – currently 1 NXT.


There are, of course, many valid use cases for unencrypted messages. A famous example is the AMs sent to the hacker who stole 50 million NXT from BTer’s hot wallet on August 15, 2014, or jl777’s use of an AM to cancel the SuperNET deal with CoinEVOLVE after the dev created a series of scam assets and went missing in action. You can view a list of all blockchain messages here.

Although transactions on the blockchain are meant to form a permanent record, AMs are intended to be removable. In the future, when the blockchain has grown and needs to be slimmed down to ensure its sustainability, messages may be pruned. Nevertheless, they form a critical building block in NXT’s second-generation functionality, underpinning a series of features.


At the most basic level, the AM system can be used to transmit human-readable messages between accounts, creating a decentralised chat system. However, advanced applications can use this feature to store structured data, such as JSON objects. These can be used to trigger or facilitate services built on top of NXT.


The idea of a Twitter clone based on NXT messaging has been around since the earliest days of the platform. Nxtmemo (https://nxtmemo.com) is a straightforward version of this idea.

You can add your nxtmemo profile to the blockchain, and BBcodes are available for showing images, links, medialinks, etc. Log into your nxtmemo account with a NXT token to choose your display name – it must be a NXT alias that belongs to your account. Simply send your unencrypted messages to NXT-W6CT-NPDH-AAQW-HWCHA to have them show up on the site.


NXTMemo is free and open source, and is created and maintained by toenu. See more on the NXT forum.



Cryptamail is a project created at Techcrunch Disrupt NY 2014 by a group of five developers, led by Kushti (now a Nxt core developer). The goal was to create a user-friendly decentralised email client with Alias-based identification. Although not currently in active development, Cryptamail is still running on the NXT testnet. It’s at cryptamail.com.

Read more about this proof-of-concept on the Nxtforum.



The Multigateway (MGW) is Nxt’s distributed cryptocurrency exchange – the least centralised such service currently available anywhere.

The primary use case for AMs in MGW is the automated deposit and withdrawal of bitcoins and other supported cryptocurrencies. These are held on MGW’s secure servers and exchanged for tokens representing each currency in the Nxt Asset Exchange, allowing for direct peer-­to-­peer trading. There are three separate servers, at least two of which have to agree for a transaction to take place – making it vastly more secure than traditional exchanges.

Essentially, MGW creates a deposit address for the Nxt user account for each of the supported coins. When the user sends coins to that deposit address, MGW delivers to the associated Nxt account the same quantity of coin assets (designated mgwBTC, mgwLTC, etc). Each of these assets represents one coin. Coin assets can then be traded on the NXT Asset Exchange like any other asset. MGW uses a similar process in reverse to withdraw coin assets back into the user’s own coin wallet. The requests to the MGW servers are broadcasted to the Nxt blockchain as Arbitrary Messages.

Multigateway was originally a plugin to the Nxt NRS client from NXTservices. It has now been incorporated into the SuperNET client v.0, in the form of a modified Nxt client that can be downloaded from the Multigateway site.

You can read more about the Multigateway here.


Helix is a standalone cross-platform financial analytics and visualisation client. As a part of FinHive, a powerful distributed financial analytics initiative that is the backbone of SkyNET, Helix has the ability to learn. A small apps store for financial tools will be included in the client, not only for crypto but also for traditional traders. The Helix client includes a distributed computation module to provide BOINC-like functions, tailored towards the financial industry.

Helix uses AMs as data containers to store whole apps. Developer nexern explains:

‘The multilayer perceptron app is 2.3 kb in size and chunked into 3 AMs. You can see the compressed and encrypted perceptron (and tetris game 4 AMs) in the blockchain here

Helix simply loads, concatenates, decompresses and decrypts these AMs directly from the blockchain, where they are stored, into memory. The process takes just three seconds. No disk space is needed. It is a fast, clean and secure solution which has a number of important real-world advantages:

  1. It makes apps very independent and robust against attacks.
  2. It provides nearly unrestricted access from anywhere due to the decentralised storage.
  3. It provides on-the-fly autorepair/update capabilities.

For example, if an app is broken due to an outdated API link, Helix can look for additional update/repair resources by scanning AMs and looking for the current app id. Where higher resource stamps are found, they can be added while Helix is running.


Helix will be used by FinHive, a wholly owned subsidiary of SkyNET. You can see FinHive’s roadmap here.

Read more on the Nxtforum.



As a result of its versatility, AMs can be used to build a vast range of projects, from simple messaging apps to file-sharing services, decentralised applications, and higher-level NXT services.

NXT is in ongoing and constant development, and changes to the core can always be proposed by the community. One of the topics currently being discussed about the AM feature is adding a standard for multipart messages or increasing the allowed message length, as new projects have started to link AMs together so they can save more data to the NXT blockchain. You can join that discussion on the Nxtforum here.

Nxt is a versatile, open source cryptocurrency platform. In this Nxt CORE article series we will dive into the main 2.0 features of Nxt. The first article was about NXT, the token itself, the second about Nxt ALIAS system. 

Read other articles from the Nxt [CORE] article series.

Also see: Nxt – The Economy Platform – Usecases for everybody

NRS release 1.3.4


Hash: SHA1

Release 1.3.4

Download here:

1ea2e9f1241fc5e64bf55b58058c8937ece0c558e06d0ab0c163e5270a362965  nxt-client-1.3.4.zip

Change log:

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

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

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

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

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

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

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

UI changes:

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

Version: GnuPG v1.4.12 (GNU/Linux)


Telepathy – inside the black box

SuperNET runs on a platform that makes the most of both NXT’s and BTCD’s powerful features. NXT provides the functionality, BTCD the secure communication. Anonymous transactions are, of course, a major strand of this – take a look at the Teleport article if you want to know more.

Different cryptocurrencies approach anonymity in different ways – typically with ring signatures or mixing. In the case of Teleport, standard denomination addresses are cloned or swept into new ones by the recipient, so that they only ever lead back to one place: the originator. But no matter how sophisticated an anonymous cryptocurrency is, there’s always going to be a weakness. Even if everything on the blockchain is completely obscure, you can still be compromised if someone is monitoring your IP address or that of your recipient.

So the new cutting edge question becomes: How do you send a letter without anyone knowing the address of your recipient – including you?

Distributed Hash Tables

This is the problem that Telepathy, jl777’s anonymity network for BTCD and SuperNET, aims to solve. At its heart, it’s a peer-to-peer network – much like the one used by BitTorrent for file-sharing. These networks pass packets of information between users or nodes. Each node knows of a few others in its vicinity, but not the whole network – which could consist of tens or hundreds of thousands of nodes.

Each time a node receives a packet, it passes it on to those closer to the recipient than itself. In this way, the packet gets closer and closer to its destination, until it finally reaches whoever it’s meant for. No one needs full oversight of the network, and there’s no central look-up table – something that was the death of Napster, since it meant it could be shut down.

These networks use something called Distributed Hash Tables, or DHT. These are not just very fast, efficient look-up tables, they also have some other interesting and useful properties as well. The DHT provides a kind of overlay to the network that nodes use to route packets – this overlay functions like a map and is used by the nodes to pass information on to the next node.

However, although the map is internally consistent, it bears absolutely no resemblance to where the nodes are in real life. Two locations that are next to each other in network space could be in different continents in the physical world – or they could be right next door to each other. It’s a little like the London Underground map, which barely reflects its above-ground geography at all but still enables straightforward travel from A to B for commuters.

Dead drops

This property can be used to route packets anonymously.

All a node has to do is select a location in network space (designated by a NXT public key, as it happens) that is near to itself, as well as many other nodes, but that doesn’t correspond to any given node: a dead drop.

The packet will be routed through the network, peer to peer, getting closer to its destination at each step. It will never reach its destination, of course, because that point doesn’t belong to any node, but it doesn’t matter: so long as the intended recipient handles the packet at some point, it can read the contents. To make sure it does get to the recipient, the node closest to the dead drop sends the packet to all of the nodes within a given distance – perhaps 20 or 30 in all. Since the packets are all encrypted, no one else will be able to see inside – but no one else will know that the intended recipient has read it either.

An analogy might go something like this:

Alice wants to deliver a message to Bob. She doesn’t know where Bob lives, but the two of them have previously agreed a location to which to send the message. The address doesn’t exist, but Bob has suggested it because he lives close by and can be in the general vicinity.

Alice encodes her message with a cipher only Bob uses, and writes it on a postcard. She gives it to a courier and tells him to drop it at the fictitious address in the centre of town. She points the courier in the right direction and off he goes. After a few minutes, he stops a passerby to ask for directions. The passerby again points him in the right direction, and he walks a little further.

A few more stops and sets of directions later, and the courier is standing in the town centre. As he’s looking around for an address that doesn’t exist, he asks directions from a couple of dozen other people he sees there, including Bob. Understandably, none of these people know where the courier is going, but all of them look over his shoulder and read the postcard while they’re talking to him. Bob walks away with his message, but no one else knows that he was the intended recipient, or what the message said.

The Last Mile

This solution – called ‘Telepathy’ because messages are delivered apparently without anyone knowing they’ve even been received – effectively solves the so-called ‘Last Mile’ problem. In the network, packets are routed around from node to node. At the last stage, though, when the packet reaches its destination, anyone monitoring the network could tell who the recipient is. With this system, though, assuming an attacker even has the ability to see what network activity there is (no mean feat in itself), they now have to choose between twenty or thirty different potential recipients. That’s for every packet, whether it’s an anonymous cryptocurrency transaction or a simple ‘hello’ message. The more traffic, the harder it becomes to make useful deductions.

Telepathy has a few other tricks up its sleeve – onion routing before starting normal peer-to-peer transmission, random delays to confuse observers, and so on – but this solution to the last mile problem is what sets it qualitatively apart from its competitors. With the right encryption, no one can read your messages. Now, no one can even figure out who you’re communicating with – or whether you’re even communicating at all.

A closer look at Teleport

Teleport isn’t just the new anonymity technology that powers BitcoinDark. It’s jl777’s complete privacy ecosystem that also forms the backbone of SuperNET (asset ID 12071612744977229797 on Nxt Asset Exchange). So how does it all work?

So-called anonymous coins come in many different forms, but they tend to rely on a limited range of different approaches towards achieving anonymity. One of the most common approaches is mixing, which essentially means combining a lot of different transactions so that it’s hard to know which output originates from which address. For example, Darkcoin uses an implementation of CoinJoin, a mixing protocol.

Another approach is to use ring signatures, like Boolberry or Monero. Whereas most transactions are signed by one key, with a ring signature a number of different keys can sign the same transaction, so it becomes far harder to know who sent the transaction in question. Ring signatures arguably offer a greater degree of privacy but they come at the cost of considerable blockchain bloat – though Boolberry’s developer has found a neat way to sidestep this issue.

Mixing offers what might be called ‘personal level’ privacy – good enough for many day-to-day circumstances. Ring signatures are a step up from that and can be very effective (hence BBR’s inclusion in the core of SuperNET). But even there, some correlations might be made by a determined attacker.

Teleport: a new approach

Teleport uses a completely different approach to anonymity. Like many of the best ideas, Teleport is elegant in its simplicity – it’s just that there are complex concepts to negotiate along the way. Instead of looking for a way to obscure the source of a transaction, Teleport considers the methods by which an attacker might find out who is sending a transaction and aims to avoid them altogether. To explain further:

Transaction linkage. With Bitcoin, every address can be linked to the one used before it, right back to the block from which it was mined. If you know the identity of the owner of one address or take an interest in the activity which a certain address displays, you can follow the transactions to and from it – and very likely eventually link that person with another known address. Teleport avoids this by using one-time addresses called telepods. If no address is used more than once, it’s impossible to link it to any other part of the network. In the original Bitcoin white paper, Satoshi Nakamoto recommends using new addresses for every transaction. Suffice to say that few people do so because it’s too much trouble. Teleport builds this into the system.

Timing attack. Perhaps you know that a given transaction was supposed to happen at a certain time. Because everything is on the blockchain, any transaction within the relevant time frame falls under suspicion. This can be used in conjunction with other methods to narrow down the list of transactions to analyse. Teleport introduces random delays and allows recipients to decide when to move the money they have been sent in a telepod, so a change might only show up on the blockchain much later.

Mantissa attack. If you send a distinctive amount of money – whether that’s a very large sum, or one with a characteristic mantissa (the numbers after the decimal point), then it’s extremely easy to spot on the blockchain and follow. A mantissa attack – a term coined in the Teleport DarkPaper – is particularly effective if you know someone is transferring a dollar equivalent of money, perhaps because they have posted the information in a forum or it has otherwise been intercepted. Knowing the exchange rate and the rough timing of the transfer allows a high degree of correlation with blockchain transactions that fit the right criteria. Teleport uses standard denomination telepods – units of 100, 50, 10, 5, 1 and so on – so that unusual amounts won’t raise any flags.

Whilst taking care of the above vulnerabilities should be sufficient for everyday privacy requirements, you do of course also need to guard against voluntarily disclosing personal information; a huge amount of data relevant to cryptocurrency addresses and transactions can be and is harvested from forums and other sources in a method known as fingerprinting. As an aside, if you have your crypto address in your signature, you might want to think again – at least, if you take anonymity seriously.

However, even having adopted good personal practice as regards securing your privacy online you could still be vulnerable to  a well-resourced attacker correlating activity from your IP address to movements on the blockchain.

IP address detection. For those wanting a really robust solution suitable for hi-tech business (think industrial espionage) or resistant to intrusive government surveillance (China, US, UK…) it’s necessary to hide the fact that you are the one conducting a transaction at all. This is where the privacyServer comes into play. It’s the piece de resistance of Teleport, and it’s what makes it a platform capable of supporting so much more than just a simple cryptocurrency transaction.

Instead of submitting a transaction directly to the network, the privacyServer encrypts it multiple times and passes it through several other nodes (other privacyServers) first – a technique known as onion routing, used by other applications including the infamous TOR project. Not only that, but every transaction is also split into several pieces and sent to a number of different nodes, only some of which send it on to its final destination (and this is the simplified version!).

The result is that even if an attacker knows that you are part of the network, and even if they compromise one or even many nodes, it becomes incredibly difficult to link the user with the transaction that ultimately follows, given that it’s bouncing around many intermediaries and being pulled to pieces and reconstituted at the end. As a broad analogy, imagine printing a paper wallet for your bitcoins, photocopying it several times, shredding the copies, then sending multiple nested packets of the paper fragments to lots of different people, some of whom forward the contents on to others, some of whom forward those contents to the final recipient, who piece the shreds back together… ‘Impossible’ isn’t a word that should be used in these circumstances, because a determined attacker with unlimited resources can always find ways to cause you trouble, but it’s about the closest thing to complete anonymity available in the foreseeable future.

Pros and cons

The result is an extremely robust system that uses both common sense and cutting-edge technology to prevent an outsider from learning what’s going on inside the BTCD ecosystem. Moreover, by using services such as InstantDEX and TradeBots (instant and automated trading applications), the advantages can be extended to any other supported cryptocurrency: BTCD will turn anything dark.

There aren’t many downsides to Teleport. One is simply that setting up a fully effective privacyServer requires a certain degree of technical competence and possibly a small financial cost for a VPS, though you’ll still enjoy pretty good privacy without that. Another is that transactions are best made when both parties are online; because the recipient is (in a very simplified explanation) being sent a private key and using it to sweep the balance of one address into a new account, a long delay could give rise to double-spending on the part of the sender. This would never result in lost funds though, because the transaction would not be acknowledged as complete by the recipient. It would, at most, be an inconvenience. In other circumstances it could even be considered an advantage because the delay brings added protection against a timing attack, should the attacker even be able to correlate activity from the sender’s IP address with any blockchain activity in the first place.

Brave new world?

With continued revelations bringing to light the unprecedented levels of surveillance from the NSA and other government agencies, as well as the rise of big data and the aggressive, large-scale harvesting of personal information by corporations, it’s fair to say that both sides on this issue will be upping their game. The arms race for privacy is only just getting started. For now, it’s nice to be one step ahead of the competition.

You can find out more about Teleport by reading the DarkPaper or visiting the BTCD thread on bitcointalk.