Right. But the user is getting the javascript from nxtra.org, which I presume is under Wesley's control. If so, user has to trust him (and still use SSL so it is not modified in transit), but he already is trusting him that the client he maintains is not malicious.

Now, if there is a copy of Wesley's javascript available for example at https://wallet.nxtcrypto.org, which is not under Wesley's control, we are back to where we started, the user has to absolutely trust the owner of nxtcrypto.org, as indeed even the javascript could have been modified.

http://localhost:7876/test for a listing of all available APIs and their parameters.

getAccountTransactions supports filtering by type and subtype, you can get asset transfer transactions for a given account. But this still returns transaction id's only, not the full transaction json. The API needs improvement.

Are you sure you need to use the hash and not just the transaction id? IDs are still guaranteed to be unique and continue to be used as the unique identifier internally. Hashes are used to make sure no new transactions are accepted that are duplicates (in all fields other than the signature) of an existing transaction even though they may have a different id.

It is certainly not soon. Besides, it is my understanding that UDP will only be used for sending transactions for fast processing directly to the node that is known to be the one to generate the next block. So at least the TF should be completely implemented before that. And the existing http API will continue to be used, necessarily over TCP.

When a node receives a transaction from another node, it does not know where this transaction originated from, it could have been forwarded from yet another node. But when your client uses broadcastTransaction to send a transaction to a node, anyone monitoring the clear traffic between the client and the node will know that the transaction originated from that client IP. If you use SSL, at least you are protecting the client privacy from the ISP and anyone who can spy along the route. The public node operator still gets to know that your IP signed and sent the transaction.

For forums and wiki SSL is indeed essential, unless we all start signing each of our posts and PMs with GPG.

Yes, I will add that to asset transfer, it could have other legitimate uses, and asset transfers would not be that frequent compared to ask/bid orders to worry about bloat.

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

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

Release 0.8.12

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

sha256: 1f9cd574914fef3ff0528cceee6b264876f90b763881b50dc1a196dbfb9598d5


Change log:

This release is only about testing and debugging. There is no need to
upgrade if you are not interested in doing testing.

Added DebugTrace.java, which uses listeners to monitor all changes to
account balances and asset balances, and all the events that cause
those changes - transactions, block generation fees, order placement,
asset issuance, asset transfer, order cancellation, trade.

This feature uses two new properties in nxt-default.properties:
nxt.debugTraceLog=nxt.trace
nxt.debugTraceAccounts=

To enable tracing of account balances, set nxt.debugTraceAccounts to
a list of account id's to be tracked, separated by "; " . The output
will be saved to nxt.trace, or the file defined in nxt.debugTraceLog.
Values in this file are tab-separated, to make it easy to import into
a spreadsheet application.

It is possible to enable tracing of all existing account balances, by
setting nxt.debugTraceAccount=* .

On restart, and also on rescan, the nxt.trace log will be overwritten.

Added VerifyTrace.java, which can parse the nxt.trace file (or a file
specified as a command line argument), and perform some verifications.
Currently, it verifies that for each traced account, the final balance
matches the total of all changes that affect that account, as
recorded in the nxt.trace log. It also verifies that for each asset,
the total of asset quantities in all accounts matches the original
quantity of asset issued. This verification can be expected to fail if
not all accounts that own an asset are included in debugTraceAccounts.

To run VerifyTrace, use the verify.sh script. The Nxt server should be
stopped first, so that the nxt.trace log does not continue to be
updated while VerifyTrace is verifying it.

Unconfirmed balances and unconfirmed asset balances are logged, but
not verified by VerifyTrace, because the presense of open or partially
filled orders can make that too complicated. It may be easier to
program a spreadsheet application to handle such calculations.

Added TRADE event, triggered when a Trade occurs. Note that the Trade
event happens before the update of the account balances.

Added BEFORE_BLOCK_APPLY and BEFORE_BLOCK_UNDO events, triggered just
before the corresponding operations in block processing.


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

