No, I hope this should not be necessary. If both nxt-default.properties and nxt.properties are in the classpath, it will read both files, and the values in nxt.properties will override the defaults in nxt-default.properties. It is ok if nxt.properties is missing completely.

The system property should only be needed if for some reason you cannot have nxt-default.properties in the classpath, or the classloader doesn't find it, or you have some complicated setup with multiple classloaders. It is a hack.

No, these are java method calls only.

OK, the fix will be in the next release.

I am only waiting for client developers to say they fully support the 0.8 branch, and to have the user friendly installer packages ready, before announcing it stable. I don't think it is unstable at all.

We have to move to the 0.8 branch before I can start working on incompatible features such as adding transaction type for fractional Nxt amounts.

This is not good. You should not have to use kill -9, because this will not let the database shutdown cleanly. Try the new version, there have been some changes in the shutdown process. You should at least see the message "Database shutdown completed" in the log, if it still hangs after that it is ok to kill it, could be that some jetty server does not want to exit, but once the database is shutdown it is safe to kill the remaining threads.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.8.1e

http://download.nxtcrypto.org/nxt-client-0.8.1e.zip

sha256: 4c665609a08fc5e79143e715c0f46246c66d35c1db6138ca9b025a1188d9aa3c


Change log:

Improved handling of peer announced addresses and ports. Setting
nxt.myAddress is now optional, which will help users with dynamic IP
addresses. When connecting to a peer, as long as nxt.shareMyAddress is
enabled, it will at a later time attempt to connect to your announced
address, or if not set, to the address your request came from.
If successful, the peer will use this address to connect to you in the
future, and will share it with others. This also does verification of
announced addresses, and considers your node connected only after a
successful connection to the announced address is made. This will prevent
invalid announced addresses from being spread to other peers too.

If you need to use a non-default port, the port has to be appended to your
announced address too. It does not need to be the same as
nxt.myPeerServerPort, so you can run the server on one port but forward
a different router port to it. If the port is not set in announced address
however, but nxt.myPeerServerPort is non-default, nxt.myPeerServerPort
will automatically be appended to the announced address.

To summarize: For users with dynamic IPs, you don't need to put anything
in nxt.myAddress, but still need to set up port forwarding at your router.

Verification of hallmarks has also been improved to attempt to resolve
hostnames to IP addresses. Note that if you use a non-default port,
the hallmark should include your address only, without the port.

Added generateToken API request. Parameters are secretPhrase and website,
response is the token string wrapped in JSON. This is also available
on the admin.html page.

Improved handling of init and shutdown. Nxt.shutdown() is now public and
client developers can call it. When Nxt is started as a standalone
application by calling main(), it will schedule a shutdown hook, otherwise
if started using init(), the caller of init() is responsible for calling
shutdown() or scheduling a shutdown hook.

Delayed starting the blockchain scan and the jetty servlets until the
initialization of all classes has completed. This should allow registering
listeners with those, and will also help prevent errors due to servlets
starting to accept requests before the system is fully initialized.

If nxt-default.properties is not found in the classpath, Nxt will also
make an attempt to load it from the file defined in the system property
nxt-default.properties, so you can define it on the command line:
java -Dnxt-default.properties=conf/nxt-default.properties. This is of
interest to client developers only.

Support use of POST in addition to GET for all API and UI http requests.
To enforce use of POST only, for those requests that require the user
secretPhrase, the nxt.properties nxt.apiServerEnforcePOST and
nxt.uiServerEnforcePOST can be set (default is false for API, true for
UI). This way client developers can enforce that only POST requests are
used for handling sensitive data.

