-
Notifications
You must be signed in to change notification settings - Fork 5
/
changelog.txt
5885 lines (4047 loc) · 245 KB
/
changelog.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
nxt-client-1.10.1:
This release adds transaction replay protection, to be enabled at the hard fork
scheduled for block 1,000,000. Upgrading to 1.10.1 or later before that block
is mandatory for all.
The ecBlockId and ecBlockHeight transaction fields, previously populated but
not used, will begin to be used for enforcing that a transaction submitted on
one blockchain or fork will not be accepted on another blockchain or fork that
shares the same code. These fields by default will be set to a block 720 blocks
behind the last block at the time the transaction is created, and transactions
will only be accepted if their ecBlockId and ecBlockHeight values point to an
existing block when they are included in the blockchain. This default setting
provides protection against replaying the transaction on a hard fork that has
diverged more than 720 blocks from the one where the transaction was created.
Light clients that have no way of verifying the ecBlock values returned by a
remote node will use hardcoded values, to be updated manually at some releases.
Transactions from legacy light clients that leave eBlockId and height set to 0
will still be accepted, but cannot benefit from such replay protection.
All CreateTransaction APIs now accept additional ecBlockId and ecBlockHeight
parameters, allowing the default values to be overridden by the client.
Minor bugfixes and UI improvements.
Updated Jetty to version 9.3.11, delete the old lib folder before unpacking on
top.
--------------------------------------------------------------------------------
nxt-client-1.10.0e:
This is an experimental release introducing the new light client and roaming
client features.
The roaming client feature, enabled by default, makes the client immediately
usable by forwarding API requests that need the full blockchain to a randomly
chosen peer (remote node), selected to provide the openAPI service. As all html
and javascript files are still served locally and not from the remote host,
this is considerably safer than just using a remote node. Outgoing transactions
are also signed locally, never sending the secret phrase to the remote peer.
This roaming client (API Proxy) mode is used automatically while the blockchain
is still downloading, with a switch to full client mode once the download is
complete.
It can be disabled by setting nxt.enableAPIProxy=false in nxt.properties.
For openAPI nodes, the API proxy remains disabled, ignoring this setting. For
light clients, the API proxy is always enabled.
The light client feature, disabled by default, makes the node run in roaming
mode permanently, without downloading the blockchain at all. It can be enabled
by setting nxt.isLightClient=true.
Light clients are not advertised as providing openAPI service even if they do
have their API publicly accessible.
The remote node to use when in roaming and light client modes is selected
randomly, but can be changed manually in the UI, or using the new
setAPIProxyPeer API, or forced to a specific peer using the
nxt.forceAPIProxyServerURL property.
Remote nodes can be blacklisted from the UI, or using the blacklistAPIProxyPeer
API. This blacklisting is independent from peer blacklisting. The API proxy
blacklisting period can be set using the nxt.apiProxyBlacklistingPeriod
property (default 1800000 milliseconds).
API requests that require sending the secret phrase, shared key, or admin
password to the server, for features like forging, shuffling, or running a
funding monitor, are disabled when in roaming or light client mode.
While a remote node cannot steal your secret phrase, and data returned by such
nodes is escaped to prevent javascript injection attacks, users must be aware
that the validity of such data cannot be verified. For example, a rogue remote
node can still return fake asset exchange recent trades or open orders prices,
or modified voting system poll options and descriptions.
To force using a remote node for testing APIs, the /test-proxy URL can be used
instead of /test for the API test page, i.e. http://localhost:7876/test-proxy.
A new sendTransaction API has been added, similar to broadcastTransaction but
without validating the transaction, without re-broadcasting the transaction and
without adding it locally as unconfirmed transaction. This API is mostly useful
for light or roaming clients that cannot validate or accept locally unconfirmed
transactions, but must nevertheless be able to send such to peers.
A new getNextBlockGenerators API has been added, returning the next block
generators ordered by hit time. The list of currently active forgers is first
initialized using the block generators with at least 2 blocks generated within
the previous 10,000 blocks, excluding accounts without a public key. The list
is updated as new blocks are processed. The results are not 100% correct since
previously active generators may no longer be running and new generators won't
be known until they generate a block.
Added a peer info modal. Minor other UI improvements and bugfixes.
--------------------------------------------------------------------------------
nxt-client-1.9.2:
This is the first stable release in the 1.9 series. Update to this release on
mainnet is optional up until block 1000000 (Oct 12), however users are advised
to do it earlier, as after July 14th updating will trigger a blockchain rescan.
The main new feature in 1.9 is the distribution of ARDR assets. See the 1.9.0e
changelog for details.
Performance optimizations for blockchain rescans and for snapshot balance
calculations. Added nxt.dbMaxMemoryRows property to allow setting the H2
MAX_MEMORY_ROWS parameter.
Updated Jetty to version 9.3.10, delete the old lib folder before unpacking on
top.
--------------------------------------------------------------------------------
nxt-client-1.9.1e:
Fixed a client UI bug affecting some form submission.
--------------------------------------------------------------------------------
nxt-client-1.9.0e:
This is an experimental release. It is a required update for all testnet nodes,
optional for main net.
This release enables taking multiple snapshots of accounts NXT balances, every
60 blocks, for a period of 90 days, and distributing an ARDR token based on the
average of those balances, at the end of the snapshot, to be used for the Ardor
consensus chain token distribution in Nxt 2.0.
On testnet, the snapshot will start at block 649400 and end at block 779000
(June 24).
On mainnet, the snapshot will start at block 870400 (expected July 14) and end
at block 1000000 (Oct 12).
Since on testnet the starting block is in the past, on upgrade to this release
a blockchain rescan will be performed automatically in order to calculate past
account balances. Those who delay upgrading their mainnet nodes until after
block 870400 will also experience such a rescan. However, the hard fork block
is set at the end of the snapshot, so the final deadline for upgrading to 1.9
is at blocks 779000 and 1000000 respectively.
To get your ARDR tokens, it is essential that you keep your NXT balance in your
own account. There is no need to run a node or forge. It is the confirmed NXT
balance that is used for the snapshot, not the unconfirmed (available) balance,
so having some NXT locked in open AE bid orders, shufflings, etc, will not
affect your ARDR distribution. For balances on exchange accounts, it will be up
to each exchange to handle the re-distribution of the ARDR tokens that will get
automatically sent to the exchange account at snapshot end.
A new getFxtQuantity API has been added, which allows retrieving the already
accumulated ARDR quantity for each account during the snapshot, and an estimate
for the quantity yet to be obtained. While snapshots are done every 60 blocks,
the numbers that this API returns are updated once every 720 blocks only.
Snapshot balances used for the ARDR distribution for a specific account can be
recorded in the log by setting the nxt.logFxtBalance property to that account
number, and performing a rescan if the snapshot has already started.
Added some additional transaction bytes validation, and phasing parameters
validation, to take effect after the hardfork.
Added getAssetDividends API, to retrieve the dividend payment history for an
asset. It can be viewed in the client by clicking on the new "View Asset
Dividends" link on the asset exchange page. Dividend payments made before a
node is updated to 1.9.0e will not show in this history, unless a blockchain
rescan is forced manually.
After the hardfork block, asset dividend payment transactions will be limited
to not more than one per asset every 60 blocks.
Added a new Messages table in the client UI. Allowed uploading a file as a
message attachment, plain or encrypted, and downloading such messages as files.
All create transaction APIs that support prunable message attachments now also
optionally accept multipart file uploads as messageFile or messageToEncryptFile
parameters, or when using client-side encrypted data the data part can also be
uploaded using encryptedMessageFile parameter. As the test API page does not
support multiple file upload parameters, upload buttons for those are not
currently available there.
Accept sharedKey parameter in downloadPrunableMessage and getPrunableMessage
APIs.
Added client UI support for decrypting messages using a shared key, to allow
disclosing the shared key for a specific encrypted message to a third party in
order to decrypt it without having to reveal the account passphrase.
Forging optimization to reduce block skipping when switching forks.
Minor other bugfixes and UI improvements.
Updated H2 library to version 1.4.192, tika to 1.13, and slf4j to 1.7.21. If
installing manually, make sure to delete the old lib folder first.
--------------------------------------------------------------------------------
nxt-client-1.8.3:
This release contains a number of improvements and bugfixes.
API changes:
Optional includeHoldingInfo parameter added to the GetAccountLedgerEntry and
GetAccountLedgerEntry APIs.
UI improvements:
Account switch no longer reloads the wallet.
Numeric decimal position, thousands separator and date formats are now locale
based. The default browser locale language is used by default. A new
"Regional Format" client side setting provides the ability to override the
default.
Numeric formatting is now implemented for most table columns which display NXT
amounts or holding amounts. The number of decimals positions in each cell is
calculated according to the largest number of decimals required and zeros are
padded to the right.
Amounts specified in NXT are limited to the number of decimal positions
specified by the "Maximum NXT decimal positions" client setting. The default
behavior is to display two digits after the decimal position.
UI improvements for transaction tables, displayed in the dashboard and other
pages. Height column was added as a link to the block in which the transaction
is included.
Starting the wallet on a specific asset page is now supported.
Desktop Wallet:
Right click functionality for copy/cut/paste of input fields and copy of label
text is now enabled. Right click menu on the asset exchange left pane is
enabled.
Entering admin password in the UI settings is no longer required when using the
desktop wallet.
Upgraded jetty to version 9.3.9, make sure to delete old lib folder first if
updating manually.
--------------------------------------------------------------------------------
nxt-client-1.8.2:
This is a bugfix release. All users running 1.8.0e or 1.8.1 should upgrade.
Added html escaping of product names for marketplace recent listings.
Fixed marketplace listing for items without image.
Only show completed purchases in recent purchases.
Implemented import contacts for the desktop wallet UI.
Other minor UI improvements and bugfixes.
Allow absolute paths for keystore file location in nxt.keyStorePath property.
--------------------------------------------------------------------------------
nxt-client-1.8.1:
This is the first stable release in the 1.8 series. Please also read the 1.8.0e
changelog for all new features and changes since 1.7.5. This release does not
require a hard fork and upgrading to it is optional. It will not do a rescan
either, but once upgraded to 1.8.1, going back to older version requires
downloading the blockchain again or restoring the nxt_db folder from backup.
API enhancements:
Added getSharedKey API, to allow calculating the one-time shared key used for
encryption of messages. Parameters are the secret phrase for one of the
accounts, the other account, and the nonce used in the message encryption.
The readMessage API now also supports decryption of encrypted message parts
using the shared key, as provided by the above getSharedKey API, instead of the
secret phrase. An optional retrieve parameter is also supported to request
automatic retrieval of pruned message parts from archival nodes.
The getDGSPurchase API now supports decryption of the purchased goods, using
either the secret phrase of the buyer or seller, or the shared key from the
getSharedKey API.
The getBalance API now supports an optional height parameter to retrieve account
balance at previous heights, if still available.
The getPolls and getAllShufflings APIs now support an optional finishedOnly
parameter, to retrieve only polls or shufflings that have already completed.
Add-on framework improvements:
Add-ons can now register their own http API request handlers, allowing custom
request types to be supported. Overriding existing client APIs is not allowed.
See the example add-on nxt.addons.PopOffCounter. Such APIs must be tagged with
APITag.ADDONS and will appear under "Add-ons" on the API test page.
The add-on framework supporting custom APIs, in combination with the client-side
plugin system, present an opportunity for developers to add functionality to
the NRS without having to modify core code. Add-on developers should be aware
that the Java API in 2.0 will undergo many changes, and add-ons code will have
to be updated. And users are again reminded to only install and run add-ons
from trusted sources.
UI improvements:
Added pagination to the recent marketplace listings and recent purchases pages.
Added finished polls and finished shufflings tables under the active polls and
active shufflings respectively, with pagination. A "view" action for polls now
makes it easy to view the results of an active or finished poll.
Added full-size image display in a new modal, when clicking on an image in the
marketplace listings or purchase modal.
Other minor bugfixes and improvements.
--------------------------------------------------------------------------------
nxt-client-1.8.0e:
This is an experimental release. It adds several new features, which however do
not require a hard fork.
JavaFX UI:
A desktop wallet UI, mostly equivalent to the in-browser UI, is launched on
supported platforms automatically when the server is started by clicking on
the Nxt desktop icon or start menu shortcut.
More details about the JavaFX UI are available at:
https://bitbucket.org/JeanLucPicard/nxt/issues/338/desktop-wallet
The property nxt.defaultDesktopAccount can be used to specify an account to
login to automatically once the desktop wallet loads.
The desktop wallet UI can be disabled by setting
nxt.launchDesktopApplication=false
The pre-compiled package will still run if JavaFX is not available, but to
recompile the code on such platforms the compile-nojfx.sh script must be used,
which skips the compilation of the desktop wallet.
The installer now creates a start and stop menu shortcuts and desktop icons on
Unix platforms too, which start the NRS client in desktop mode. From the
command line, use the new start.sh script to start the client in desktop mode,
and the corresponding stop.sh script to stop it. The start.sh and stop.sh
scripts can be run from any directory.
The jar installer package has been replaced with a self-extracting shell script
package nxt-client-1.8.0e.sh, which Unix users can just run, or click on, in
order to launch the installer. An advantage of using the installer instead of
the zip package is that the installer will create the above mentioned menu
shortcuts and desktop icons, and will also automatically remove old libraries
from previous installations in the same directory.
A known bug (of IzPack it seems) is that on Unix the installer fails to create
desktop icons when installing in a not yet existing target directory. It will
also fail to remove old menu shortcuts and desktop icons, so first running an
uninstall of a previous installation is still advisable.
Incompatible change:
Note that when run in desktop mode on Unix and Mac, the ~/.nxt directory is now
used to store configuration files, logs, and the nxt_db blockchain database.
This makes it simpler to upgrade to a new version, by deleting the content of
the old nxt installation directory, as no user configuration files or database
files are stored in it.
The run.sh script continues to use command line mode, i.e. does not attempt to
start the desktop wallet and desktop tray icon, and continues to use the nxt
installation directory from within which it must be run to store the nxt_db
database, logs, and configuration files. Users who want to use desktop mode but
still use the nxt installation directory instead of ~/.nxt for those files can
use the run-desktop.sh script instead.
Funding Monitor:
The new Funding Monitor feature provides monitoring account balances, and their
automated replenishment from a funding account, based on account properties set
by the funding account to the monitored accounts.
NXT, asset, or currency balances can be monitored. If a balance falls below
the configured threshold, a transaction will be submitted to transfer units
from the funding account to the monitored account. A transfer will remain
pending if the number of blocks since the previous transfer transaction is less
than the interval configured for the monitor.
The APIs for the Funding Monitor feature are StartFundingMonitor,
GetFundingMonitor, and StopFundingMonitor. Detailed documentation for those is
provided in the API javadoc files. A user interface for setting and viewing
currently running Funding Monitors is accessible from under the cogwheel menu.
Client UI page or modal redirection. By adding page or modal parameters to the
http://localhost:7876/index.html URL, the client can be redirected to open a
specific page or modal pop-up, with pre-populated parameter values.
For usage example, see:
https://bitbucket.org/JeanLucPicard/nxt/pull-requests/42/added-page-redirect-modal-popup-with
The Marketplace has been enhanced by adding recent listings and recent
purchases tables, showing the last 10 goods listed or purchased.
Marketplace listings now can have images. Image files are uploaded as prunable
unencrypted binary message attachments to the DGSListing transaction. A new
messageFile file parameter has been added to the dgsListing API, to allow
direct upload of files as multipart form data. This parameter is also supported
by all createTransaction APIs which allow message attachments, but is not
exposed on their /test API pages.
Image attachments that have been pruned are retrieved automatically from
archival nodes when the user views the page.
A new downloadPrunableMessage API has been added, to allow downloading of
prunable message attachments directly as binary data. An optional secretPhrase
parameter is supported, to allow decryption and downloading of the encrypted
part of the message instead of the plain text part.
The nxt.apiSSLCiphers property can be used to select which SSL ciphers should
be enabled for the API server when using SSL.
Unless overridden in nxt.myPlatform, the real system platform is now shown in
the peer info, as found in the java os.platform and os.arch system properties.
Other minor bugfixes and optimizations.
Updated jetty to version 9.3.8, lucene to 5.3.2, tika to 1.12, and slf4j to
1.7.18. Delete the old lib directory first when installing manually on top of a
previous installation. If using the installer, old libraries will be deleted
automatically, as well as any existing files under the classes and html
directories, excluding html/ui/plugins.
Server-side add-ons:
It is now possible to trigger script execution, or really add any custom Java
code to the server, by writing a class which implements the nxt.addons.AddOn
interface, making sure it is on the classpath, and enabling it by adding its
name to the nxt.addOns property. See the example add-ons in the nxt.addons
package. The AfterStart and BeforeShutdown add-ons can be used to trigger
scripts to be run just after the server has started, and just before shutdown.
Java source files for add-ons can be placed under addons/src to be compiled with
the compile.sh script, and the resulting class files under addons/classes will
be included on the classpath at runtime.
This is an unsupported feature for developers only. While in the 1.x series
the Java API is expected to be stable, it will undergo significant refactoring
in 2.0. Keep any custom add-on code simple, and be prepared to have to change it
for 2.0 or discard it. It should also be obvious that such custom Java code can
crash your node or have unexpected side effects.
Malicious add-ons installed under the classes directory can easily get access
to your secret phrase. For add-ons installed under addons/classes, this has been
made more difficult, but they could still do other malicious acts. Therefore,
do not install and run add-ons from untrusted sources.
--------------------------------------------------------------------------------
nxt-client-1.7.5:
Code cleanup and removal of logic no longer needed after the 1.7 hard fork has
been passed. Added checkpoint at block 622000.
Peers running versions older than 1.7 are now blacklisted.
Allow disabling of specific API or groups of API using the nxt.disabledAPIs and
nxt.disabledAPITags properties, each taking a list of API request names, or API
tag names, separated with ';'. For example:
nxt.disabledAPIs=startForging; startShuffler
nxt.disabledAPITags=Create Transaction; Tagged Data
will disable the startForging and startShuffler API, and all API that are listed
under the Create Transaction or Tagged Data tabs on the API test page.
The enabled/disabled status of each API or APITag is exposed in getConstants.
The client UI hides menus related to disabled API tags and the "Send NXT",
"Send Currency" and "Send Message" buttons are hidden automatically when
their corresponding API is disabled.
The getAccountLedger API has been fixed to always apply the firstIndex,
lastIndex pagination to the final list of entries matching the query, rather
than to all entries for the given account or based on block height.
Use fixed shuffling transaction timestamps. To prevent timestamp correlation
attacks, all shufflers now use the same transaction timestamp, set to the last
block timestamp.
Performance optimizations. Account public keys are now cached in memory. This
cache currently takes around 12 MB at most, and can be disabled by setting
nxt.enablePublicKeyCache=false.
Back button added to the transaction info, account info, block info and ledger
info modals. Use the back button to return to the previous info modal.
Updated H2 to version 1.4.191. The MVStore storage engine is disabled by default
as it is still in beta, PageStore continues to be used. As this version no
longer accepts implicitly relative jdbc URLs, if you have configured a custom db
location in nxt.properties, make sure to prefix the path with ./ if it is not
absolute, e.g. nxt.dbUrl=jdbc:h2:./nxt_db/nxt... instead of
nxt.dbUrl=jdbc:h2:nxt_db/nxt... . If unpacking on top of existing installation,
delete the old lib folder first.
Token generation is now supported when using the "Remember Passphrase" option
and the NRS.signBytes() method now uses the remembered passphrase in case the
passphrase parameter is not specified.
The transition effect displayed when hiding the left menu was disabled since
it is causing UI rendering problems under certain conditions.
"Switch Account" button added to the account info dialog. Clicking it would
switch the wallet to this account.
"Refresh Search Index" option added to the "Settings" menu. Use it to rebuild
the search index in case you are no longer getting correct search results.
Added UI for issuing singleton asset.
run.bat now works on Windows XP and Windows 2003. Database, configuration
files and logs are stored in the roaming folder under the user folder and
tray icon is operational.
Nodes that update from version older than 1.7.3e to this release after the hard
fork block will have blocks after 621000 deleted, to make sure they switch to
the 1.7.4 fork.
--------------------------------------------------------------------------------
nxt-client-1.7.4:
This is the first stable release in the 1.7 series. It is a mandatory update
for everyone. There is a hard fork scheduled for block 621000, estimated to
occur around Jan 21, 2016, at which new features will be enabled. Nodes that
do not update to 1.7.4 or later by this date will be left on a fork.
On testnet, the hard fork block is already passed, and all new features are
fully functional.
There were incompatible API changes introduced in the 1.6 series. API users
still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs
and forum announcements, before upgrading to 1.7. These changes do not affect
regular end users who just run the NRS client on their desktop or VPS node.
The new features and improvements in the 1.7 series have been documented in
the 1.7.0e through 1.7.3e changelogs, available in the changelogs directory.
Here is a high level summary of the new features to be enabled after the
hard fork:
Coin Shuffling, a fully decentralized coin mixing, to improve account privacy.
Account Control for phased transactions, the Nxt equivalent of multisignature.
Immediate release of certain types of phased transactions on approval.
Improved block times, 60 s average, long block times now extremely unlikely.
Account Properties, assigning arbitrary name/value metadata to user accounts.
Singleton Assets, useful for representing single tradeable objects.
Dynamic fees, proportional to the relative transaction size.
Improved Exchange Booth UI.
Data Cloud, adding a UI and multiple enhancements to the existing Tagged Data
feature, to allow decentralized, censorship-free and tamper-proof publication
and retrieval of small files, documents, or arbitrary data. This feature is
not dependent on the hard fork and will be fully usable immediately on update
to this release.
Changes added since the 1.7.3e release:
Added detectMimeType utility API, allowing auto-detection of the mime type of
uploaded file or data, using the Apache Tika library.
The uploadTaggedData API now uses such mime type auto-detection to determine
the mime type of uploaded data when the user has not explicitly provided a
type parameter. It also automatically sets the isText property to true for
data of type text/plain only.
Made the maximum permitted number of forgers or shufflers running at the same
time configurable, default 100 each, using the nxt.maxNumberOfForgers and
nxt.maxNumberOfShufflers properties.
The default value of includeCounts parameter in the searchDGSGoods API is now
also false, this API was inadvertently missed when globally changing the
defaults to false in the 1.6 branch.
Various UI improvements.
Updated Bouncy Castle library to version 1.54.
--------------------------------------------------------------------------------
nxt-client-1.7.3e:
This is an experimental bugfix release. It is a mandatory update for testnet
nodes.
Added retrievePrunedTransaction API. This API can be used to force retrieval
of the prunable data for a given transaction, even if past the configured
nxt.maxPrunableLifetime. Using this API to retrieve pruned data however does
not increase its lifetime, i.e. at the next scheduled table trimming the data
will be pruned again if expired. This API queries all currently available
archival peers, until the missing data is found, therefore it can take some
time to complete, and can also return no results if there are no such peers
online, or none of them has the requested data. Consistent with the behavior
of getTransaction and related API, the returned transaction JSON will not have
the prunable parts included if they have already expired and
nxt.includeExpiredPrunable=false (default is true), but if those parts have
been successfully restored, they can be requested using the more specific APIs
such as getPrunableMessage, getTaggedData, etc.
The getPrunableMessage, getTaggedData, and downloadTaggedData APIs now support
optional "retrieve" parameter, default false. If the corresponding data has
been pruned and retrieve is true, an attempt will be made to retrieve the data
from archival peers, as if using the retrievePrunedTransaction API.
Added getReferencingTransactions API, returning the transactions referencing a
given transaction id.
Added getLinkedPhasedTransactions API, returning the phased transactions with
by-transaction voting model for a given linkedFullHash, regardless of their
phasing status (pending, approved or rejected). Since the corresponding table
is trimmed after finish height however, the result will not include those
transactions that finished before the last trimming height.
Increased maximum leasing period to 65535 blocks, to take effect after the
hard fork.
Shuffling UI improvements.
Added UI for the Tagged Data feature, now known as Data Cloud.
The Exchange Booth UI has been improved. The user must only enter the number
of currency units to be bought or sold, and the server determines the maximum
or minimum rate required in order to obtain or sell this amount, based on the
current market offers available. This avoids the creation of exchange requests
that cannot be filled, and eliminates the need for manually calculating the
required exchange rate.
To prevent clickjacking exploits, a new http header is now added by default to
all http API responses, X-FRAME-OPTIONS: SAMEORIGIN. This can be turned off by
setting nxt.apiFrameOptionsSameOrigin=false in nxt.properties.
Incompatible changes:
The taggedData field in the getAllTaggedData API response has been renamed to
data, for consistency with the other get*TaggedData APIs.
The behaviour of the currencyBuy API has been fixed, to exchange no more than
the number of currency units specified in the units parameter. Currently, the
total amount of NXT as calculated from rate * units is exchanged for currency,
even if this results in purchasing more than the number of units requested,
which is non intuitive and not consistent with the way currencySell works.
This change will take effect after the hard fork.
Updated Jetty to version 9.3.6 and slf4j to version 1.7.13. Make sure to
delete the old lib folder if unpacking over a previous installation.
This release will do a blockchain rescan on testnet and may delete blocks
after certain height, to resolve testnet forks.
--------------------------------------------------------------------------------
nxt-client-1.7.2e:
This is an experimental bugfix release. It is a mandatory update for testnet
nodes.
Accounts under phasing only control are not allowed to create or join
shufflings, or start shufflers.
Shuffling UI improvements. The My Shufflers page has been merged with
My Shufflings.
Added includeParticipantState parameter to getShufflers, to allow retrieving
shuffling participant state too with the same request.
The deleteAccountProperty API has been fixed to accept both recipient and
setter parameters, to be able to delete properties set to the account by
another account.
For consistency with setAccountProperty and deleteAccountProperty, the
getAccountProperties API account parameter has been renamed to recipient.
The account owner is also identified as recipient in the JSON fields of
the properties returned.
Added getAvailableToBuy and getAvailableToSell Monetary System APIs, to allow
calculating the rate required in order to completely fill an exchange request,
or the maximum available currency units or NXT amount considering the current
market offers.
Added Account Properties UI.
Account Control UI improvements and bugfixes.
This release will do a blockchain rescan on testnet only, deleting blocks
after height 484310.
--------------------------------------------------------------------------------
nxt-client-1.7.1e:
This is an experimental bugfix release. It is a mandatory update for testnet
nodes.
Added nxt.useStrongSecureRandom property, default false, to control whether a
strong SecureRandom implementation is used.
Test speed of SecureRandom on startup and refuse to start if slower than 512
bytes per second.
Disallow starting multiple shufflers for the same recipient account on the same
node, even if for different shufflings.
Fixed local signing of shuffling create transactions for holdings.
Added current registrant count to shuffling fields.
Improved handling of failed transactions submitted by shufflers.
Improved My Shufflers, My Shufflings, and Active Shufflings UI.
GetHoldingShufflings should return shufflings of NXT if holding parameter is
not specified or zero.
Blacklist peer versions older than 1.7 on testnet.
This release will do a blockchain rescan on testnet only.
--------------------------------------------------------------------------------
nxt-client-1.7.0e:
This is an experimental release. The new features will be activated at block
483000 on testnet (Nov 30) and 621000 on production (estimated Jan 21, 2016).
All testnet nodes are required to upgrade to this release. Those that don't
will remain on a fork.
Production nodes will need to upgrade to the stable 1.7 version once it is
released (expected before end of December), but in any case before the
hardfork scheduled for block 621000.
New features:
Coin Shuffling. This feature is based on the paper by Tim Ruffing et al,
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .
Coin shuffling can be used to perform mixing of NXT, MS currencies (unless
created as non-shuffleable), or AE assets. Any account can create a new
shuffling, specifying the holding to be shuffled, the shuffle amount, number
of participants required, and registration deadline. This is done using the
shufflingCreate API. The subsequent shuffling steps can be done either
manually, by using the shufflingRegister (for accounts other than the
creator), shufflingProcess, shufflingVerify or shufflingCancel APIs, or, much
more conveniently, by starting an automated Shuffler, using the startShuffler
API. Once started, the Shuffler monitors the blockchain state for transactions
relevant to the specified shuffle, and automatically submits the required
transactions on behalf of the user, performing shuffle processing,
verification, or cancellation as needed. To do this, the Shuffler is required
to keep the user secret phrase in memory, therefore it should be run on a
trusted local machine only. A restart or a crash of the node requires the
shuffler to be started again using the startShuffler API, as it should never
save the user secret phrase on disk.
To participate in a shuffling, a deposit of 1000 NXT is needed, in addition
to the amount of currency or asset being shuffled. Or if shuffling NXT, the
amount of the shuffle must exceed this 1000 NXT minimum. If the shuffling
completes successfully, this amount is added to the recipient account balance,
to allow it to send outgoing transactions (as it is required that only new,
unused accounts are specified as recipients). If the shuffle fails due to
a registered participant failing to participate as required, or intentionally
submitting false data, the participant responsible for the shuffle
cancellation is penalized by retaining this deposit and sending it to the
forgers of the shuffle finish block and the previous three blocks instead.
If a shuffle is cancelled because the required number of participants is not
met, nobody is penalized and all deposits are refunded. On testnet, the deposit
and penalty is 7 NXT only.
After shuffling registration is complete, participants must submit processing
data within a 100 blocks period each (10 blocks on testnet). For the
verification and blame phase, the total allowance for all participants is 100
+ numberOfParticipants blocks (again reduced to 10 + n blocks on testnet).
Full blocks are not counted towards the limit. If at any stage the deadline is
reached without some participant submitting the next required transaction, the
shuffling is cancelled at this participant's fault. It is therefore critical
that after registering for a shuffling, the shuffler started is left running
until its successful completion. If the node must be restarted, all previously
running shufflers must be started again manually.
Query APIs to retrieve currently running shufflers, shufflings, and shuffling
participants are: getAllShufflings, getAccountShufflings,
getAssignedShufflings, getHoldingShufflings, getShufflers, getShuffling, and
getShufflingParticipants.
If desired, finished shufflings can be automatically deleted from the database
if the nxt.deleteFinishedShufflings property is set to true (default is false).
The fee for creating a shuffling or registering in one is 1 NXT, for the
shuffling process or shuffling cancel transactions 10 NXT, and for the verify
transaction 1 NXT.
Account control for phased transactions. Any account can be restricted to only
be allowed to issue phased transactions subject to a specific voting model.
This is achieved by the account submitting a setPhasingOnly transaction using
the setPhasingOnlyControl API. The getPhasingOnlyControl API can be used to
retrieve the status of an account phasing control, and
getAllPhasingOnlyControls to get all accounts subject to phasing control with
their respective restrictions.
Once set, the phasing only account control can only be disabled or changed
with another setPhasingOnly transaction, itself subject to the currently set
phasing restrictions.
Note that by-transaction and by-hash voting models are not allowed for phasing
control, and setting voting model to none is used to disable the control.
To prevent deadlocks due to cyclic account control restrictions, approval
transactions themselves (PhasingVoteCasting) are not subject to phasing only
account control.
When setting phasing account control, a maximum fees total can be specified,
limiting the total fees for currently pending phased transactions of the
controlled account, and limits can be placed on minimum and maximum phasing
duration allowed.
Transactions of accounts subject to phasing account control with restriction
on maximum fees are throttled at one per account per block.
Immediate release of phased transactions on approval. Phased transactions with
a voting model that does not depend on account balance (such as by-transaction
or by-hash), or by-account with no minimum balance and with a whitelist, will
be released before their finish height as soon as approved (in the block in
which the transaction causing their approval is executed), if possible. Such
early finish is guaranteed for transaction types known to be phasing safe. For
others, if the early finish does not succeed due to the transaction failing
validation at this height or conflicting with another transaction in the same
block, a second, final release attempt will be performed at finish height.
New base target adjustment algorithm. Average block times will be 60 s, with
1440 blocks per day. Block times should practically never exceed 10 min.
Limit of 1000 NXT on minimum forging balance. This applies to the total of the
account own guaranteed balance plus any balances leased to it, but not to each
individual balance lease. An account with balance lower than the limit can
still lease its balance to another.
Account properties. Those are name / value pairs that can be set on any
account (except Genesis), by either the account owner, or by another account.
Names are limited to 32 characters, and values to 160 characters. Names are
unique per account and per setter account, but not globally unique. Account
properties cannot be transferred between accounts. The setter of an account
property can edit it by replacing its value with another. Either the setter,
or the recipient (if different) of an account property can delete it. There
is no limit on the number of properties an account can have. Fee for setting
account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee
for every 32 chars after that.
Account properties are managed using the setAccountProperty and
deleteAccountProperty APIs. To query the properties of an account, or those
set by an account, the getAccountProperties API can be used.
Singleton assets. Issuing an asset with a quantity of 1, decimals 0, and
description length not exceeding 160 characters, will require a base minimum
fee of 1 NXT only, instead of the regular 1000 NXT asset issuance fee. For
description of more than 32 chars, an extra 1 NXT fee is added for each 32
chars. Asset name for singleton assets is limited to 10 chars, same as for
regular assets.
Throttling of unique resource allocation transactions. Asset issuance
(excluding singleton assets), monetary system currency issuance, and alias
assignment (excluding re-assignment), will be limited to only one transaction
of each type accepted per block.
Spreading back block fees for asset and currency issuance. The transaction
fees for asset (excluding singleton assets) and currency issuance will be
split between the forgers of the current and the previous three blocks in a
4:3:2:1 ratio.
Prunable plain and prunable encrypted message attachments both allowed in the
same transaction. The maximum data size for each such attachment is 42 kbytes,
but when coexisting in the same transaction the sum of the two is still being
limited by the maximum payload size of 44880 bytes.
Peers that provide http or https API access open to anyone, configured with
nxt.apiServerHost=0.0.0.0 and nxt.allowedBotHosts=* , are now labelled as
providing a service, API or API_SSL, and can be found using the getPeers API
with the corresponding "service" parameter. This API has been modified to
accept multivalued "service" parameter, returning peers that match all
requested services. The ports on which the open API access is running are
included in the peer info of peers providing those services as apiPort and
apiSSLPort fields.
Incompatible changes:
Deletion of asset shares will be performed as a separate AssetDelete
transaction type instead of as sending the shares to Genesis. Sending shares
to Genesis will no longer be allowed. A new API, getAssetDeletes has been
added to retrieve asset deletions, as using the getAssetTransfers API to find
transfers to Genesis account no longer can be used for that purpose. There is
also a new API, getExpectedAssetDeletes, to get asset deletes expected in the
next block, analogous to getExpectedAssetTransfers.
Since both prunable plain and prunable encrypted messages can now be added to
the same transaction, the APIs getAllPrunableMessages, getPrunableMessage, and
getPrunableMessages cannot continue to use just a single "isText" boolean field
in the JSON response to indicate if the prunable message is text or binary.
For all prunable plain messages, a new "messageIsText" boolean field is added,
and for all prunable encrypted messages, a new "encryptedMessageIsText" boolean
field is added in the response of the above APIs, for each message.
For backwards compatibility, the "isText" field will continue to be added, but
only for transactions that have either plain, or encrypted, prunable message
attachment, not for those that have both.
This change does not affect the attachment JSON returned from getTransaction
API, as there are already separate messageIsText and encryptedMessage.isText
fields there.
Fees and size limit changes. Several transaction types or attachments will
have new fees and size limits, to encourage users to utilize the prunable
versions when available, and to make fees proportionate to actual blockchain
space consumed.
Aliases:
Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus URI
total length, after the first 32 chars. Name and URI size limits remain at
100 and 1000 chars respectively.
Messages and EncryptedMessages (non-prunable):
Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the
first 32 bytes. For encrypted messages, the length is measured excluding the
nonce and the 16 byte AES initialization vector, and to account for those
there is an extra fee of 1 NXT.
Fees and size limit for prunable messages remain unchanged.
AccountInfo:
Base fee 1 NXT, with 2 NXT additional fee for each 32 chars of name plus
description total length, after the first 32 chars. Name and description size
limits remain at 100 and 1000 chars. AccountInfo transactions throttled at
one per block.
Polls:
Base fee 10 NXT for polls with up to 20 options, and total size of poll name
plus poll description plus total option length not exceeding 320 chars. For
each option above 20, an additional fee of 1 NXT, and for each 32 chars after
320, an additional fee of 2 NXT. Poll creation throttled to one per block.
Name, description, and option length limits remain at 100, 1000, and 100 chars
respectively.
DGS Listing:
Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus
description total length, after the first 32 chars. Name and description size
limits remain at 100 and 1000 max. DGS Listing throttled at one per block.
DGS Delivery:
Base fee 1 NXT, with 2 NXT additional fee for each 32 bytes of encrypted goods
data after the first 32 bytes, nonce and AES initialization bytes excluded.
Encrypted goods data size limit remains 1000 bytes.
Phasing:
In addition to the current fee for phasing (1 NXT for balance independent,
20 NXT otherwise), 1 NXT will be added for each 32 bytes of hashedSecret or
linkedFullHash fields.
Referenced transactions:
An extra fee of 1 NXT for the 32 byte referencedTransactionFullHash if set,
i.e. if the transaction is using the referenced transactions feature.
To facilitate migration of legacy client code to the new fees, if the property
nxt.correctInvalidFees=true has been set in nxt.properties (default is false),
the server will automatically replace insufficient fees for submitted unsigned
transactions with the minimum fee needed, depending on the transaction, as if