Nxt testrelease 1.7.0e has been released
Test release Nxt 1.7.0e has been released with great new features. Check it out!
http://nxter.org/nxt-testrelease-1-7-0e-has-been-released/
Topic: [NXT] Development Discussion - The dev plan that keeps on delivering (Read 22179 times)
November 30, 2015, 03:32:36 PM
November 24, 2015, 06:36:21 PM
I'm currently sending the following message out to all exchanges to help them with the upgrade path from 1.5.15 to 1.6.2 to 1.7.
There's useful information here for everyone, especially if you run an NXT-based project.
Spread the word.....
*************************************************************************************************
Mandatory upgrade to NRS 1.7 before 21 Jan 2016
The next planned Nxt release, 1.7, will be a mandatory upgrade for everyone, as it will be a hard fork.
The first 1.7 version will be released at the end of this month (November 2015) as an experimental release,
a stable mainnet 1.7 version will be released at the end of the year,
and the 1.7 hardfork will be set to occur in mid January 2016.
Any systems still running on versions older than 1.7 will be adversely affected.
We recommend that any systems still running now on the last version (1.5.15) be upgraded as soon as possible to the newest stable release: 1.6.2.
This will make the transition to the 1.7 branch much simpler.
(Note: this does not apply to MGW node operators, liase with the MGW team for the latest information)
An upgrade from 1.5.15 to 1.7 is NOT recommended, and we will be unable to provide effective support for that upgrade path.
While the stable 1.7 version has not been released yet, it is
imperative for Nxt-based projects that preparations for migration to 1.7 begin now, as for any
API client this will involve a number of code changes. The current stable release is 1.6.2,
and all API changes required for 1.7 are already fully supported in 1.6.2.
Upgrading to 1.6.2 now will ensure a smooth transition to 1.7 when it is released, as there should be no API
incompatibilities between 1.6.2 and 1.7 stable.
Below is a high level review of the code modifications required.
A detailed list of all affected APIs is posted at:
https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199198/#msg199198 , and
the changes are also discussed in the 1.6.0e, 1.6.1e, and 1.6.2
changelogs, available as usual in the changelogs directory of the 1.6.2
release package. Please do read the information in these changelogs.
https://nxtforum.org/nrs-releases/nrs-v1-6-2/
https://nxtforum.org/nrs-releases/nrs-v1-6-1e/
https://nxtforum.org/nrs-releases/nrs-v1-6-0e/
1. A number of API calls, which in 1.5.15 and previous releases return
additional information, at a performance cost, have had their defaults
modified not to return those extra fields unless specifically
requested. The format of the API response has not changed, only what
fields are returned by default. If your code uses any of those APIs and
in some invocations needs the additional fields, make sure to add the
corresponding "include" parameters in those places.
2. The getAccountTransactions and getAccountTransactionIDs APIs,
deprecated in 1.5 have been removed in 1.6. Use
getBlockchainTransactions instead and make sure to handle correctly the
phased transactions. Some enhancements to getBlockchainTransactions,
such as being able to get only executed phased (or not phased)
transactions, introduced in 1.6.1e, should make that easier.
3. Some APIs no longer do a detailed error checking of the user input.
Any APIs that accept an object id such as account, asset, or currency,
but do not need to retrieve the actual object, no longer check for its
existence. Such APIs will now return an empty result list instead of an
error, when supplied for example with non-existent asset id.
4. Asset transfers to the Genesis account are now treated as deletion
of asset shares, and as such are not retrievable using the
getAssetTransfers API. The quantityQNT in the asset JSON returned by
APIs such as getAsset now corrects for such share deletion. The
original asset quantity issued is returned as initialQuantityQNT in the
asset JSON.
The above API incompatibilities must be taken care of on upgrade from
1.5.15 to 1.6.2. The 1.7 API will be consistent with 1.6.2 and will
require no further adjustments.
Other than the API tweaks, there are two major changes to take effect
in the 1.7 hardfork, that require taking action now and preparing in
advance:
1. For virtually all transaction types in 1.7, fees charged will no
longer be constant (currently 1 NXT), but based on the actual
transaction size. As it is not possible to hardcode the logic for fee
calculation in each client of the API, the approach suggested is to let
the server determine and use the minimum fee required, which happens
when a new transaction is submitted with feeNQT=0 parameter. This
feature is fully supported in 1.6.2, and therefore a migration to using
server-side calculated fees can be started now.
2. The maximum allowed size of permanent message attachments (plain or
encrypted) has been significantly reduced, from 1000 bytes to 160
bytes. If you use permanent messages, regardless of the transaction
type they are attached to, you need to make sure their size does not
exceed 160 bytes. As fees for permanent messages have also been
increased significantly and are proportional to the actual message
size, it is strongly recommended to switch to using prunable messages
instead. To create a message as prunable, the only change required is
to add messageIsPrunable=true parameter to the corresponding
transaction creation API call. The format of the transaction JSON is
the same for permanent and prunable messages (this is why they can't
both coexist in the same transaction), therefore no changes in parsing
the JSON response are needed. Prunable messages are also deleted by
default after 90 days. If your application needs to have them available
longer, or indefinitely, this can be configured in the nxt.properties
file, and it is also possible to automatically retrieve such expired
prunable messages from archival nodes running on the Nxt network.
Prunable messages have been supported since 1.5, and archival nodes are
introduced in 1.6.2, so again the migration from permanent to prunable
messages can be started now, without waiting for the 1.7 stable release.
Please see this forum thread for information and discussions regarding
the transition to prunable messages and the fee calculation changes:
https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
We have also set up a mailing list, to allow better direct communication with the Nxt dev team, so if you
are responsible for an Nxt-based project, sign up here:
http://nxt.org/cgi-bin/mailman/listinfo/nrs-development
**********************************************************************************************
There's useful information here for everyone, especially if you run an NXT-based project.
Spread the word.....
*************************************************************************************************
Mandatory upgrade to NRS 1.7 before 21 Jan 2016
The next planned Nxt release, 1.7, will be a mandatory upgrade for everyone, as it will be a hard fork.
The first 1.7 version will be released at the end of this month (November 2015) as an experimental release,
a stable mainnet 1.7 version will be released at the end of the year,
and the 1.7 hardfork will be set to occur in mid January 2016.
Any systems still running on versions older than 1.7 will be adversely affected.
We recommend that any systems still running now on the last version (1.5.15) be upgraded as soon as possible to the newest stable release: 1.6.2.
This will make the transition to the 1.7 branch much simpler.
(Note: this does not apply to MGW node operators, liase with the MGW team for the latest information)
An upgrade from 1.5.15 to 1.7 is NOT recommended, and we will be unable to provide effective support for that upgrade path.
While the stable 1.7 version has not been released yet, it is
imperative for Nxt-based projects that preparations for migration to 1.7 begin now, as for any
API client this will involve a number of code changes. The current stable release is 1.6.2,
and all API changes required for 1.7 are already fully supported in 1.6.2.
Upgrading to 1.6.2 now will ensure a smooth transition to 1.7 when it is released, as there should be no API
incompatibilities between 1.6.2 and 1.7 stable.
Below is a high level review of the code modifications required.
A detailed list of all affected APIs is posted at:
https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199198/#msg199198 , and
the changes are also discussed in the 1.6.0e, 1.6.1e, and 1.6.2
changelogs, available as usual in the changelogs directory of the 1.6.2
release package. Please do read the information in these changelogs.
https://nxtforum.org/nrs-releases/nrs-v1-6-2/
https://nxtforum.org/nrs-releases/nrs-v1-6-1e/
https://nxtforum.org/nrs-releases/nrs-v1-6-0e/
1. A number of API calls, which in 1.5.15 and previous releases return
additional information, at a performance cost, have had their defaults
modified not to return those extra fields unless specifically
requested. The format of the API response has not changed, only what
fields are returned by default. If your code uses any of those APIs and
in some invocations needs the additional fields, make sure to add the
corresponding "include" parameters in those places.
2. The getAccountTransactions and getAccountTransactionIDs APIs,
deprecated in 1.5 have been removed in 1.6. Use
getBlockchainTransactions instead and make sure to handle correctly the
phased transactions. Some enhancements to getBlockchainTransactions,
such as being able to get only executed phased (or not phased)
transactions, introduced in 1.6.1e, should make that easier.
3. Some APIs no longer do a detailed error checking of the user input.
Any APIs that accept an object id such as account, asset, or currency,
but do not need to retrieve the actual object, no longer check for its
existence. Such APIs will now return an empty result list instead of an
error, when supplied for example with non-existent asset id.
4. Asset transfers to the Genesis account are now treated as deletion
of asset shares, and as such are not retrievable using the
getAssetTransfers API. The quantityQNT in the asset JSON returned by
APIs such as getAsset now corrects for such share deletion. The
original asset quantity issued is returned as initialQuantityQNT in the
asset JSON.
The above API incompatibilities must be taken care of on upgrade from
1.5.15 to 1.6.2. The 1.7 API will be consistent with 1.6.2 and will
require no further adjustments.
Other than the API tweaks, there are two major changes to take effect
in the 1.7 hardfork, that require taking action now and preparing in
advance:
1. For virtually all transaction types in 1.7, fees charged will no
longer be constant (currently 1 NXT), but based on the actual
transaction size. As it is not possible to hardcode the logic for fee
calculation in each client of the API, the approach suggested is to let
the server determine and use the minimum fee required, which happens
when a new transaction is submitted with feeNQT=0 parameter. This
feature is fully supported in 1.6.2, and therefore a migration to using
server-side calculated fees can be started now.
2. The maximum allowed size of permanent message attachments (plain or
encrypted) has been significantly reduced, from 1000 bytes to 160
bytes. If you use permanent messages, regardless of the transaction
type they are attached to, you need to make sure their size does not
exceed 160 bytes. As fees for permanent messages have also been
increased significantly and are proportional to the actual message
size, it is strongly recommended to switch to using prunable messages
instead. To create a message as prunable, the only change required is
to add messageIsPrunable=true parameter to the corresponding
transaction creation API call. The format of the transaction JSON is
the same for permanent and prunable messages (this is why they can't
both coexist in the same transaction), therefore no changes in parsing
the JSON response are needed. Prunable messages are also deleted by
default after 90 days. If your application needs to have them available
longer, or indefinitely, this can be configured in the nxt.properties
file, and it is also possible to automatically retrieve such expired
prunable messages from archival nodes running on the Nxt network.
Prunable messages have been supported since 1.5, and archival nodes are
introduced in 1.6.2, so again the migration from permanent to prunable
messages can be started now, without waiting for the 1.7 stable release.
Please see this forum thread for information and discussions regarding
the transition to prunable messages and the fee calculation changes:
https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
We have also set up a mailing list, to allow better direct communication with the Nxt dev team, so if you
are responsible for an Nxt-based project, sign up here:
http://nxt.org/cgi-bin/mailman/listinfo/nrs-development
**********************************************************************************************
November 24, 2015, 12:03:00 AM
great job on the release timeline. cant wait to see it in action.
November 17, 2015, 09:30:18 PM
I will just leave this here to make it clear to any developers reading this:
1. There will be changes in fees and permanent message size limit in 1.7. They will take effect in the 1.7 hard fork, in very early January 2016.
2. These changes will break any application that has hardcoded fees of 1 NXT, or uses permanent messages exceeding 160 bytes.
3. *snip* ALL API USERS CAN, AND ABSOLUTELY MUST START UPDATING THEIR CODE NOW. DO NOT WAIT UNTIL 1.7 STABLE IS RELEASED *snip* START UPDATING TO 1.6.2, USE SERVER-SIDE FEE CALCULATION, AND EITHER SWITCH TO PRUNABLE MESSAGES, OR MAKE SURE PERMANENT MESSAGE SIZE DOES NOT EXCEED 160 BYTES.
4. To repeat. Do not wait until 1.7.1 stable *snip* THIS IS THE ADVANCE NOTICE.
Technical questions about the transition should be discussed here: https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
2. These changes will break any application that has hardcoded fees of 1 NXT, or uses permanent messages exceeding 160 bytes.
3. *snip* ALL API USERS CAN, AND ABSOLUTELY MUST START UPDATING THEIR CODE NOW. DO NOT WAIT UNTIL 1.7 STABLE IS RELEASED *snip* START UPDATING TO 1.6.2, USE SERVER-SIDE FEE CALCULATION, AND EITHER SWITCH TO PRUNABLE MESSAGES, OR MAKE SURE PERMANENT MESSAGE SIZE DOES NOT EXCEED 160 BYTES.
4. To repeat. Do not wait until 1.7.1 stable *snip* THIS IS THE ADVANCE NOTICE.
Technical questions about the transition should be discussed here: https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
November 17, 2015, 09:24:09 PM
Coin Shuffling
This feature is based on the paper by Tim Ruffing et al, http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .
This feature is based on the paper by Tim Ruffing et al, http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .
Following on from ^^^this^^^^, Nxt's implementation of coin shuffling has been reviewed by the creator of coinshuffling... Tim Ruffing !
https://nxtforum.org/core-development-discussion/coin-shuffling-code-review-by-tim-ruffing/
Here is the tl:dr version:
And a confirmation by Tim that all issues have been addressed:
No problem. Just to confirm: All your answers look reasonable and make sense to me
No problem. Just to confirm: All your answers look reasonable and make sense to me
Green light
November 17, 2015, 09:18:21 PM
Devlelopers building on top of Nxt should pay attention to these threads, there are some important changes in Nxt to be aware of:
https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
https://nxtforum.org/core-development-discussion/new-fees-and-size-limits-in-1-7/
Ordinary users, you won't notice the changes so don't worry
https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/
https://nxtforum.org/core-development-discussion/new-fees-and-size-limits-in-1-7/
Ordinary users, you won't notice the changes so don't worry
November 17, 2015, 09:16:13 PM
November 17, 2015, 09:11:44 PM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
The website is 99.9% by QBTC
The tweet got over 70 retweets, gotta spread the word about nxt tree and upcoming features.
I advertised my tweet, lets see how efficient will be
Nice one
Over 110 retweets now. Any results so far? Let me know so that I can see if this is efficient.
Unfortunately, the 0.1% involvement I have with the website means I don't have this find of visibility. Maybe QBTC with drop by with some stats.
November 16, 2015, 07:50:24 AM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
The website is 99.9% by QBTC
The tweet got over 70 retweets, gotta spread the word about nxt tree and upcoming features.
I advertised my tweet, lets see how efficient will be
Nice one
Over 110 retweets now. Any results so far? Let me know so that I can see if this is efficient.
November 13, 2015, 10:29:19 AM
I found this from CfB too, which might help in the discussion to avoid confusion...
[this bit is my addition]
...I see that people confuse Account Control and Phasing. The rule is quite simple: if it's only u who control ur account then it's AC, if other people required for control then it's Phasing [Phased Transactions].
[this bit is my addition]
November 13, 2015, 10:27:50 AM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
The website is 99.9% by QBTC
The tweet got over 70 retweets, gotta spread the word about nxt tree and upcoming features.
I advertised my tweet, lets see how efficient will be
Nice one
November 13, 2015, 10:24:21 AM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
The website is 99.9% by QBTC
The tweet got over 70 retweets, gotta spread the word about nxt tree and upcoming features.
I advertised my tweet, lets see how efficient will be
November 13, 2015, 10:18:12 AM
I think, full Account Control is most important feature in 1.7.
I've been waiting for this feature for a long time. I thought it was originally going in 1.4
Well it shouldn't be too log to wait now
It will be a big step forward, these are the planned features from Aug 2014.. (as Account Control is being implemented in 3 phases, one already complete, then some of these are live now)1. Disable non-SmartContract transactions
Removes ability to initiate manual transactions. After they are disabled only virtual transactions initiated by smart contracts (hosted on this account) will be processed. This subfeature is necessary to unlock extra potential of Smart Contracts and should be done before I complete Smart Contracts.
Manual transactions can be enabled again only if a smart contract does it. A possible application is funding an account for a kid who will get access to this account only after some conditions r met (like becoming 18 y.o.)
2. Send money/assets only to predefined accounts
Defines a list of acconts that can be recipients of transactions initiated by the account. Besides extra protection some other schemes can use this subfeature, for example, an escrow service that can send money only to Alice or Bob, but not to himself.
3. Enable/Disable "Instant Transactions" mode
Enables/disables "instant" transactions mode described by BCNext here - https://bitcointa.lk/threads/nxt-instant-transactions-with-guaranteed-confirmation.179540/
Pay attention, that it doesn't automatically create IT feature. Mczarnek is working on another IT approach proposed by anon136, but I think that we need legacy IT mode just in case.
4. Allow/Disallow only some outgoing/incoming transaction types
Allows/disallows different transaction types. Besides extra security it's handy to prevent anyone from sending trash assets to ur account.
5. 2FA with hash chains
This brings 2-factor authorization into Nxt. Actually it's possible to have N-factor auth, it's similar to Multisig of Bitcoin, but requires to send two transactions instead of one. This also adds protection against quantum computers.
6. Transfer of everything to another account (at will, dead man's switch, incoming transaction)
Can be used to transfer everything from one account to another. It can also be used to "merge" multiple accounts into one.
7. Setting spending limits
As title says. Can be used for stronger security and also to limit amounts ur wife/kid spends.
Removes ability to initiate manual transactions. After they are disabled only virtual transactions initiated by smart contracts (hosted on this account) will be processed. This subfeature is necessary to unlock extra potential of Smart Contracts and should be done before I complete Smart Contracts.
Manual transactions can be enabled again only if a smart contract does it. A possible application is funding an account for a kid who will get access to this account only after some conditions r met (like becoming 18 y.o.)
2. Send money/assets only to predefined accounts
Defines a list of acconts that can be recipients of transactions initiated by the account. Besides extra protection some other schemes can use this subfeature, for example, an escrow service that can send money only to Alice or Bob, but not to himself.
3. Enable/Disable "Instant Transactions" mode
Enables/disables "instant" transactions mode described by BCNext here - https://bitcointa.lk/threads/nxt-instant-transactions-with-guaranteed-confirmation.179540/
Pay attention, that it doesn't automatically create IT feature. Mczarnek is working on another IT approach proposed by anon136, but I think that we need legacy IT mode just in case.
4. Allow/Disallow only some outgoing/incoming transaction types
Allows/disallows different transaction types. Besides extra security it's handy to prevent anyone from sending trash assets to ur account.
5. 2FA with hash chains
This brings 2-factor authorization into Nxt. Actually it's possible to have N-factor auth, it's similar to Multisig of Bitcoin, but requires to send two transactions instead of one. This also adds protection against quantum computers.
6. Transfer of everything to another account (at will, dead man's switch, incoming transaction)
Can be used to transfer everything from one account to another. It can also be used to "merge" multiple accounts into one.
7. Setting spending limits
As title says. Can be used for stronger security and also to limit amounts ur wife/kid spends.
Remember, this is only a guide. Features have been switched around and new ones added that weren't (like the cold storage integration). But I think the devs have proved in the last two years that they have the expertise to deliver what they say they will.
November 11, 2015, 07:49:09 AM
I think, full Account Control is most important feature in 1.7.
I've been waiting for this feature for a long time. I thought it was originally going in 1.4
November 09, 2015, 12:00:37 PM
I think, full Account Control is most important feature in 1.7.
November 09, 2015, 11:09:47 AM
Added to OP:
Video Walkthrough link added for Nxt Marketplace core feature
Links to Transparent Forging nxtforum.org discussion threads and "Advantages of Transparent Forging" thread by Come-from-Beyond added
Video Walkthrough link added for Nxt Marketplace core feature
Links to Transparent Forging nxtforum.org discussion threads and "Advantages of Transparent Forging" thread by Come-from-Beyond added
November 09, 2015, 11:06:23 AM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
The website is 99.9% by QBTC
October 30, 2015, 08:01:39 PM
Very good website, it really sums up NXT's roadmap perfectly, and the design makes it user friendly.
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
I had to tweet it:
https://twitter.com/RealBitcoinBlog/status/660243941091078144
October 30, 2015, 12:27:24 PM
Added summary of versions 1.1, 1.2 and 1.3 to OP. Plus links to Nxt APIs and full release notes for all versions.
Also added documentation links for Monetary System and Minting (Mining of Monetary System coins).
Also added documentation links for Monetary System and Minting (Mining of Monetary System coins).
October 30, 2015, 09:19:08 AM
OP updated with more detailed info and made clearer.
Video walkthroughs, video discussions and teasers added for all core features listed in OP. More release history and links will be added in time. Props go to MrCluster87 and Tai Zen.
Post if the you have any problems with the links.
Video walkthroughs, video discussions and teasers added for all core features listed in OP. More release history and links will be added in time. Props go to MrCluster87 and Tai Zen.
Post if the you have any problems with the links.
Jump to: