Nxt Client (NRS) 1.11.7
Exe and dmg digital signature: "Stichting NXT"
.sh Sha256:dca642ffa8a2508c72af9246dc224af3f4e523427b77b1e7a026fe0ea57e05cd nxt-client-1.11.7.sh
1.11.7 .zip sha256:
NRS 1.11.7 release notes
This release adds the ability to submit a JLRDA purchase transaction from the IGNIS Token Sale page even before the sell offer has been published.
Such transactions are not broadcasted immediately, but held in memory and only sent out when the expected sell offer arrives in the unconfirmed transaction pool.
For this to work, you must keep the node running after submitting the purchase transaction, until the sell offer has been received and processed.
Note that after submitting a purchase transaction in advance of the sell offer, you will get a pop-up that your currency buy order has been submitted, but it will not show in the unconfirmed pool. This is normal as such advance orders are kept separately.
This functionality is currently available for full nodes only, i.e. those that have downloaded the full blockchain. Users of light clients can submit JLRDA purchase transactions only after the sell offer has been accepted in a block. To switch from a light client to full node, set nxt.isLightClient=false in conf/nxt.properties, and wait for the blockchain to download.
More IGNIS Token Sale UI bugfixes and improvements:
Add paging buttons to the exchange history table on the Ignis page.
Initialize the JLRDA units field to 0.
Fixed "calculate fee" when connecting to a remote node with remembered passphrase.
Implemented TransactionScheduler, added ScheduleCurrencyBuy and GetScheduledTransactions APIs.
ScheduleCurrencyBuy API accepts same parameters as CurrencyBuy API, and an additional offerIssuer parameter. Instead of broadcasting the prepared transaction immediately, it schedules it to be broadcast as soon as an unconfirmed currency exchange offer transaction from that issuer, for that currency and a sell rate not higher than the requested, arrives in the unconfirmed transaction pool. The broadcast parameter must be set to false. This API requires a full node (not a light client) and admin password unless running on localhost.
GetScheduledTransactions API returns a list of all scheduled transactions for a given account.
Note that these APIs were specifically added for the purpose of the IGNIS Token Sale, and may be removed or modified in the future.
Other fixes and improvements:
Allow blacklisting the real remote host, not the proxy, when running a public node behind a reverse proxy. Use the nxt.forwardedForHeader property to configure the header added by the proxy to the API http requests (normally X-Forwarded-For).
Fixed printing of paper wallet for passphrases containing special characters.
WARNING: If you printed out a paper wallet for an account passphrase which contains special characters using an earlier release, this passphrase may have been printed out incorrectly, with those characters missing, or truncated. In this case you are advised to print out a correct copy using this version. The QR codes were not affected by this bug, and neither were the standard account passphrases generated by the client.
Also note that some long passphrases may be cut off by your printer unless page size is adjusted to width.
ALWAYS VERIFY THAT THE PRINTED PASSPHRASE IS CORRECT BEFORE RELYING ON A PAPER WALLET AS YOUR ONLY BACKUP!
The NRS (Nxt Reference Software) Client is the Nxt core developers’ official wallet release.
NRS is a locally hosted client server application. By default it downloads the Nxt blockchain, but from version 1.10.0e you can run it as a light client as well as a full node. To forge and earn forging fees from processing transactions on the network you must run the Nxt Client in full mode, which is possible even on small devices like laptops, or on a Raspberry Pi.
The Nxt Client is easy to install. Use the 1-click installers for Linux, Mac and Windows or read this INSTALLATION GUIDE to launch the NRS .zip from terminal.
ICO Release FAQ
Q: What's the priority to execute these buy orders when they will hit blockchain? Same as usual?
A: As soon as the node scheduler storing the scheduled transactions sees the exchange offer as an unconfirmed transaction, it will immediately broadcast your currency buy transactions.
And they will compete with the rest of the transaction for inclusion in the next block, according to the usual transaction priority.
Q: So, if I understand correctly, this new stuff is for users to make buy transaction in advance, instead of lurking near PC and try to be fast?
Q: And if my advanced buy order is not filled, I need to repeat the same before the next batch? Am I right, this new stuff do not solve MAAC problem?
A: It does solve it, since MAAC found a way to submit his transaction while the Jelurida exchange offer was still unconfirmed and invisible to the UI.
With 1.11.7, every scheduled transaction will do exactly that.
Q: When does Jelurida exchange offers become valid? Only when approved or broadcasted?
A: When the Jelurida exchange offer is still unconfirmed the scheduler will submit the buy orders
Q: Will not wait for approval of it?
A: They will all approve in the same block, the exchange offer will have the earliest arrival time so the currency buy transactions will match it in the same block just like MAAC did it manually
Q: But looking at history, approval account approves exchange offer few block later. I feel some confusion here. Always thought, that without approval any transaction is not "valid".
A: The exchange offer will no longer be phased, just a regular transaction
Q: And if my scheduled buy order is not filled, I need to repeat the same order before the next batch?
A: Yes, as usual, however you'll compete on level terms with everyone else
Q: What do I need in order to submit a scheduled transaction?
A: You'll need a full node running on localhost, or a remote full node to which you have the admin password. As usual your passphrase is never submitted to the remote node.
NXT Mobile app