iQIcBAEBAgAGBQJTLCIoAAoJEFOhyXc7+e2ANSMP/0VLUj4HJj2Ggp0yGaZQjJOC
fDsnxzF+1B/+UJbUbanukqxK156YCWSR88JLWwPPj6sYB2g8b61of2s9hNUth9m7
qFWQGjw8tjPr93aulNwPcVPmrZ45lQjSFRISYbBhwmhbEiZFI580zW232P2xHF1y
FewPsy91EGrDRwpI/zgkQiVTyHypHw7V05HmLPHEf9norgI5o6VuRzKC6zbrzHS+
MMMmRlsDpGnXr3FML+QY1qehuDxVsW1mMwhPu7R4EWscWaRoUa6VgaQcDW948Q7w
q5Xygx/KsBHTqUUtKrRuEiIcbeWVpmw75lOiT1bIEnrnS63CNf0yLonyRALredR2
YekxjLONDN7buYWIsZ9FkLsB4zoiCs7/o41J4fgZGItXqaFZztWBeYPCdrlHYAzZ
4u4QdUgrJFLVBMYUQnJCRsto4b+IhDAF5vprkNNed1CVw4IWDvNzCRtPpV43PSCV
L5pn94XMaUVF9u35Pex6dPS8jh4/hIJWX3UyLPYiyNql+wVf2LylMuCM3sdBtXxg
eQikARgB1uHAAks+B/xCF2bQZoukTo0vO4qXUs/bpSEZzxMwVpAPYXo2fs5c5CYq
9zpjeXhKTaw2KooHwftu67LRkSlrWsnwDkcbR5Ug44Jss6KzIB1kHyVxODPrtZqW
s69236xlavNtxQuwYGbW
=bZmc
-----END PGP SIGNATURE-----

Since I did some forging on test net after testing non-unique asset names, my node generated blocks with such assets, that are being rejected by all other nodes running older code, so we have a fork on test net. It would be interesting to see how this gets resolved once the test nodes are one by one updated to 0.8.11.

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

Release 0.8.11

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

sha256: 7c538041c1c2f07a1eab1f1f88ff0d5d91961e0eac5004520e00585e411e9382


Change log:

Allow non-unique asset names.

Added getAssetsByName API call returning a list of all assets
with given assetName.

Added getAllTrades API call returning all trades starting from
a given timestamp (contributed by Antanst).

Improved the JSON responses for several API calls:
getAsset now also returns numberOfTrades. getAccount now also
returns unconfirmedBalance. broadcastTransaction now also returns
transaction hash. getAsk/BidOrder now also returns order height.
Performance of getTrades should be greatly improved, and it also
returns block id for each trade.

Explicitly stop all jetty servers when Nxt.shutdown() is called.

Escape text inserted as peer software or peer announced address
in the NRS client html, to prevent cross-site scripting and
related attacks by malicious peers.

Now that Crypto.sign() never produces bad signatures, no need
for additional call to verify() after block sign, or for
multiple transaction sign attempts.

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

iQIcBAEBAgAGBQJTKaInAAoJEFOhyXc7+e2AvWIQAK8UNOU0qA8BKjh/UwCqVYKJ
5knIKtsq7Qg8XoY8KWwy5FDQH+C/tccd3GB6nRUA8XeV0Sswcc6mlPMVZixWZOnu
Pb1dtsnigLiDb9UWvi8HD3gTAocd+vnqojfa9lnRujR8gYXQxnQxoIMiVTYcyr5k
Ck5dfa873Co3WZvOXtRZi7FQboQTtfWJFgt+fkizNdMMPXyDSSwlpWvEY3G8qlcJ
dr0DRanllCTTdCLvDGHmNdyzJAQWvqmXLABdCQerWz2ufxaaPeqFL8iIjdq+nA15
5eLMjGNkblibBInid33MMdtyLVuTeRGEe6wVbvoN64P7jTFoV8B8E3owfpAaxGaD
euDIGbHi7AlMuQ/y1EJ5zIsEmD3eXVrwb34LSs+VRCWqmJU4Qpp36C+pHk89GpJk
9fV3dBXVXhcs3/TUpABqSHXLc95HL93w9K/GvUd2HbhjExy8M2RPRUGSYpNdeoW9
VVx0Mt6Zwv8nxnF/JhNbTIQZVrnWkx6ZPXKSDt/FWbYl1SzaMuATHyl0js0/luZw
t1YU376na2QPDk744njMwN5f7x/Tyow4XGDRKWr7q8oxdFzBd3SbQ5gZmrpR6MO2
3yoVHiw66ZDEfEXC5CuuEwnoFJ8cEXBDpqhK5enJFHjZ+P3fE5fngJcmguSmPFjU
dMmV55WRQfFCzXGXOWQr
=8b11
-----END PGP SIGNATURE-----

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

