Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

Read the above SQL once again more carefully

Not now, this will open another can of worms.

Yes of course.

It turns out the transition to fractional amounts, which is required for reducing the minimum fee, will not be that simple. It would require adding a new transaction type, because the current ordinary payment transaction stores amounts and fees with 1 NXT precision, not multiplied by 100 as in the account balance. So it will take longer to implement and test. The positive side is that while doing that we can make the fractional part allow amounts much lower than 0.01, so we will achieve much higher divisibility.

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

Release 0.7.5

http://download.nxtcrypto.org/nxt-client-0.7.5.zip

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.


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

iQIcBAEBAgAGBQJS/kSlAAoJEFOhyXc7+e2ArxsP/ieUexCLGYB+4WiluLXbNEP5
uDOLcvm+gi3/d960TiINeUJ5uXdr8VDMx2MECsM4zyFBmL7ipE4c1/mWCTXyLHM9
6Vi9z32QyjGO8kLrsg1KxZ2TYIQyDdCqLAJUJ46Zrkk3x+nQRrhsewaJgWJkrKMD
c0vl1JPebNve6kSr2M8XErebO/jTFNzVSFW/dms0GdlEWmUKeImDXhPM3+8+B32c
q+2e64hu2onIrkhV/DyGOWkAj7v2OD9AGEbcVZDrKCfBZV2CDn1eUWSAke1lXHXr
X2o1KBCoOcDFL7Sy0zylTf8CIJgjUns8/nT6NCakNaSNVHtoAdQbrYZMYnPxA9Cb
kzfsVqdbUc3TWpnnRpa0w3FD8CY65/8+2IOvxV/w2DXiQpLTBLrvGGZ3ktg5wFT4
MInzJXF2x75fIL7Yo41oVw3WTeLgE6Mfbhpko08CL9v9NCCbKGEN08a0aBQshs/2
A3iky6EQqayQrsnpB4VCG63QNcLMQUSP4CedbkFTFczDkUa8TCUZfdopAawOz2iK
WfJAaA7Y47LhUhrhvcbcM5UQzK+4WwgEGcblgRKc7y9G7v6Iz5LpJqmdvUiF66Px
30HZZ5CgKDqo8tMzfI7qcmjPNUMQop3YhfstW/KZWL6xF6TrPE6Uc/cSoYqbTHwl
6OeSO2RI6cjevWQPl3iX
=PO6n
-----END PGP SIGNATURE-----

Nothing. Just a bug in setting the correct peer info, mostly a cosmetic problem. Fixed in 0.7.5.

Querying many accounts at once will be slow even if done on the server side, it will be better to have a way to subscribe for notifications when the balance of an account changes. Currently this is not possible with the http API, only with the direct Java API (i.e., you would need to write Java code to talk to the server).

Also not sure what he means by "all of the accounts held by the node" - each node has information about all existing accounts on the blockchain, so it is not a very useful query.

Sorry, can't do that now. This would require much more fundamental changes, new block and transaction versions at the least.

I mean, the way the current javascript client is doing it, whatever this technology is called. I didn't plan to touch that part myself, I am not familiar with HTML5 push.

How does your client currently work, only by making javascript calls to the http api? Is it just a bunch of html and javascript files that need to be in a directory served by jetty? Because I am considering switching to embedding jetty in 0.8 or later, but of course need to plan how to accommodate your client.

The answer is I don't know yet. It is not just changing a hardcoded constant. We have the logic of multiplying amounts by 100 all over the code (yet not absolutely everywhere), this needs to be cleaned up and all the amounts need to be handled in a consistent way, i.e. all in NXT-cents, and only display them as fractional in the client, and parse user input as fractional in the client. I need to go through the code and fix that, and then track down and fix the bugs resulting from my fixes.

Forging means the server knows your secretPhrase. When it does, it automatically checks whether it is possible to generate a block, every second. Even if the account effective balance is 0, it will keep checking, so you could start forging before the required minimum 1440 number of confirmations, and once the effective balance becomes > 0, the account will automatically be forging. It will continue forging indefinitely, unless stopForging is called (lock account does the same), or the server is shutdown.

The deadline is the estimated time until your next chance to generate a block. Your chance changes only when a new block arrives, so only then the user will get a notification of a deadline change. In between such notifications, client developers can just decrement the deadline with 1 second every 1 second.

It is a bug (fixed) if the deadline is ever shown as negative, this can happen if the server time is behind the timestamp of the last received block.

Users of the javascript client will get a JSON notification when the deadline changes. Client developers using the Java API directly can register a listener to receive such notifications, just like it is done in User.java:

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

Release 0.7.4

http://download.nxtcrypto.org/nxt-client-0.7.4.zip

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.


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

