I think it was missed on this thread but there is a Development Roadmap published by Jean-Luc on nxtforum.org >>>
https://nxtforum.org/news-and-announcements/development-roadmap/In short,
many features are written and are being integrated into the main code as we speak ready for testing (there is also a github somewhere to prove it). If we want stuff quicker then
we need to find more Java developers to spread the work around
5* for Jl, Come-from-Beyond and the rest for the work so far.
****
Development roadmap
April 09, 2014, 02:01:43 pm
--------------------------------------------------------------------------------
I am now working on integrating into the develop branch the changes from
feature/tf branch that CfB was working on. Those include Digital Goods Store,
Effective Balance Leasing, Transparent Forging changes (getNextBlockGenerators),
Phased transactions (not sure if this got completed). They will be enabled only
on test net initially, but I need to merge the code, convert all amount handling
logic to NQT, do some review and refactoring, fix obvious bugs if any.
I also need to integrate the canonical signatures and AES encrypt patches from
Dr Evil, and switch the encryption in DGS to use AES.
In the meantime, Wesley and other client devs should make the transition to NQT
so that their clients work with the 0.9 branch.
The remaining issue in AE:
https://bitbucket.org/JeanLucPicard/nxt/issue/79/buy-order-and-sell-order-matching-does-notneeds to be resolved, and this is a good warm-up task for a new developer, while
I am busy with the above work.
After bugs in fractional NXT transactions are found and fixed, we need to try on
test net the NQT_BLOCK transition without a blockchain reset. This means, first
we do another reset by setting NQT_BLOCK in the future, so that blocks with
fractional transactions on test net get deleted and again everything is only in
whole NXT. Until NQT_BLOCK, 0.9 nodes internally use NQT, but transactions are
still signed in the old format, with integer amounts. When NQT_BLOCK is reached,
transactions after that block will be signed and verified in the new format
(amounts as longs). Around the time of the transition, transactions that were
created before NQT_BLOCK but didn't get a chance to be included in the last
non-NQT block, will end up eventually being rejected. Similarly, if a fork
reached NQT_BLOCK height sooner, and its nodes started signing transactions in
the new format sooner than the real chain, those new transactions may either get
rejected, or popped off and included in new blocks after NQT, depending on their
timestamp and deadline. So overall this is a tricky transition and we need to
rehearse it first on testnet.
Only after such test is successful, and we have switched to NQT on main net, with
all clients supporting NQT and AE, we can consider launching AE.
I need to work on moving all derived objects - Accounts, Assets, etc, to the
database. I will start on that immediately after finishing the merge of the
feature/tf branch. The launch of AE does not strictly need to wait for this to
be completed, but while everything is still kept in memory we don't have a
scalable system and if AE is unexpectedly successful we will not be prepared
to handle the sudden increase in assets, orders, trades and so on. Moving those
to the database will in turn create different performance issues that need to be
found and fixed.
There are several projects that can be taken by new developers in parallel with
the above:
The Voting System needs to be tested and put in production, and will need an API
to get some statistics about voting with various restrictions - such as, only
count NXT that did not move in the last n blocks, or that did not move after the
poll was created, or do not count accounts that were created after the poll, and
so on. Having a working Voting System is important so we can agree on changes to
the minimum fee and asset issuance fee.
Alias transfer, or maybe trading, or expiration, need to be implemented. This is
again a standalone area and I don't have the time to focus on it soon.
The performance of getNextBlockGenerators, needed for TF, has to be significantly
improved. I have some ideas about it, and will see what I can do while integrating
the feature/tf branch, but finishing it may be left for a new developer. Related
to that, the implementation of UDP server and accepting transactions over UDP for
faster and DDOS-resistant processing, is again a completely standalone project
that somebody needs to take.
Features like parallel chains, blockchain shrinkage, persisting or not of some
transactions during shrinkage, will be looked at after the above work is done.
------------------------------------------
N.B.
****
NQT See nxtQuant.
nxtQuant This is the name given to 0.00000001 NXT (or 10^-8 in mathematical shorthand) in the Nxt code and abbreviated to NQT. nxtQuants are equivalent to satoshis in Bitcoin and allows NXTs to be highly divisible, making them tradable with coins that have values many decimal places higher or lower than Nxt. nxtQuant is currently a temporary name.
****
Source: The
Nxt Glossary >>>
https://wiki.nxtcrypto.org/wiki/Glossary
Show Posts
?). Am almost sure that Fact Digitization - a feature vital for advanced DACs - will be the 3rd feature "borrowed" by others.
I never used the NRS on a 'public' computer and downloaded it from the link in this thread. I would love to tell you the original password, but i use it to encrypt my BTC wallet too. It's a similar random combination just like 1Nm4azDöl68gRpqy29gEüXXnjk@b_)38dzkb?q
)