Release 0.8.10

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

sha256: 10dad2cd0fa509a66c86ab3a39c9a702e9a1ded483879708125f5a2540827cfd


Change log:

Better transaction attachment validation. Blocks that incorrectly
got accepted but later fail to be processed for any reason, will
be deleted from the database.

Better validation of minimum fee for different transaction type.

GetAccount API will also return unconfirmed asset balances.

BroadcastTransaction now verifies the signature of received
transaction bytes before broadcasting the transaction.

Removed forging code no longer in use. Generating blocks below
height 30000 (transparent forging phase 1) is no longer supported.

Made Db.getConnection() public and added Blockchain.getBlocks and
getTransactions methods taking PreparedStatement as parameter,
for use by Java API clients.

Added an APITestServlet for manual debugging and testing of the
API. All http API calls will now automatically be listed under:

http://localhost:7876/test

or if you need to try only a specific one, e.g. getBalance:

http://localhost:7876/test?requestType=getBalance

Unlike the admin.html page, this listing is automatically
generated and will include all available API calls without
having to be manually updated when a new one is added.

Applied the patch to Curve25519.sign() suggested by DoctorEvil.
Block and transaction signing should no longer fail to verify.


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

iQIcBAEBAgAGBQJTJCM+AAoJEFOhyXc7+e2Ak98P/3HKv7J+amawNwLZLeCgyn8y
35J7DPNFVZJDgCAmODrnJxUFO/3xFkr3d/6D4uLFrBR7X+lXtbCZEePUHpu5XuAz
lu4ZndbMqmSWKMnKichMaQVnr2T3+IeYxyY/nTTY35B0gMUTCGJq2yu+SpR0Rc0n
0H1/1nou9ExhWnPoJDxK4Daoh5fI1+UlqGeLFLFD7GQ2R+T40dBI5JIy3shLtkdW
eI3/d2rKHF+80FfRIFdqUdyD77NeC/q46vB8NdbWUYtRcQpz9fs7UAIw4gdt2FdV
/KGTaUdF2JQgoZ+4/IZAxBZ49pNjsGrG4OckCl5f/oZQ2lMuHE72CHBS1hL64qMP
PPsyTSzrgyp54jbowiKJoPQ7z6fIhmjGAluWVwOiYzx1zkcoHEmzysHlyMLyPBNq
xE4gf37w4L3oNIBBlKl2G9jo7PcwOLMK65kjFJL4oUA5DQHyaGnfhq5haY4nLQ3r
2/dzV0tyQYvVZTpz2e7fV5TsaarszgwKW/Cf5Vc/kT17CaguBnCZ+2RiQv1YFGF0
TEIQf1VYgGn2P5ijfLtXRACYbwPjdGO6Iw5dPJy7QAOObEvhQWk0UrUSG2kAEeqZ
TRX+p9MaOxXC/bgGKb3hlFrEproB5r+6ZKkiP4Fsq9Wt09v+YG03fkNd3aL4hc2U
SRgvolffGgLPwtRLKZ82
=BDFr
-----END PGP SIGNATURE-----