The default NRS browser UI has been changed to use POST only, and so have
the tools - admin.html, message.html, alias.html. This way the user
secretPhrase will no longer be cached in the browser memory.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTC23tAAoJEFOhyXc7+e2AoW0P/iRzGr2E4h0kfKJdVE6lbmim
BE5X4uksz8A8Amdo8KoVKEAnTlEGkOHEPPXl2jegiJZi4CupxYNqOR7EaXdPwFNg
eQbA+pOgazpG7ljoZAfdKve4qEEQj4/enBgWRAMMnwEeysi/SMMxSPbzk2QI3EA+
h/kFHHuZjerbdbWghqaaETG11RzZYLiFt0xhFQtBcgCxjdTTGJ3eA9euRuP2VpGo
vsy4UhwjS1nZsv1B6DVuZpZcviDR2siXTTiZNPO/pxOvHP9rbGhKK7DUwrgLkI23
aqi52c8beCRfNIszhqfO+qPrRQOl51a3KeuedkNyt5QyaKoKSyRb8pKSk7H6D3n8
F9u9zWdl4+97a0KZVsl9sOKHN6oQW4CKjFD+/P0xz6FAVz29IrFmUAS1582mwjGB
LtcleI4LzBhYLXP9xblOQw8DMhrSz0kInMSlXkhjHrwMgQ/Z706RcPa4m3E7Itp7
4212I4kgQOj2CMB0Dj2F+M7msbpJ4fOgZwe3n7dU5d0CqkyfDHqS59qdoSEw+m8P
OVFqYGccLgwC4oqISV9MKGXK+GQmAnOsk3qUmuk7IwuFLvKFiOH2ONezlEgNf3Nq
H9ishR4Kz5EmL+lxMVVdFKJv4F+wBvrJ46kCn6dLpdE3AAQ8UE3igHuuzWSfuN9b
IDqSgNO/e6KgYRNSw5N3
=xPDQ
-----END PGP SIGNATURE-----

Yes, this is true. You don't have control over which nodes you connect to, so why would you need such behavior? It would only make sense if you can define a whitelist of nodes to connect to, but currently you can't do that. Your node will keep trying to connect to whatever list of peers it receives from the others, and telling them your public address itself, how is that different from allowing the peers to share it amongst themselves too?

In 0.8.1, I am adding the ability to use POST instead of GET for all API and UI methods, and optionally enforce use of POST for the methods that submit the user secret phrase. This is to prevent caching of the secret phrase in browser memory cache, and to prevent mistakes due to submitting the same request twice, as browsers are supposed to warn users when doing this with POST requests.

This wasn't possible before because everything shared the same port and POST was reserved for peer networking only. Now that the UI and API requests have their own servlets, there is no problem in making them accept both GET and POST. I am adding a nxt.properties parameter whether to enforce the use of POST for the methods that require it, or just accept both GET and POST.

I have already changed the NRS UI and the tools - admin.html, alias.html, message.html, to use only POST. Client developers preparing for the 0.8 branch should consider using POST where appropriate too.

The only place where it matters is in the blockchain scan, and I will delay this to be done in the ThreadPool.start() so that you can first add listeners to the BlockchainProcessor.

The rest of the init() is intentionally done static so that it can only be run once, and it has to be in an inner class because otherwise the initializers of Peers and other classes will deadlock with the init() of Nxt.
The nxt-default.properties has to be there. I don't throw exceptions if nxt.properties is missing. Why do you not want to use nxt-default.properties? It only needs to be in the classpath, it can be hidden from the user.

This cannot be done in init, because properties must be loaded before any other classes attempt to get them using Nxt.getStringProperty() etc., such as the Logger initializing its debug and enableStackTraces as static final. Allowing additional properties overrides in the init() was not such a good idea. If you want to add listeners to BlockchainProcessor for example, before init() has been called, it still needs to see the correct values of all properties - so it is too late to set them in init().

What I can do is make Nxt.shutdown() public and not add any shutdown hooks myself, when started using init(), only when started using main(). Then whoever calls init() has the responsibility to add a shutdown hook or call shutdown().

I don't know how your restart works, but unless the jvm is really shutdown and started again, init() is unlikely to work as expected after a shutdown(), because of all the static initializers and final variables I rely on.

If you have an address that other peers can connect to, you can't really prevent that from being shared. Even if your peers don't share it with each other, you don't control which peers you connect to. So when you connect to one peer, after a while you request from it all other peers that it knows about. Then, you start connecting to them one by one - and all of them get to know your address directly from you. So it doesn't make sense to announce a public address, yet to set sharing to false. It will still get known, only a bit slower.

