[Java] [0.7.4] Latest NXT-Client and english tutorial

[mannimmond]

I had the same issue before. Not really an issue more a question:

You speak of line 41 in the OP. Line 40 says "my Hallmark". Should you have said line 46? Because in line 45 it says "well known peers" which you (erroneously) seem to have associated with line 40/41.

There are already quite a few peers in line 46. Should I add the nodes you quoted or should I replace the ones that come with the latest client with the quoted ones or should I do nothing?

Regards
 

[punkrock]

Latest client:

Note: Before upgrading your client, please backup the files blocks.nxt and transactions.nxt! If you forgot to backup the files, no problem. Just download the latest NXT-files below.

STABLE CLIENT

Download: NRS 0.6.1 (Mirror)
SHA-256: 6b5c8632c2d52a066d40017055a2e28f25d16fa30d3c0574bddb12f7d157e55c (nxt-client-0.6.1.zip) *updated 2014-02-07*

To verify a SHA-256 checksum you can use MD5 & SHA Checksum Utility (Virustotal)

Change log 0.6.1:

Fixed a minor bug in the 0.6.0 critical bugfix. Probably not exploitable,
but doesn't hurt to upgrade.

Backported some minor optimizations from 0.7.0.

Better handling of malformed peer announced addresses.

EXPERIMENTAL CLIENT (use with caution!)

Download: NRS 0.7.0e (Mirror)
SHA-256: aa778bade323d2b3f4cf13c925aa7b541d57f0853a5828385b72254ac92010bc (nxt-client-0.7.0e.zip) *updated 2014-02-07*

To verify a SHA-256 checksum you can use MD5 & SHA Checksum Utility (Virustotal)

Change log 0.7.0e:

This is the first release using an embedded java database (H2) to store
the blockchain, instead of serialized java object files. Because this is
a major change, this version is to be considered experimental.

The blocks.nxt and transactions.nxt and .bak files are no longer used.
Furthermore, they will not be loaded at startup, when you start with
empty database the very first time it will need to download the full
blockchain from the network.

The database is stored under the nxt_db directory, as of now it will
take around 100 MB when downloaded. If anything goes wrong and you need
to start fresh, it is safe to delete that nxt_db directory, it will be
recreated.

There are no changes in the web.xml file compared to 0.6.1. I will add
parameters to tweak database settings later, if needed.

The database will use 50% of the memory available to java for its cache.
The actual value is printed out at startup.

Currently only blocks and transactions are stored in database tables,
everything else such as accounts, aliases, assets, orders, messages,
is loaded at startup and then kept in memory. The amount of memory
those take is still small, relative to what was needed for all blocks
and transactions.

At startup, the blockchain scan takes a bit longer, this is normal.
If anything else is unusually slow, I will look into profiling and
optimizing it.

There are no new user-visible features compared to 0.6.1, the code is
kept in sync now (including the critical bugfixes). Having both 0.6.1
and 0.7.0e nodes on the network should not result in forks. I will
maintain both the 0.6.x and 0.7.x branches for some time, until all
major database related issues are discovered and fixed. Please report
bugs, including the stack traces.

Latest NXT-files:

Blocks.nxt & Transactions.nxt: nxt-files-2014-02-07.zip (89,3 MB) *2014-02-07*

[mannimmond]

I had the same issue before. Not really an issue more a question:

You speak of line 41 in the OP. Line 40 says "my Hallmark". Should you have said line 46? Because in line 45 it says "well known peers" which you (erroneously) seem to have associated with line 40/41.

There are already quite a few peers in line 46. Should I add the nodes you quoted or should I replace the ones that come with the latest client with the quoted ones or should I do nothing?

Regards

punkrock or anyone?

[punkrock]

You don't have to add more nodes. There are already enough in upcoming versions. I will remove the points from the tutorial.

[mannimmond]

You don't have to add more nodes. There are already enough in upcoming versions. I will remove the points from the tutorial.

Ok. Thanks

[stormrider]

I am not able to install the 6 version , does it 's cause problem if i stay with my 5.11 client until the next upgrade?

[mannimmond]

https://www.virustotal.com/de/url/97557d0157231a506983cca6a5d9deb1b8180978ed0d3e010b3558c6bf1a919b/analysis/ ?

