Topic: | Nxt | Blockchain Platform | Proof of Stake | Official - page 190. (Read 941285 times)

How to upgrade the nxt client? I found a post explaining it but the url it claims, that should be used to automatically update the client, does not work. The page does not exist. So it might be an outdaten tutorial.

When i have the wallet open it states that i should upgrade. Only i don't know how.

Anyone can explain?

Eric Grill of http://coinoutletatm.com/ explaining how they use the NXT Messaging feature for recording their transactions.

https://www.youtube.com/watch?v=FN0gUIVYu2s&feature=youtu.be&t=10m36s

There is more action in www.nxtforum.org if you didn't register yet

Glad I found this thread, it was so buried under the other crappy cryptos.

NXT is really my old favorite, I hope you guys will deliver this coin into the top 3. I see ethereum is just a bad joke, this coin is the real deal.

I hold a moderate amount of NXT, and I will hold it long term Good luck and keep working hard on it!

New Experimental Release of NXT 1.6.0E!



Peer services:

Peers can advertise to other peers the set of services they provide, and
include this information when sharing peer addresses with each other. Currently
available services are Hallmark (being a hallmarked peer), and Prunable
(providing archival and retrieval service for expired prunable data).

To configure a peer to provide the Prunable service, nxt.maxPrunableLifetime
must be set to -1 and nxt.includeExpiredPrunable must be true (default). Such
a peer will then provide expired prunable data to other peers when requested.
If nxt.includeExpiredPrunable is false, the node will still keep prunable data
indefinitely (if nxt.maxPrunableLifetime is -1), but will not provide them to
others.

The services a peer provides are also exposed in the getBlockchainStatus and
getStatus APIs. The getPeers API accepts optional service parameter, to
filter the result based on desired provided service, and includes the services
each peer provides in the peer info.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 1.6.0e

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.6.0e.zip

sha256:

e0a3eaca084fbe89cad5890ac9cb94a2e0c06bef5fe065c84702ff53e643aa4d  nxt-client-1.6.0e.zip

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.6.0e.jar

sha256:

49281f76b855e218e4f69a60f8cba6aaa5c0deeb382615196f6f728e958a01e7  nxt-client-1.6.0e.jar

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.6.0e.exe

The exe and jar packages must have a digital signature by "Stichting NXT".


This is an experimental release for testing only. Source code is not provided.


Change log:

This experimental release adds several major new features. It does not require
a hard fork, and update to the 1.6 branch will be completely optional even
after it is declared stable. 1.6 peers are compatible with 1.5 peers, but as
usual the database changes are not reversible, going back from 1.6 to 1.5
would require starting again from a 1.5 database.


Account ledger:

The account ledger feature provides a record of all recent changes to the
account balances (including NXT, asset, and currency balances), and the event
that caused each change. It is enabled by default for all account, but can be
set to track certain accounts only or be disabled completely, using the
nxt.ledgerAccounts property. By default records are kept for the last 30,000
blocks, this can be changed using the nxt.ledgerTrimKeep property.
The nxt.ledgerLogUnconfirmed property controls whether confirmed, unconfirmed,
or both types of changes are tracked.

The new APIs getAccountLedger and getAccountLedgerEntry are used to retrieve
account ledger records. Their parameters and response fields are documented in
the javadoc.

Account ledger events can also be followed using the existing eventRegister
and eventWait API.

Using account ledger events as an alternative to the getAccountTransactions or
getBlockchainTransactions API completely avoids the need to handle phased
transactions as a special case. Only changes to account balances that actually
happened, and at the time (block height) they happened, are recorded in the
account ledger. The account ledger also makes it easier to monitor an account
for changes that occurred as a result of past transactions (e.g. an AE order
being filled), or are result of dividend payment transactions, or block
forging fees.


Peer services:

Peers can advertise to other peers the set of services they provide, and
include this information when sharing peer addresses with each other. Currently
available services are Hallmark (being a hallmarked peer), and Prunable
(providing archival and retrieval service for expired prunable data).

To configure a peer to provide the Prunable service, nxt.maxPrunableLifetime
must be set to -1 and nxt.includeExpiredPrunable must be true (default). Such
a peer will then provide expired prunable data to other peers when requested.
If nxt.includeExpiredPrunable is false, the node will still keep prunable data
indefinitely (if nxt.maxPrunableLifetime is -1), but will not provide them to
others.

The services a peer provides are also exposed in the getBlockchainStatus and
getStatus APIs. The getPeers API accepts optional service parameter, to
filter the result based on desired provided service, and includes the services
each peer provides in the peer info.


Restore prunable data:

A peer configured with nxt.maxPrunableLifetime=-1, or any positive value
higher than the minimum of two weeks (1209600 seconds), when downloading the
blockchain from scratch, will automatically start requesting the missing
prunable parts (prunable plain/encrypted messages, and tagged data) from any
archival peers it finds on the network (those providing the Prunable service).

This task of requesting and restoring missing prunable data can also be
triggered using the new retrievePrunedDat debug API, for peers that already
have the full blockchain or need to be restarted during the download process.

(Note that when nxt.maxPrunableLifetime is set to a positive value, extend
tagged data transactions are ignored for the purpose of selecting which
pruned tagged data to retrieve, the timestamp on the original upload data
transaction is what is being used. To make sure all pruned data are retrieved,
set nxt.maxPrunableLifetime to -1, and if really needed set it back to the
desired value after the initial restore is complete.)