I want to make sure people understand that it is not "trustless" signing. Unfortunately, the way we are doing it, you still have to trust the server. You don't send the password to the server, but you sign an array of bytes that the server sent to you. How do you know that this array really represents the transaction you intended to sign? To be sure, the client would need to parse and verify it, so the client needs to know exactly how each transaction type should be represented as a byte array. This is not a secret, it is in the source code, but if you need to implement this logic on the client side, you might as well construct the byte array yourself, and not trust the server to do it for you correctly. So by letting the client be simple and lazy and let the server construct the byte array, you necessarily have to trust the server. Furthermore, you have to trust that the server response you received has not been modified in transit - and the issue of using SSL to talk to the server becomes important again.

I don't use unit tests now. Those are not substitute for functional testing and QA, and I share the view that for new features unit tests are not that useful. I prefer testing the whole system, in conditions as close to production as possible, and this is why I worked on making the test net easy to participate in for everyone.

Well, just things like the above, I never realized the unconfirmed asset balance was not available in the API. There are also calls that are not efficient, requiring multiple requests first to get some object ids, then to get the objects themselves one by one. Then there are calls that are partially redundant or duplicate, like getBalance, getAccount, getAccountPublicKey. getAccount already returns balance and public key, why do you need the other two? Fine, getting the assets for an account is more expensive and should not be done if not needed, but for getting the balance and public key the work is the same. Looks like those were added one by one on as-needed basis.

No more 0.7 releases. I don't have the time to maintain two branches, and asset exchange features and bugfixes are not in 0.7.

I haven't had such problems with forks on 0.8, I saw a few rescans today but now it has recovered without need for restart.

You need to use Account.getUnconfirmedAssetBalance(). Of course I just noticed it is not returned in the http API, sorry. I will add it.

The whole http API needs some critical review and improvement.

No changes to the default properties.

Right, or you will have to calculate the public key from the secret phrase on the client side too.

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

Release 0.8.9

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

sha256: fccd8dcb964a357e2f2546aa36dae83df7ff5e623a0dda2351cbe506c139c76d


Change log:

Client-side transaction signing support. All http API requests that
create a new transaction, now accept either a secretPhrase or a
publicKey parameter. If secretPhrase is supplied, transaction is
created, signed at the server, and broadcasted by the server as
usual. If secretPhrase is not supplied, but a publicKey parameter
is, as a hex encoded byte array, the transaction will be prepared
by the server and returned in the JSON response as transactionBytes.
This byte array can now be signed by the client, and then sent back
to the server for broadcasting using the broadcastTransaction API.

Transaction hashes, which can be used to uniquely identify transactions
to avoid transaction signature malleability attacks, can now be
obtained using Transaction.getHash(), and are also available in the
JSON representaion of transactions. The hash can also be used to retrieve
a transaction from the server, instead of using transaction id, by
supplying a hash parameter to the getTransaction http API instead of
transaction parameter.

For improving performance, getBlockId and getBlockTimestamp Java API
methods have been added to the Transaction class, to avoid the need
to call getBlock which may require additional database query. Java
clients should use those instead of going through getBlock.
Similarly, the blockTimestamp field has been added to the JSON returned
by getTransaction and the other API calls that return a transaction
JSON, so http clients can also avoid unnecessary calls to getBlock.

Upgrading to 0.8.9 will modify the database to add the hash and
block_timestamp columns to the transaction table.

Transactions that have become invalid will now also be removed from the
re-broadcasting pool.

Moved all global constants to Constants.java.

Improved transaction validation for Asset Issuance transactions to
avoid misleading invalid transaction errors.

Corrected handling of transactions with identical timestamps in block
generation and in the NRS client UI.

Added ASSET_BALANCE and UNCONFIRMED_ASSET_BALANCE events to Account,
fixed possible problem with asset balance calculation.


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