In fact, in 0.8.1, I added a feature so that setting nxt.myAddress is optional and only strictly needed if you use a non-default port. If you don't set nxt.myAddress, but nxt.shareMyAddress is still true (the default), when you connect to a peer he will see the address your request is coming from, and at a later time try to connect to this address at the default port (unless you have set nxt.myAddress to something else, in which case it will try to connect to your announced address). If it succeeds, it will treat your peer as if nxt.myAddress has been set to the address your connection was seen as coming from. And also share this address with others so they can also connect to you. This way you don't need to worry about what is the external IP of your router, and especially if it ever changes for those with dynamic IPs. If you don't want this to happen, set nxt.shareMyAddress to false. In this case, the peer networking server will not be started at all as nobody will be attempting to connect to you. You can of course still make outgoing requests and receive responses to them.

This is shifting from proof-of-stake to proof of having a distinct IP. For ordinary people it is indeed difficult to get many IPs, but what about an adversary who wants to attack Nxt? Any government can easily do it, or even a company of the size of Google or Amazon that surely has a pool of available IPs that are not always used, or even a rogue high-level sysadmin at such a company or a big ISP... they can just borrow some of their unused IPs for an hour and perform a 90% attack.

I explained that in a previous post.
No, those parameters are used by Jetty only, but we are no longer running inside jetty. Use ctrl-c to kill the java process, and when shutdown cleanly you should see:

DEBUG: Database shutdown completed
Nxt server 0.8.0 stopped.

(if nxt.debug is false you will not see the first line)
Port 7876 by default, no https.

If you can use the Java API directly, there is:
String nxt.Token.generateToken(String secretPhrase, String website)
and
Token nxt.Token.parseToken(String tokenString, String website)

I will add an http api to generate token, there is already one that the user api is using, and we have api for generating/decoding hallmarks, for completeness it makes sense to have it for tokens too.

I believe you can make java api calls from groovy, right? Then just use the java api directly, if your script is running on the server, no need to go through http.

Not that I know of. The last refactoring I did is at least a very small step in the direction of making it possible, as far as the Blockchain and its processors are now objects and not a set of static methods, but there is much more work to be done to really allow multiple chains, most of the code assumes there is just one and only blockchain.

Two things I forgot to mention in the change log:

If you are using Tor, now the tor socks proxy address and port need to be specified on the java command line:
java -DsocksProxyHost=localhost -DsocksProxyPort=9050 -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt
and obviously set nxt.shareMyAddress=false in nxt.properties

The default database connection pool size is set to 10. I also print out debug messages with the maximum number of simultaneous database connections observed at runtime, like:
DEBUG: Database connection pool current size: 3
In the unlikely case you see this reaching 10, for a very busy public node, consider increasing the nxt.maxDbConnections setting.

Try http://localhost:7876/admin.html . Those tools use the API server which is now on port 7876, this is why I made the html files also served from that port.

Try setting nxt.apiServerHost=0.0.0.0 and nxt.uiServerHost=0.0.0.0 to allow those servers to listen on all interfaces. The default is 127.0.0.1 only.

There is no pressure, I was just putting it up for discussion.

I don't feel I need help, yet, because many of my changes are still so fundamental that I am changing code all over the place and this type of work will be difficult to coordinate when there are many developers. CfB has to re-read the code and figure it out again every time I make some drastic refactoring like the last one. But eventually the code will stabilize and it will be possible to have several developers contributing at the same time. I also don't want to slow down the developers of clients and installers who want to peek into the source.

Should we create a poll and vote for it...

It is very simple to generate a self-signed certificate actually, just use the keytool command that comes with the JDK:
keytool -keystore keystore -alias nxt  -genkey -keyalg RSA
It will ask you to choose a password (that you will later need to enter in nxt.properties as nxt.keyStorePassword), and some mostly optional details for the certificate, and then generate a keystore file which you need to put in the nxt directory and point nxt.keyStorePath to it.

No, I use jabber, when I don't forget to turn it on, but CfB doesn't use it... we communicate by email only.