[punkrock]

@stormrider: Delete everything and download the latest 6.1 - it works. You will face problems by staying on outdated versions.

@mannimmond: Just a false-positive.

[mannimmond]

@mannimmond: Just a false-positive.

I guess so too. Any way to prove it?

[punkrock]

Latest client:

Note: Before upgrading your client, please backup the files blocks.nxt and transactions.nxt! If you forgot to backup the files, no problem. Just download the latest NXT-files below.

STABLE CLIENT

Download: NRS 0.6.2 (Mirror)
SHA-256: cdb39d82e59aade4a0ea6b9f64fc9852fdab5d37a9a4ba755dffeaa96672aaf5 (nxt-client-0.6.2.zip) *updated 2014-02-09*

To verify a SHA-256 checksum you can use MD5 & SHA Checksum Utility (Virustotal)

Change log 0.6.2:

Fixed a bug in the calculation of guaranteed balance which could in some
cases result in effective balance higher than the actual balance. Since
this change can produce a fork, a switch to the correct calculation will
happen at block 64000. Everyone should upgrade to either 0.7.1 or 0.6.2
before that block, or we will get forks.

Improved validation of peer addresses to prevent syntactically invalid or
unresolvable addresses from being included in the peers list.

Enabled logging of all debugging output to a log file. Everything printed
out to the console will also get logged to a file nxt.log. This should
help with submitting bug reports in case of crashes and errors, as it
doesn't matter anymore if your windows console just disappeared.
The nxt.log file is overwritten at every server restart.

Cleaned-up hallmark and authorization token processing. Added Token and
Hallmark classes, those can be now used by Java client developers to
generate and validate tokens and hallmarks without going through the http
interface.

Improved logging of block push failures and block pop-off events, those
will now print out the block id and the reason for block rejection.

Improved peer blacklisting and logging of reasons for blacklisting. Http
requests from blacklisted peers are now completely ignored.

Made all API request handling classes under the nxt.http package visible
in the javadoc documentation, to be used for documenting the parameters
and return values of the http API.

There haven't been any database related bugs in the 0.7 series. All the
above changes have been applied to both 0.6 and 0.7 branches. I encourage
more people to try the 0.7.1 version, there is no need to continue
maintaining the 0.6 branch very long if we don't encounter problems with
the database version.

Improved performance of blockchain scan.

[punkrock]

@mannimmond: Just a false-positive.

I guess so too. Any way to prove it?

No. You can start from scratch if you don't trust in these .nxt-files. And by the way: It's nonsense to scan a zip-file in my opinion. You need to upload the concrete files you will use, in this case the -nxt-files. Here you can see the clean results.

blocks.nxt
blocks.nxt.bak
transactions.nxt
transactions.nxt.bak

[punkrock]

Latest client:

Note: Since version 7.x you don't longer need the .nxt- & .nxt.bak-files. Version 7.x is working with an internal database. If you start the client for the first time, just wait some minutes. It will take a while to download the complete database (~112 MB). For updates: Do not delete the nxt_db directory.

STABLE CLIENT

Download: NRS 0.7.3 (Mirror)
SHA-256: 8dccdaaf16d5f6714a96b05e08a918462cc3d549db66c7f52e81bc51b30894ae (nxt-client-0.7.3.zip) *updated 2014-02-12*

To verify a SHA-256 checksum you can use MD5 & SHA Checksum Utility (Virustotal)

Change log 0.7.3:

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.

[punkrock]

Latest client:

Note: Since version 7.x you don't longer need the .nxt- & .nxt.bak-files. Version 7.x is working with an internal database. If you start the client for the first time, just wait some minutes. It will take a while to download the complete database (~112 MB). For updates: Do not delete the nxt_db directory.

STABLE CLIENT

Download: NRS 0.7.4 (Mirror)
SHA-256: 847c70f734a3954159af99e0241d448369d4833067076570671324946a835245 (nxt-client-0.7.4.zip) *updated 2014-02-13*

To verify a SHA-256 checksum you can use MD5 & SHA Checksum Utility (Virustotal)

Change log 0.7.4:

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.