I can't speak to if NXT as a whole is a scam currency, but my personal experience was that it took basically two days to confirm a transaction. And when I went to make a small transaction to test something out it said my password was wrong.

What happened to TF, any ETA on its implementation? Its surprising that after all this time there is still no TF when it was one of the features promised on launch.

TF is just an ability to "predict" the future. All the other is bells and whistles.

NXT is being dead as the fully centralized core developer(only one),the UNtransparent price manipulation ,shit scam assets and without any real use but just for dump

ALERT WITH THIS "SCAM" COIN.

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/

Coin Shuffling
This feature is based on the paper by Tim Ruffing et al, http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .

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

In the spirit of keeping the community informed about what is coming in 1.7, here is the changelog, as it is now. All features described are already implemented, this is not a roadmap, this is completed work (for the server part at least, we are still waiting for the UI to be finished and polished).


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 forger of the shuffle finish block instead. If a shuffle is cancelled because the required number of participants is not met, nobody is penalized and all deposits are refunded.

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.


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.


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.


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.

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 1 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.

Over 110 retweets now. Any results so far? Let me know so that I can see if this is efficient.

...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].

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

I've  been waiting for this feature for a long time. I thought it was originally going in 1.4

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.

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

Guys, you know we have a lot of hot discussions on AT Project then Smart Contracts proposal from cfb. I wasn't a fan of AT project(I wasn't strictly against that as well though). And I was strictly against Smart Contracts, I really don't like the idea of projecting core implementation details into the blockchain.

Having a job during last days to investigate current state of Ethereum, I would like to say it's good Nxt has delayed AT project adoption. It's not a scalable approach, it has a lot unexpected properties and so on.

Quick example, its possible to write some random crap into blockchain as contract code, e.g. https://etherscan.io/tx/0x4bb32548d3b28d8bbdbe969888dff6285a0404bb314b7a8e5d81a61a313781eb (contract https://etherscan.io/address/0x190cf16a720f69d1b1ac68e873d9c5b06c1f0f2b). It starts with invalid instruction 2f then some meaningless stuff. Fee is minimal as code execution aborts immediately. Trying to submit something about 60kb after this 1kb tx, I've got my geth stuck and broken 

And please note this is not a bug, even more, this is the best behaviour probably(and with arbitraty-input JMP instruction it's not possible to analyze code execution correctness at all, probably).

And scalability would be a problem for Eth. Considering the same logic, e.g. polling to get done against Nxt & Eth, in the former case it's code running
on top of JVM while in latter it's about code running on top of EVM which is running on top of JVM/pyVM/LLVM.

Some researchers around are working on solving general problems of Ethereum-like contracts, namely scalability and privacy. I made the blogpost comparing two known proposals, Hawk and Enigma http://chepurnoy.org/blog/2015/10/towards-a-new-frontier-of-the-smart-contracts-hawk-and-enigma/ .

In both cases contract execution is happening off-chain, and blockchain is being used to store commitments / MACs or CRSes(common reference string for non-interactive Zero Knowledge Proof with size of tens kilobytes).

Surprisingly(or not), Nxt is already well ready for storing that complementary data. The only thing we need is to promote Nxt chain for being used for things like that(so to use Nxt  in both systems). Thoughts?

Price immediately plummets 20%.