iQIcBAEBAgAGBQJTIZ8pAAoJEFOhyXc7+e2ASMoP/jzSzsX4tmi9RORPEQYpsK5r
Qt5QL55L3D0FkNBQJ30VCZ79dYk2ihjdT816TNErDl8izm2iOhj08rugsrlIsFXB
ld+688KtfUUGyt0o59yarhV5CI3fPxWCb0Fvkyjc8d8P1VlnJnPWYbDk8dMZdns7
dpICau9niIn2WcePC70fyIRQuiP1i9gFaFIOHWhCqsb33iQ9+mKCd4b9K+xk/sWe
P4R8w70jsEJgVkUbLYuQPglel0sPKp2HTVnNH1QExRPbXaA1WhnJ3bA1sHDir6al
hGAv3WRuYubZ78IsAjNGgw9WbIZs9aFcN2+ayfENkDb/s9qp6Pg7TVRvDOQb1kxN
NWWEhG+IrEhcO+85sujOoO9S7ShIoMvpUaPcmcbmUc6xnYcDYeTyX6++VaYE9wV1
GX0jbLcP8yQ+Nj+o7eiFRHekDLrrY5ubZM/5B+qvASAwA8LUZhGK7kT6d2qREAT5
ryxwcTsP0R0hpe8P5yBR75vbvfiPM10M37rQlZGFxqBfYgmG3ZqcGoNtg+ZC2Yl5
ox+m5Vg1U1D5r9OjzFXh5uAUG7C63z/EIJRxNBP/jiOAzON+rJwLHgIqWogsSYvI
XxrKhXyorO4qU9vq5nUHsmWp9jIWwctZ8lRNjWkZSpIsLRsRoKKSDRT1H7cA7gK8
k3fTldSikmyFsWz6CYak
=k0em
-----END PGP SIGNATURE-----

Not a bug, effectiveBalance can be negative.

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

Release 0.8.8

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

sha256: 837973d4313b6d3e835ff46c41870ca5ced367b8dc8a160a912d8124f1721b5e


Release 0.7.7

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

sha256: 7a8b4430a78b044871ab676caad8eb36384135d6dc694c0a4ca24c51805fdc24


Change log:

Fixed incorrect setting of genesis block timestamp when
local time is in the daylight savings period. This must
have been the reason for users in the southern hemisphere
being unable to forge.

Since DST in the US starts March 09, it is critical that
at least those in the US upgrade to 0.8.8 or 0.7.7.

There are no new bugfixes or features in 0.7.7 relative to
0.7.6 other than this daylight savings time fix.


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

iQIcBAEBAgAGBQJTGZm8AAoJEFOhyXc7+e2AC28P/iviF4g2sV8YN/e2a5bKwfKR
JY8Fe1qMLQEGaNJKVoL+h7W4DKzzh+qcIf7t0zqY9idEFZn/oU5gSXsbcQrpQwTz
IZ6bVZTf6WH81e3aSfIZ4Th9XsBJ6/GZSeaIcy95AhToqOZW37kA1WaVjRysCP9W
ZWeagUpyQMmc6au1YboR9JmJVlRFZmMpeNIOWjciwZW5YIBATSweYMroBK4It1FQ
5sUBDEfs5m8KcRC9/io3gQFLajyZ7UfgK2sffavWYz/yS+wI3xM5XhAJX9hdG3HF
DQFyGFIMPEI7/19rsH7XHiRuVhqOcCWaQDtz8HuKaIb37pP05A9VhRZa6VteTPOr
lyDLz5v0ldl8C+0ykR1RJ/iq/zGpBvvWhiX6daro3u5o37CyoIt6kwjDQ7ANvBxO
BbCuW5hb567G3VdWcl2gcWryQ0bZnVtZ4okZ++q2B7c3xoQfjw6SOwouI+Ib/cCr
ZhqaHRWaDAlbciaceGGZB0Cutz/3AboOl/Kf3AXlsmCANjWk1rkhu0FeU4QNLOqm
gU5ghmUvs+Nukm/c2dyidY+ZqupuQ2o/BxmF3IztFnepC6xfUNm8luWgUoB65kCC
938QQrPBeU11QTUqKNV/wOG6AGSqOlPqtOqA6q8JQ6GsxzneFv4yojgJpF1CbBrA
2uqeZtE9GyhNuIujZDqZ
=ZpRQ
-----END PGP SIGNATURE-----