iQIcBAEBAgAGBQJS/ATQAAoJEFOhyXc7+e2Az3YQAM2i40MF7EvS0Snof0I2qGp4
Har6d7y8/ycesR2TRCHSsm6C/xor8Q3cutApFXqcZ2C1pPsRGS88nTpzrZakvRS2
nVWD9xwlPVUr3Z841w6YRR3e2bGVbTntbztgfnBjPuropnKwsL0HE3zYDx0c4Z8w
w/cpOT2g2lwWxdW3e2ogi30X0tzWK307tQujDDAFJAcHtONJOahQSxFY1nvH/Ggp
IiElFO2d0T/8BrBSHkc6wi1jcZuut+IeRZFfwFqE81ZGfvleMsmbkBypLlKEgX8i
vkRx/Q2pIEVvcTcPQn10fr8dzE6JMUCii6+UHRWg9TXYe0bmpqF6USMOz2UxB/u2
phWwRYT9xAmLRdxqXeWVdxs+v9UhWdTqvUSwoPykxiQoK3qJaOpkoG0Tbj8gQQFH
NaY21FigF6g/1HLXPan65eYW+WfpdeRzEAA2SHR6/7hS1eEyKrXTy0Dm321VrMrU
sbK4L/RFeWu/NoF09lhBMwaF/t1OoffMUHTMX2fMBRrWsA0sLmlc0HQXiyJ1sESO
RQ9vKOgAhvLz08JNNJ/8g8Tie5RJaEOOdHywECZVQjTRZSz9bYtywel9SHS1RE5w
jaYs5HfQjRWOsWegHSOtUo7XZCcR6QsPKDJvdX1L+WmubMxEt5Dya11K3o4pvFQt
oKUosIWGFNgStAGIgPgx
=fxzG
-----END PGP SIGNATURE-----

The block probably came from yet another node, and it was acceptable by vps1.nxtcrypto.org based on their time differences, but by the time it came to you, and accounting for your time difference from the original node that sent it, it was not acceptable to your node. I will stop blacklisting nodes based on timestamp errors only (but the block will still not be accepted).

No, I will not. If I run a public node I may want to allow API requests to it, yet I don't want people to be able to tell which accounts are forging on that node. To start or stop forging requires the secretPhrase, similarly obtaining information about forging status should also require it.

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

Release 0.7.3

http://download.nxtcrypto.org/nxt-client-0.7.3.zip

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.



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

iQIcBAEBAgAGBQJS+0MYAAoJEFOhyXc7+e2ALV8P+wWgHvaTWjTnph67Z9KsFE2Q
b4SNxnjbcirb7VOJmADdgaJ06XSx3rstgh2oY7Dt3Lm/h30NFTF38eUSTMbfTqGt
w3vH1n3X0VM6Hf6XB+pqRDo6gyA3rqnaf0U7dftOMYJlEnBu9enN+3XKvWbCb7jQ
hn+sJ0VufaHXtthHewQI7Zu5Bs0/T/73P1bwTDTg8Q6X3+qErpDMDlp+ibFqp0CO
eRDil8J+wKUtJhnJKlCTTCW0oVeYzr2pEiiSzd8x3LxvRBdGhzrtsgo1QMPJuBW1
1VB0vf8AbZbrEAMfnG+ZhRVO91AJstha7aG9k5hS7irEQ+WFtu7gVYeei+0vpHYg
QEqS/+ylRdTDeIOyCM3M3GdOCBo2cotvC9wlV0xfozEbA9KXdMPmLifw8tGcnxTs
RjCrHSb2u6xPAq+fcOa/OxXRTBEm8l2cUdZ6dv5eQ1GHaqfICOol5DtxG0U5K21K
2fv3RPwn41OkHFM1k+ohR+Rj+KczKvT8smKzZYbL/uqb2LonW8QONK0sfjZWOBmx
53XEjYh0MLTpbHyFWai3KpVpHyfE/5jxZL29Js7ImE6yjHX82g3ZS6S5cJJDQhOs
IIv2fKmusnhzwDIgtaSVKT/gSnleQqEBLCgCtV4FH7oQpht7sRNbOLK9DEHRN0uI
jLWVCgICI1/J3YhaDUza
=1geu
-----END PGP SIGNATURE-----

The documentation is all auto-generated with javadoc. My plan is to add descriptions of the http request parameters expected, and the json object returned, as javadoc comments for all request processing classes in nxt.http, but I haven't done it yet. This way hopefully the http api documentation will stay in sync with the code, if whoever changes the code bothers to update the comment too.

If the slow blockchain scan was the only issue with the database version, now that this is fixed the days of the 0.6 branch are limited. Everyone should try the 0.7 branch and report bugs, if nothing serious the next release will be 0.7 only.

But you can still unlock your account from the browser and forge, right? And when we decide to remove the web interface, I will add an unlock account API, and also I hope somebody comes up with an alternative web interface by that time too.

Maybe there is hope for the raspberry owners after all... let's see what they report.