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

I'm not sure I understand....

So if the node with #12345 is on a slow distant part of the network and #12344 is on a nice well connected bit, nodes will see #12344 first and accept it but then they see #12345 which is the overall best ticket and accept that instead, and #12344 and #12346 which tried and ultimately were rejected when #12345 turned up a few milliseconds later both get penalised and have to wait a minimum of 1440 blocks - is that right?

But strictly speaking they could now win at that point because they were not the best ticket and they were probably not the next ticket so having to wait 1440 blocks is that really a penalty?

I will try my best (math is not my strength - logic is).

Basically the way that TF works is that there is a crypto hash for each block which was calculated from the previous' block hash and the "forgers" account.

This hash then determines who's account is the "best" to forge the next block so in a perfect situation if we consider that the max. "weight" of a block is 100 then you would see a blockchain like this:

A(100) B(100) C(100) D(100)

but things aren't perfect as some people won't forge (or pass on their forging right) so the network allows other "less perfect" blocks to be announced and each node will accept the best one that they see to try and keep building on the chain.

A(80) B(90) C(50)

The problem of "forking" is because each node can't see everything in the network (due to latency) so you could also end up with:

A(80) B(95) C(10)

with these "forks" ending up becoming "ignored" because a longer "better" chain has been noticed by the node.

So the problem we are dealing with is that B(95) could "hide" their block and then announce it *after* B(90) which would at least for 1 block make it a "better chain".

But as others will build upon what they see then it won't necessarily *matter* that B(95) was better than B(90) because C(50) is better than C(10) and so B's attempt to "create a fork" will fail.

If though someone has the ability to produce a better B, C, D, E, etc. then they could replace a large number of blocks. This is known in Bitcoin as the >50% attack.

We need to work out the probabilities of all this including how "penalising" a node for "not forging" changes this.

It really is a penalty as they now have no chance to forge a block for 24 hours (I wouldn't be surprised if people ended up modifying the software to "go to sleep" for 24 hours in that situation).

Also it doesn't really matter being "the best" as we are building "chains" (the weight of the entire chain is what is best rather than each specific block in it).

Done.  I am in email contact with Nifty too.

I AGREE.

As I can help at your disposal

I'm not technical. So you can ignore me if I say something stupid.

Isn't it possible to build something on top of NXT that can be more profitable for the forgers around us to keep the network safe?

I thought James was experimenting with such a coin earlier.

Why dont we update the NXT network?

Ah, okay thank you, didnt know the 0.8.x version are experimental.