The getBlockchainTransactions API now accepts optional includeExpiredPrunable
parameter, to force including expired prunable parts in the response, if
available (default false).


Asset delete:

Asset transfers to the Genesis accounts are now treated as deleting the
corresponding number of shares, with the total asset quantity adjusted
accordingly. A new deleteAssetShares API has been added to perform this
function. At the next hard fork (1.7), asset transfers to Genesis will be
completely disallowed and the deleteAssetShares API will then create a new
AssetDelete transaction type, to achieve the same quantity reduction effect.


API additions:

A new getTaggedDataExtendTransactions API has been added, to retrieve all
tagged data extend transactions for a given tagged data upload transaction.

The getConstants API now also returns a list of all supported request types
and their properties.

The approveTransaction API accepts revealedSecretIsText boolean parameter,
default false, as a way of specifying whether revealedSecret is text or
binary. The old revealedSecretText parameter to submit the text value
directly is still supported.

Added encodeQRCode and decodeQRCode APIs, to handle the encoding and decoding
of QR image on the server side, instead of in javascript, using the ZXing java
QR processing library, version 3.2.1. This improves the generation and parsing
of QR codes used in offline transaction processing, images that failed to
decode correctly using javascript can now successfully be processed.

Allow attaching encrypted messages to accounts that don't yet have a public
key announced, as long as the public key is included in the same transaction
as a public key announcement attachment.


Several performance optimizations have been included in this release:

The last 10 blocks and the transactions in them are now cached in memory.
The unconfirmed transactions (up to nxt.maxUnconfirmedTransactions, default
2000) are also cached in memory.

Accounts with zero balance are now deleted from the account table, which
significantly reduces its size and should make queries for the balances of the
active accounts faster. Only public keys for such accounts, if available, are
permanently stored in the separate public_key table. Creation of new accounts
for one-time use, which is the practice of many exchanges and merchants,
should now be less of a burden for the database, as long as such accounts are
fully emptied after use.


Updated jetty to version 9.3.2. If unpacking on top of a previous installation,
delete the old lib subdirectory first.

This release will perform a database upgrade and rescan on first start.


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV8sIcAAoJENqvaxkWiP4ZvZQP/iWOYYj2PjqPp1OjtQt/nxbe
7sAUJBhISvc+NBSGCly53W34t/+QsPhE0eOoY9EZ6vvKqsvAXdDUFYdMKHbX2FZx
gni32IxFMmDb64HlaG07GFSWvXAPwA/+lJCeWwBVwnkF9HvLJaTpdmG4+u9howsb
OFeE6IAvHYAdEJLDpB27Fm3knQkTS4e0j3RJUtHt9DmREq0O+x4TByK1RnwAjQs2
NciTpIbKAN3T7OKzonES+5rQtXnp5pLulA7jw3QyfXTpIRu3DgKFXKobZbI8zHvK
2e2zGsrA7F267d6xYsPL1TjtqSKldxjuX0RP2zAd28yS0SNAll2Zq+4qFM4dPOBw
3jcbb3ecMySeJ7KI9SJxeq2PWA1ogLfs7/NvCAwLmgs7cPAmLgHE3LP/6HeL6ox2
Z/d/t+NvPHyTPh5DLXQ9q9rJNFKCWAd5NTmSyd4KZVbhm7/mVpWJwnH6CacE+8bX
4FDaA1uQh+4FVbzvBldlNGj7Q/mziNvz36cg0B3Dn/Bfgx04Bp3OPDhh+I/uU/Hw
i+d3lr73UZlYNHkwMdtkFNnJ/mITBe02SRwpo07UvCWPYCSso5OacNC2n9rHnCOc
Aqqy894h7WtNg60cFM4fBBC44UzMpECFIvOwCtOWEhzS8ES8S6Ly3nzYkp3RMOoq
NCZgq03lVoyf7Kkk7GPO
=7ack
-----END PGP SIGNATURE-----

Wow, great place to present Nxt to decision makers in finance. How did you bring Nxt to discussion?

Brainwallets are usually very safe if you choose a strong password. It is recommend to use a password of at least 20 letters, numbers and special characters. I usually use a password of at least 100 chars.

Regarding the hacking of brainwallets at DEFCON 23 and the death of brainwallet.io, how safe are nxt-addresses when they had their first output?

When brainwallets are hacked that easily then it sounds risky. Though those nxt addresses only can hold something of value once their security was updated with an incoming transaction, right?

So is the brainwallet a risk or not?

I am happy to announce that NXT will be on a panel at the Barclay's Select Series events on the 15th of September: https://events.barclays.com/ehome/131090/298522/?categoryid=1101963


You will see my name still on the list, but I will be replaced on my request by Nick Grove of NXT2PAY, who will speak about NXT from the perspective of real use cases. Will be changed on the site, soon.

15:10 - 15:50     Panel discussion: Bitcoin and Virtual Currencies move mainstream
Tony Gallippi, Co-founder / Executive Chairman, Bitpay
Nicolas Cary, Chief Executive Officer, Blockchain
Bas Wisselink, Co-founder, NXT Foundation (This will be Nick!)
Tom Robinson, Chief Operating Officer, Elliptic Enterprises Ltd

The good thing about this is that Nick wears a suit much better than I ever could, too!

Regarding the hacking of brainwallets at DEFCON 23 and the death of brainwallet.io, how safe are nxt-addresses when they had their first output?

When brainwallets are hacked that easily then it sounds risky. Though those nxt addresses only can hold something of value once their security was updated with an incoming transaction, right?

So is the brainwallet a risk or not?