NRS client Experimental Update 0.8.0e

Get it here


sha256: 12ea7642953934b4b36cb833c500afefc9d1521776a298e3a6b6473cb0303a0c

Change log:

This release introduces a major change in the Nxt server architecture.
Instead of being a servlet run by Jetty, Nxt is now a standalone
application which itself launches Jetty servlets, when needed.
This should make it easier to use as a Java library, as it no longer
needs to be run inside a servlet container.

The Nxt configuration has been made more flexible, both for the end user
and for application developers. Nxt no longer uses web.xml, or any xml
files for that matter. Instead, a user-friendly properties file is used.

The layout of the distribution has been changed and simplified. Unpacking
the zip file will produce the following directory structure:

This is where the configuration files are kept. All default properties
are in conf/ You should never edit this file,
unless you are a packager or client developer who needs different
defaults for his distribution.
All default values are reasonable, so Nxt can just be started without
any configuration. If however the end user wants to customize some
parameters, the way to do that is to create another properties file,
conf/, containing ONLY the properties that need to be
different from the defaults. Nxt will read both
and, and the values in will override those

This contains the html files needed for the NRS javascript based client,
under html/nrs, the html-based tools such as admin.html and update.html
under html/tools, and the javadoc documentation for the Java API under

This is where all required Java libraries are kept – Jetty, H2 database,
and the JSON-simple library. All Jetty libraries that are not used by Nxt
are no longer included, which also results in a smaller distribution

This jar contains all compiled Nxt classes.

This script is the simplest way to start Nxt, under Linux:
java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
As you can see, the classpath needs to include nxt.jar, all the jars under
lib, and the conf directory.

Notably missing are start.jar, webapps, and the Jetty configuration
directories, which are no longer needed.

In addition to the switch to embedded Jetty, significant refactoring of the
code has been done, which may be of interest to users of the Java API. The
changes are too many to describe here, but can be easily seen by comparing
the javadoc of 0.8.0 with that of the 0.7 branch. Most notably, interfaces
have been defined for the Block and Transaction classes, the Blockchain
class has been split into several classes, and the Peer and User classes
have also seen some clean up.

Client developers using the Java API can override any of the default
properties by submitting a custom Properties object to Nxt.init().

The configurable properties in are all documented in
the comments in that file. Some additional details about those:

Nxt will start up to three different Jetty servers, if needed.

The peer networking server accepts http requests from peers. It is only
started if nxt.shareMyAddress=true (which is the default). If you are behind
a firewall and don’t have an externally visible IP, you can set this to false
to disable it.

The port and host interface of the peer server are configurable. If you set
a non-default port in nxt.peerServerPort, this will be appended to the address
you announce to peers (this address should be set in nxt.myAddress). Using
non-default peer networking port hasn’t been tested much though.

For a machine with multiple network interfaces, now you can specify on which
interface to bind each server. By default, nxt.peerServerHost= so the
peer networking server listens on all interfaces.

There are no hardcoded nxt.wellKnownPeers in the default properties files.
You are supposed to set those to your own preferred peers in
However, if none are set, a random selection of and
public nodes will be used.

The DoS Filter is enabled for the peer server only.

The API server accepts http/json API requests. By default, now it runs on port
7876, and listens on the local interface only. If you run a public
node and want to accept API requests from anyone, set nxt.apiServerHost to, and nxt.allowedBotHosts to * (or empty).

The nxt.apiResourceBase points to a directory of static html files that are
also served by the API server. Developers of clients using the http/json API
will want to customize this to point to their client html and javascript files.

The Jetty Cross Origin Filter can be enabled for the API server by setting
nxt.apiServerCORS=true (disabled by default).

The UI server is used for the NRS javascript client UI. By default it runs on
port 7875 and accepts requests from localhost only. Client developers using
the same API calls as the NRS client (not the http/json ones) should customize
nxt.uiResourceBase to point to their client html and javascript files instead.

SSL can be enabled for both the API server and the UI server (default disabled).
If this is done, the corresponding ports will accept https requests only. There
is no way currently to have both http and https supported at the same time, but
this can be added, I just didn’t see the need for it.
If you enable SSL, you need to set nxt.keyStorePath and nxt.keyStorePassword,
and obviously you need to have your own SSL certificate (self-signed or signed
by a CA) in a keystore file. I have only tested this with a self-signed

Client developers using the Java API will probably want to disable both the
API server and the UI server, and for users without a visible IP address
even the peer server.

Debugging output is now disabled by default, but can be enabled by setting
nxt.debug=true. Exception stack traces will still be logged, as long as
nxt.enableStackTraces=true. I hope there will be none of those.

The connection to the database can be completely customized, as the full
jdbc url used to connect to it is exposed in the properties file and can be
modified. Client developers that insist on being able to access the database
from a separate process, while Nxt is running, can do so by appending
;AUTO_SERVER=TRUE to the jdbc url, which will enable automatic mixed-mode.
This is disabled by default, but if you enable it and write to the database
while Nxt is running, expect things to break.

It is also possible to have the database in a different location, not just
in the current working directory, if you change the jdbc url accordingly.

To change the amount of memory used for the database cache, use the
nxt.dbCacheKB parameter, in kilobytes. If set to 0, by default 50 % of the
memory available to the JVM is used for database cache.

There have been no changes to the database schema, you should use your
existing nxt_db directory with this release too, instead of downloading
the blockchain from scratch.

This release is labeled experimental, but please try it. In particular, the
client developers and packagers should test it well, and if there are no
major issues, expect the 0.7 branch to become obsolete soon.

Version: GnuPG v1.4.12 (GNU/Linux)



NRS Client update 0.7.6

Get it here


sha256: c219d6a13c870ea7f454fe1e91efe6c6098bed767156aa8921aad0bebe9fe79a

Change log:

Compact the database at every shutdown. This should help reduce the size
of the nxt_db directory after the first run, check the before and after
disk usage.

Prevent duplicate peer listings in the known peers and blacklisted peers

Prevent a potential duplicate account key attack, of the type described

Added Voting System, not yet enabled.

Some refactoring of the Block and Transaction classes.

Asset exchange bugfixes from the test network and more API requests.

Improved validation of transactions to prevent wrong blacklisting of
peers, and to better enforce transaction validity.

Version: GnuPG v1.4.12 (GNU/Linux)



NRS Client update 0.7.5

Get it here


sha256: 66adc8379a8f6e3fba7797fbc94b8b62f3e486ea5b6e9877f064c4b0d1f2584d

Change log:

Various performance and memory usage improvements.

Improved validation of peer addresses and handling of peer connection
status changes. User interface improvements related to peer display.

Additional optimizations in getMilestoneBlockIds, backwards compatible.

Further clean up of the core nxt classes from all UI related parameters.

Version: GnuPG v1.4.12 (GNU/Linux)



New NRS client update: Release 0.7.4

Get it here


sha256: 847c70f734a3954159af99e0241d448369d4833067076570671324946a835245

Change log:

Another bugfix in the transition to Transparent Forging, starting from
block 67000. Upgrade before this block, because there will be a fork.

This release drops support for the old getMilestoneBlockIds protocol.
Clients older than 0.7.3 will not be able to request blocks from 0.7.4
nodes. Everybody needs to upgrade to 0.7.4 anyway, before block 67000.

Some optimizations in the database queries used during unlock account,
let’s see if this helps Raspberry users.

Minor other improvements.

Version: GnuPG v1.4.12 (GNU/Linux)



New Nxt client version 0.7.3! 0.6 series no longer supported!

Get it here


sha256: 8dccdaaf16d5f6714a96b05e08a918462cc3d549db66c7f52e81bc51b30894ae

Change log:

The 0.6.x series is no longer supported. Starting with this release,
only the database version will be developed.

Optimized the getMilestoneBlockIds protocol. This is the peer to peer
request that currently puts the most load on the public nodes, and is a
cause of a large amount of unnecessary outbound traffic. However, for
backwards compatibility, version 0.7.3 still supports both the old
and the improved getMilestoneBlockIds protocols, so when older clients
connect to 0.7.3 nodes they will still cause unnecessary load and
extra traffic, unfortunately.

WARNING: Support for the old getMilestoneBlockIds protocol will be
removed in 0.7.4. You don’t need to upgrade immediately, but if
you don’t do it before 0.7.4 comes out, your older version nodes
will not be able to request blocks and catch up with the blockchain.
Better upgrade sooner than later.

More and more refactoring. Completely separated the user interface logic
from the core business logic. Nothing in the core nxt package depends on
the classes in the nxt.user package anymore. Instead, a Listeners
framework is used, so that the UI can register to be notified of the
events in the core that it needs to know about. This is also intended to
be used by Java client API developers.

Added some more indexes to the database tables to improve performance.
These will be created automatically the first time this version is
started with your existing database – no need to start from scratch,
no need to delete your old nxt_db directory.

Privacy related change: Before this release, newly generated blocks
and new transactions were broadcasted to peers twice. This could allow
your peers to deduce that your node was the generator of the block or
transaction in question. This is now fixed. Note that somebody with
the ability to monitor all your internet traffic will still be able to
tell that it was you who generated a block, because the generating node
sends the block before having received it from any other peer. I don’t
see a physically possible way to avoid that, yet. Also note that the
transaction re-broadcasting feature will continue to re-broadcast your
transactions until they are received back from at least one other node,
but will not do that with transactions received from other nodes. This
could still be used to deduce that your node was the source of a
transaction, in case the initial attempt to send it failed, and it was
re-broadcasted (but somebody already observed the failed first attempt).

Separated block forging logic into a Generator class, which can also
be used by Java API clients to start and stop forging.

Added startForging and stopForging API requests.
Parameters: secretPhrase, required for both starting and stopping.

Fixed minor bugs. Fixed a bug in peer download traffic monitoring.


New Nxt client version 0.7.1!

Get it here!