Log de Cambios del Software de Nxt

From Nxt Wiki
Jump to: navigation, search
This page is a translated version of the page Nxt Software Change Log and the translation is 25% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎русский • ‎українська

Contents

1 Version 1.5.11

June 8th, 2015

  • This release removes compatibility with peers older than version 1.5, and no longer accepts connections from them.
  • Conditional logic dependent on block 445000 has been removed where no longer necessary, as block 445000 has been passed now.
  • Parallel blockchain download using 36-block segments is now the default regardless of height. Returning more than 36 blocks at a time by getNextBlocks is no longer supported.
  • The maximum WebSockets message size and the maximum allowed response size to a getNextBlocks request have been reduced from 192 MB to 10 MB.
  • A checksum at block 445000 has been added.
  • Added isDownload field to the getBlockchainStatus and getState API response, indicating if blockchain download is in progress. This gets set to true when a batch of more than 10 blocks at once has been downloaded from a peer, and gets reset to false when an attempt to download more blocks from a peer does not result in any new blocks added.
  • The peer requests getUnconfirmedTransactions, getMilestoneBlockIds, getNextBlockIds, getNextBlocks, processBlock, processTransactions, getCumulativeDifficulty, are being rejected while a blockchain download is in progress, as indicated by the above isDownloading property.
  • The timestamp of the last connect attempt to a peer is now included in the peer JSON object.
  • Added a connect parameter to DumpPeers debug API, to force a connection attempt to each known peer first, adminPassword required if needed.
  • The run.bat script on Windows no longer uses the -server flag by default.
  • Updating nodes of version older than 1.5 to this release will delete blocks after height 445000, to make sure such nodes are not left permanently stranded on the 1.4 fork.

2 Version 1.5.10

June 4th, 2015

  • Create installer package for Windows and Linux using the IzPack installer. See https://bitbucket.org/JeanLucPicard/nxt/issue/283
  • Added separate linux and windows (cygwin) build and release scripts.
  • Track and log database query execution times. The new properties: nxt.statementLogThreshold, nxt.transactionLogThreshold, and nxt.transactionLogInterval can be used to configure logging of slow queries.
  • Database performance improvements and optimizations. The account leasing data has been moved from the account table to a separate account_lease table. More table indexes have been added or existing ones modified.
  • Improved JSON encoding performance.
  • Outbound websockets connections are no longer initiated when using a socks or http proxy (if system property socksProxyHost or http.proxyHost is defined).
  • Include expired prunable JSON in API transaction JSON, if available.
  • To protect public nodes from unneeded extra load, the getState API does not include counts even if includeCounts=true, unless the adminPassword is either provided as a parameter, or is not needed.
  • Added numberOfAccountLeases and numberOfActiveAccountLeases to getState, showing the total number of scheduled (first lease only) or currently active account balance leases.
  • Limit peer details length to 10 characters for version, 20 for application, 30 for platform, and 100 for announced address.
  • Client UI improvements:
    • Fixed a bug sometimes not showing notification badge after login.
    • Improved Bulgarian and Slovak translations.
    • Fix local signing of upload tagged data and approve transaction.
  • This release will perform a full blockchain rescan on first start.
  • Updated jetty to version 9.2.11. If unpacking on top of existing installation, delete the old lib folder first.

3 Version 1.5.9

May 27th, 2015

  • Enable Voting System, Phasing, and related new features at block 445000.
  • This is a hard fork, upgrade to 1.5.9 or later is mandatory for everyone.
  • If upgrading from 1.4.x, read the 1.5.0e and later changelogs for the important changes and new features introduced in the 1.5 series.
  • Peer networking improvements. Peers unreachable for more than 7 days and not listed under nxt.wellKnownPeers or nxt.defaultPeers are removed from the peers database.
  • Updated some translation files, added Bulgarian and Catalan translations.
  • Other minor bugfixes and improvements.

Important licensing change:

  • The Nxt core software is now distributed under the GNU General Public License version 2, with the exception of the client UI code which remains under the MIT license. Please read the files LICENSE.txt, COPYING.txt and DEVELOPER-AGREEMENT.txt for more information.

4 Version 1.5.8e

May 15th, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Set the content type to "text/plain; charset=UTF-8" when sending http requests to peers. This is an important bug fix, as the incorrect encoding of outgoing blocks and transactions containing some Unicode characters can prevent their propagation and lead to forks. Everyone running the experimental release should update.

5 Version 1.5.7e

May 15th, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Added WebSockets support in the peer to peer networking. When connecting to peers that do not support WebSockets, HTTP is still used. WebSockets can be disabled by setting nxt.useWebSockets to false (default is enabled).
  • Implemented parallel blockchain download. After Constants.PHASING_BLOCK (not yet set on main net), blocks and transactions data will be requested from multiple peers in parallel, in batches of 36 blocks (when more than 36 blocks need to be downloaded), instead of downloading up to 720 blocks from the single blockchain feeder peer. This is expected to reduce the time for full blockchain download, once most nodes upgrade to support the parallel download protocol.
  • Added file upload using multipart form requests to the UploadTaggedData, ExtendTaggedData and VerifyTaggedData APIs. Added upload file button to the corresponding forms on the /test page.
  • Added DownloadTaggedData API, to download tagged data as a file.
  • Added optional includeData boolean parameter to all GetTaggedData APIs, default true, to allow omitting the actual data from the result for saving bandwith, since it can now be retrieved separately using the DownloadTaggedData API.
  • Improved search by tags. Improved validation of tagged data.
  • Added includeEffectiveBalance to getAccount and getBalance API, default true. If false, effective balance and guaranteed balance are not included in the response, which should improve performance for these APIs.
  • Added HexConvert utility API.
  • Improved GetConstants JSON to include an alternative transaction type JSON representation.
  • Peers in the nxt.wellKnownPeers list are always kept connected, regardless of the number of connected public peers or the total number of know peers.
  • Added GetInboundPeers API, to return all peers that have sent a request to this peer in the last 30 min.
  • Added inbound, inboundWebSocket, and outboundWebSocket boolean fields to the Peer JSON returned by the getPeer and getPeers APIs, to show the inbound status of each peer and whether it has established an inbound or outbound websocket connections to this node.
  • Limit the total number of inbound or outbound connections, using the properties nxt.maxNumberOfInboundConnections and nxt.maxNumberOfOutboundConnections, defaults 250 and 50 respectively. The nxt.maxNumberOfConnectedPublicPeers value cannot exceed the nxt.maxNumberOfOutboundConnections value (if it does, it is set to nxt.maxNumberOfOutboundConnections).
  • The getAccountTransactions and getAccountTransactionIds APIs have been restricted to always return only the non-phased transactions. Those APIs have also been deprecated and will be removed in 1.6. The getBlockchainTransactions API should be used instead, which has the same behavior but returns both phased and non-phased transactions (by default, unless either phasedOnly or nonPhasedOnly parameters is specified). Do not simply replace getAccountTransactions with getBlockchainTransactions in your client code without an understanding of how phased transactions work and without being prepared to handle them correctly.
  • Added links to the Wiki documentation for each API request from the /test page. The links are autogenerated and thus work only for the wiki sections following the same hash tag pattern, but most of them currently do.
  • The JavaScript NRS.sendRequest() function no longer accepts a callback function as its second parameter. Instead, when sending a request with no data, specify the value {} as the second parameter and the callback function as the third parameter.

Client UI improvements:

  • Implemented client side signing of the tagged data transactions.
  • Added File Upload form, accessible from the settings menu. Allow extending a tagged data transaction from the transaction info modal.
  • Integration of current status of client translations for new 1.5 features, new "experimental" state for languages with translation status at 40-50%+, added Czech, Greek, Hindi translations in experimental state, updated translation state for other languages (Beta: 70-80%+, Stable: 90-95%+).

6 Version 1.5.6e

April 28rd, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Peer networking improvements.
  • Announced addresses are always verified to resolve back to the peer address and not accepted if they don't. Old peer instances and old announced addresses are removed when a peer with dynamic IP changes address.
  • If nxt.maxNumberOfKnownPeers (default 2000) is exceeded, the peers pool size is reduced back to nxt.minNumberOfKnownPeers (default 1000), keeping the highest hallmarked peers first.
  • Peers are only identified by IP address now, not by address and port. Multiple nodes sharing the same IP address will be treated as one peer, with announced address and port as of the most recent GetInfo request or response sent out of or received from this address.
  • Incompatible change: If using non-default port, the hallmark must also include that port, otherwise the hallmark is ignored.
  • Optimizations in unconfirmed transaction propagation. When forwarding newly received unconfirmed transactions to peers, if their count exceeds 10, the broadcast is done in multiple batches of 10. When requesting unconfirmed transactions from a peer, the ids of the transactions currently in the pool are included in the request, so that the remote node does not need to include them in the response. The response size is also limited to 100 transactions, unless the requesting node does not provide such exclude parameter.
  • Each tagged data can now also have a channel field. The searchTaggedData API can filter the search results by channel, and a new getChannelTaggedData API has been added to retrieve tagged data by channel, optionally filtered by account too.
  • Fixed the UI for AddPeer and BlacklistPeer to accept admin password if needed.
  • "Approve Transaction" action is now available in the transaction info actions tab.
  • "Reveal Secret" field is added to the "Approve Transaction" modal when voting model is "By Hash".
  • Enhanced the /test page to accept and pre-fill the test forms with any parameter values supplied in the url, e.g.: http://localhost:7876/test?requestType=getBlocks&lastIndex=10&includeTransactions=true
  • This release will perform a full rescan on test net.

7 Version 1.5.5e

April 23rd, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Fixed processing of unconfirmed ExtendTaggedData transactions.
  • AddPeer and BlacklistPeer APIs now require POST and admin password.
  • This release will perform a full rescan on testnet.

8 Version 1.5.4e

April 22nd, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Fixed a bug in parsing ExtendTaggedData transaction json which prevents such transactions from propagating between peers.
  • Added permanent message option to most send transaction dialogs.
  • Other minor bugfixes.

9 Version 1.5.3e

April 19th, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • This update adds the Prunable Tagged Data feature, planned to be enabled at the voting system block too.
  • Prunable tagged data are similar to prunable plain messages with no recipient, but with additional searchable metadata fields added. This feature can be used for decentralized and trustless distribution of small (up to 42k, including the metadata) pieces of data, which are by default stored for two weeks only (24h on testnet), but can optionally be stored longer or indefinitely by some nodes, and can be verified against the blockchain even after their expiration.
  • Currently each tagged data can have the following fields, in addition to the data itself: name (required), description, tags, type, isText, filename.
  • Name, description and tags are indexed and searchable using Lucene. All data and metadata is prunable, after pruning only a single 32 byte hash remains.
  • Fee for either uploading or extending tagged data is based on the total data size (including metadata), and is 1 NXT for up to 1k bytes, 0.1 NXT for each 1k above, up to the limit of 42k.

New APIs:

  • UploadTaggedData - create and broadcast new tagged data.
  • ExtendTaggedData - extend the expiration time of already uploaded tagged data. If the data is still available, only the transaction id is needed. If not, already pruned data can be resurrected by including (in addition to the original transaction id) all of its fields too, i.e. name, description, etc. Anyone can submit an extension, not only the original uploader. Each extend transaction increases the expiration deadline by two weeks (24 h on testnet). Extending an existing tagged data from another account does not change the original submitter account id by which it is indexed and searchable.
  • VerifyTaggedData - used to verify expired tagged data downloaded from another node, against the hash in the current blockchain.
  • SearchTaggedData - full text search on name, tags, and description, optionally filtered by submitter account.
  • GetTaggedData - retrieve tagged data by transaction id.
  • GetAccountTaggedData - retrieve all tagged data submitted by a given account.
  • GetAllTaggedData - retrieve all existing tagged data.
  • GetDataTags - returns the distinct tags of all tagged data, with the number of data having each tag.
  • GetDataTagsLike - prefix search of data tags.
  • GetDataTagCount - the total number of distinct tags.
  • All the Get* and Search* APIs above can only retrieve tagged data that has not been pruned yet.
  • There is no client UI support for any of these APIs. It is expected that specialized third party plugins will be developed for specific tagged data use cases, depending on file type and target user group.
  • Currently the pruning of tagged data is controlled by the same configuration properties that are used for prunable messages expiration.
  • Same as with prunable messages, when using broadcastTransaction API to submit an already signed tagged data upload transaction, the prunable parts must be in the prunableAttachmentJSON parameter in case transactionBytes parameter is used. If submitting transactionJSON, it already has the prunable parts.

New debug APIs:

  • GetAllBroadcastedTransactions - if transaction rebroadcasting is enabled, returns the unconfirmed transactions that have been broadcasted from this node but have not yet been received back from a peer.
  • GetAllWaitingTransactions - returns the unconfirmed transactions that are currently temporarily kept in memory during transaction processing.
  • RebroadcastUnconfirmedTransactions - if transaction rebroadcasting is enabled, causes transactions currently in the unconfirmed pool to be broadcasted to peers again, until received back.

Other changes and bugfixes:

  • Improved handling of invalid transactions during block generation. Fixed validation of AE order cancellation transactions. Fixed a memory leak in processing of unconfirmed transactions. Set the default limit on waiting unconfirmed transactions nxt.maxUnconfirmedTransactions to 1000.
  • The DGS goods delivery data size will be limited to 1000 bytes after VS block.
  • Bugfixes in prunable messages processing.
  • Fixed phasing with whitelisted approval accounts.
  • On testnet, this release will perform a full rescan on first start with rollback to height 263895.

10 Version 1.5.2e

April 15th, 2015

  • This is an experimental release. It is a required update for all testnet nodes, but is also possible to run on main net.
  • Added getAllPrunableMessages API, returning all currently available prunable messages in reverse block timestamp order.
  • Added verifyPrunableMessage API, which can be used to verify that a prunable message obtained from another node (a service provider) matches the hash found in the blockchain, i.e. has not been tampered with.
  • Show maxPrunableLifetime setting in getState and getBlockchainStatus. Show current number of prunable messages in getState.
  • Changing the nxt.maxPrunableLifetime property now also affects existing prunable messages (next time pruning is run), as transaction timestamps instead of expiration timestamps are now used.
  • Reverted DGS goods delivery maximum size to 10 kbytes, same as in 1.4. For goods of a larger size, a prunable encrypted message should be included in the delivery instead.
  • Removed core restriction on 28 byte minimum prunable message length, this will be checked by the client UI only.
  • Added nxt.includeExpiredPrunables property, to be able to force to still include the prunable parts in the returned transaction JSON, even if expired, as long as they are still available. Can be used to force an archival node to always return those, thus allowing another archival node that feeds from it to also get all of them.
  • Limit the number of unconfirmed transactions that can be brought in memory to nxt.maxUnconfirmedTransactions, no limit by default. If set, transactions with lowest fee/size ratio are dropped from the unconfirmed pool first. The ordering is same as the one used when selecting which transactions to include in a new block.
  • Added requeueUnconfirmedTransactions debug API.
  • Added support for uncompressed non-prunable encrypted messages and encrypted to self messages, as a new appendix version, to avoid the need to specify the compression status as a request parameter when reading them.
  • Added setLogging API, to allow changing log levels without having to restart the server.
  • Added eventRegister and eventWait APIs, to be used for registering listeners and waiting for server events instead of polling.
  • Changed the parameters accepted by broadcastTransaction. The prunable parts must be submitted either in the transactionJSON, or, if using transactionBytes, in a new prunableAttachmentJSON parameter, which has the same format as the transaction attachment json. The prunableAttachmentJSON is also returned by the signTransaction and getTransactionBytes APIs now.
  • Added support for prunable plain and encrypted messages in the client UI.
  • Added optional buyer parameter to getDGSGoodsPurchases API.
  • Voting system UI improvements and bugfixes.

11 Version 1.5.1e

April 11th, 2015

  • This is an experimental release which adds the Prunable Messages feature. It will be enabled at the same block as the Voting and Phasing features.
  • This is a required update for all testnet nodes, but is also possible to run on main net.

New features:

  • Prunable plain and encrypted messages.
  • Plain and encrypted messages can now be created as prunable. For a prunable message, the message data itself is never a part of the transaction bytes. Instead, only a 32 byte sha256 hash of it is included in the bytes that are being signed, used to verify the signature, or to generate the full transaction hash or id. This makes it possible to completely remove the message data at a later time, keeping only that 32 byte hash, and still be able to verify the transaction signature and have the transaction hash and id unaffected by the pruning.
  • Prunable messages have a predefined lifetime, after which their prunable parts are deleted from the blockchain. This lifetime is measured starting from the transaction timestamp of the message. When a node receives a transaction or a block from a peer, it is only required that the prunable parts of any prunable message are also included if their expiration time has not yet been reached. If it has, and a valid message hash is included instead, the block or transaction will still be accepted.
  • Currently the minimum lifetime of all prunable data is set to 24 h for testnet, to allow easier testing of this feature. For main net, it is tentatively set to two weeks, but this is subject to change before the stable release. Note that pruning is performed at the same time as derived table trimming, which by default is every 1000 blocks, so the actual removal of the prunable data from the database will happen with some delay after their expiration time.
  • A node can choose to keep prunable messages longer, by setting the nxt.maxPrunableLifetime property to a larger value. It cannot be set to prune them earlier. Changing this value only affect transactions received after the change. Pruning can be disabled completely by setting this property to -1.
  • Prunable messages that have not yet been expired, but are past the minimum lifetime, are only retrievable using the getPrunableMessage(s) APIs, but are not included as part of their transaction JSON.
  • If a transaction containing prunable attachments is phased, the prunable parts are nevertheless saved and available immediately, not at finish height. If their expiration deadline comes before the phasing finish height, they will be pruned and not available at finish height.
  • Fees for prunable message attachments are set at 0.1 NXT per 1024 bytes, with the first 1024 bytes free (the regular transaction fee depending on its type still applies). This is again subject to change before the stable release.
  • The full size of prunable message attachments is limited to 42 kbytes. Note that the full size is still included for the purpose of calculating the total block payload, even though only the 32 byte hash is in the transaction bytes.
  • The size of regular plain and encrypted messages in this release has been restricted back to 1000 bytes, and will likely be reduced even further, before the stable release. This will be done in order to encourage users to switch to prunable instead of regular messages. Fees for regular message attachments will also be increased substantially.
  • Creating prunable plain messages of less than 28 bytes is not allowed, as at such small sizes it is more efficient to store the full message instead of a 32 byte hash of it. There is no lower limit on prunable encrypted messages.
  • It is not possible for a transaction to have both prunable plain and prunable encrypted message at the same time. It is also not possible to have both prunable and regular message of the same type (plain or encrypted). It is however possible to have a regular plain message and an encrypted prunable message, or a prunable plain message and a regular encrypted message.
  • Prunable encrypt-to-self messages are not currently supported as there seems to be no good use case for them.
  • Prunable encrypted messages can optionally be compressed before the encryption (default is to compress). The compression status is stored and does not need to be specified when decrypting. Regular encrypted messages are still compressed by default, but this compression can now optionally be disabled. For backwards compatibility, since their current bytes format does not store the compression status, this needs to be specified again when decrypting, else an error or unreadable data will be returned.

New APIs:

  • GetPrunableMessage - returns the prunable message for a given transaction id, optionally decrypting it if encrypted and if a secretPhrase is supplied.
  • GetPrunableMessages - returns all prunable messages for a given account id, optionally limiting to only those with another account as recipient or sender, and decrypting them if a secretPhrase is supplied.
  • Prunable messages that have already been pruned are not returned by the above APIs.
  • The UI for those APIs will be implemented in a later release.
  • TrimDerivedTables - a debug API to trigger a derived tables trim, and prunable tables pruning.

Changed APIs:

  • All APIs that create a new transaction now also accept optional messageIsPrunable or encryptedMessageIsPrunable boolean parameters (default false). If true, the message or encrypted message attachment, if any, is created as a prunable message.
  • To control whether compression is performed before the encryption or not, the new compressMessageToEncrypt and compressMessageToEncryptToSelf parameters can be used (default true).
  • Prunable messages, if not yet pruned, are also returned as part of the transaction json by the getAccountTransactions API, using the same fields as the corresponding regular messages, but adding a messageIsPrunable or encryptedMessageIsPrunable boolean flag.
  • ReadMessage now also handles prunable message attachments, if any. It takes an optional uncompressDecryptedMessage and uncompressDecryptedMessageToSelf (default true) parameters, only used for non-prunable messages (not needed for prunable ones).
  • DecryptFrom accepts an optional uncompressDecryptedMessage parameter, and encryptTo accepts an optional compressMessageToEncrypt parameter, default true.

INCOMPATIBLE changes:

  • BroadcastTransaction has been modified to optionally accept all parameters that are needed to create a prunable plain or encrypted message (client side encryption only). This is required because the data for such messages is never a part of the transaction bytes themselves, so trying to broadcast a transaction that has a prunable part by only submitting its bytes to broadcastTransaction WILL FAIL, unless the corresponding parameters necessary to add the prunable parts are also supplied. Note that they need to exactly match the original parameters with which the transaction bytes have been created and signed.
  • For non-prunable messages, broadcastTransaction behaves as before, but users are encouraged to start switching to prunable messages in view of the planned size restrictions and fee increases.
  • The EncryptedData java class no longer handles compression internally, this is left to the caller of the encrypt and decrypt methods to do.

Other changes:

  • GetPolls now supports an optional includeFinished parameter (default false).
  • Multiple bugfixes and improvements in the Voting System and Phasing UI.
  • The limit on transaction deadline of 1440 minutes has been removed. It is now possible to create a transaction with a deadline of up to 32767 minutes. This has been done because many use cases of phasing require that the transaction bytes are prepared much earlier than the actual broadcasting of the transaction to the blockchain.
  • This release will perform a database upgrade with a full rescan on first start. On testnet, it will cause a rollback to block 256935.

12 Version 1.5.0e

April 6th, 2015

  • This is an experimental release for the Voting System and Phasing. It enables these features on testnet, and is a required update for all testnet nodes.
  • It is also possible to run this version on main net, but the block at which the new features will be enabled has not been set yet.
  • New features:
    • Voting System.
      • Voting System API calls:
        • CreatePoll, CastVote, GetPoll, GetPolls, GetPollResult, GetPollVote, GetPollVotes, SearchPolls.
      • Polls processing is optional. If nxt.processPolls=false (default is true), vote counting is not done and no poll results are stored. This can be used to reduce the load on lower performance nodes. It is still possible to get the results of a poll using getPollResult, as long as the required vote and balances data hasn't been trimmed yet.
      • Regardless of the nxt.processPolls setting, votes for polls that finished before the last trim height (1441 blocks by default) are deleted and only aggregate results, if processing is enabled, are kept.
      • Votes are weighted based on the voting model selected, which can be by account, by balance, by asset balance or by currency balance, and a minimum balance cutoff can also be specified. The voting model is defined when the poll is created, however a different voting model can be specified when calling the getPollResult API, to calculate on the fly an alternative vote counting, as long as vote data is still available.
      • Voting multiple times, changing, or deleting votes is not allowed.
      • The fee to create a poll is 10 NXT for a poll with up to 20 options, with 1 NXT additional fee for any additional option (max 100 options are possible).
    • Phasing.
      • Phasing API calls:
        • ApproveTransaction, GetAccountPhasedTransactions, GetAccountPhasedTransactionCount, GetAssetPhasedTransactions, GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls, GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.
      • A transaction of any type can be phased by adding a phased=true parameter and an appropriate set of phasing parameters. Phased transactions are accepted in the blockchain immediately (subject to all usual validations), but are executed only at finish height, if still valid and if the required quorum has been met.
      • If not approved, or not valid at finish height, they remain in the blockchain but are never executed, and any changes they caused to the sender unconfirmed balance are reversed, except that the fee is not refunded.
      • In addition to the voting models available in polls, phased transactions can use a whitelist of accounts (max 10) allowed to vote for the transaction.
      • It is possible to vote for (approve) up to 10 phased transactions with a single approval transaction. This transaction will be accepted in the blockchain only if all phased transactions it is voting for are already in it.
      • Voting multiple times is allowed but has no effect on vote counting, votes after the first vote from each account are ignored.
      • It is also possible to make any transaction phased without needing voting for approval. This can be used to create transactions with deferred execution.
      • Pay on reveal secret is supported as a voting model for phased transactions.
      • When this voting model is used, the phased transaction must include the hash of a secret chosen by the sender (up to 100 bytes long), and an approval transaction for it is only accepted if it includes the secret that results in this hash. It does not matter who the sender of the approval transaction is, unless a whitelist is also defined. Supported hash functions currently are sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them as parameters are available from the getConstants API.
      • Finally, it is possible to make a phased transaction that is released or rejected not on the basis of voting, but based on the presence of other transactions (linked transactions) in the blockchain at its finish height. To do that, up to 10 phasingLinkedFullHash transaction hashes can be defined when creating the phased transaction. Note that this does not create a dependency between the linked transactions themselves. This feature can be used to implement atomic execution of transactions of any type, provided the phased transaction is phasing safe. Transactions already in the blockchain before the acceptance of the phased transaction can also be linked, as long as they are not more than 60 days old, or themselves phased transactions.
      • The deferred execution with no approval needed, pay on reveal secret, and linked transactions features are currently accessible using the API only, the UI for them will be completed in a later release.
      • Similar to voting, the phasing data for phased transaction that finished before the last trim height is also deleted and only the aggregate approval results are kept.
      • The fee for making a transaction phased depends on the voting model selected. For by-account voting with no minimum balance, or no voting needed, it is 1 NXT in addition to the regular fee for that particular transaction type. For voting that depends on voter balances, the additional phasing fee is 20 NXT.
      • The fee for approving a phased transaction is 1 NXT for each phased transaction included in the vote.
    • Variable size messages, encrypted messages, digital goods deliveries. After VS block, messages and encrypted messages will be allowed to be up to 40 kbytes long instead of 1000 bytes, with 1 NXT fee for each 1024 bytes. Digital goods deliveries can also be up to 40 kbytes, with 1 NXT fee for each 1024 bytes after the first 10k. A single transaction is always limited not to exceed the maximum block payload length, currently 255 * 176 bytes.
    • Other new APIs:
      • GetOrderTrades - given an askOrder, bidOrder, or both, returns all trades that were executed as a result of this order.
      • GetDGSExpiredPurchases - returns the purchases for a given seller which have expired without being delivered.
      • GetDGSTagsLike - returns all Digital Goods Store tags starting with a given (at least 2 characters long) prefix.
      • GetAliasesLike - returns all Aliases starting with a given (at least 2 characters long) prefix.
      • SearchAccounts - full text search on account info (name and description).
      • GetPlugins - returns a list of all installed plugins.
      • DumpPeers - returns all active peers of a certain version.
      • Shutdown - shuts down the server. Takes an optional scan parameter, if true the derived tables are truncated and a full rescan with validation is scheduled on next start. The resulting nxt_db folder is smaller, and a node bootstrapped with this database is going to verify the blockchain and rebuild all derived tables on start. While this ensures validity of the blockchain and all tables, it cannot verify that this is the current consensus blockchain and not a fork, therefore providing such a database for download is still not trustless.
      • GetLog - returns the most recent log messages, kept in a memory buffer.
      • GetStackTraces - returns the stack traces of the currently running threads.
      • Shutdown, getLog and getStackTraces require the admin password.
    • Changed APIs:
      • CreateTransaction - to facilitate debugging and to allow preparing transaction bytes and json even for transactions that are currently invalid, if broadcast parameter is false, all relevant transaction fields (json, bytes, hash, etc) are still included in the result even in the case of invalid transaction. If broadcast=true, those fields are returned only in case of successful transaction broadcast, otherwise only the error messages are returned. This change affects all APIs that end up creating a new transaction.
      • GetConstants - in addition to adding the new transaction types and subtypes, and the voting models, the format of the resulting json has been changed.
      • Added optional timestamp parameter to getExchanges and getTrades.
      • Added optional account parameter and pagination support to getCurrencyFounders.
      • Always include errorCode and errorDescription in some API results that only had an error field in case of an error.
      • Limit number of records returned by all APIs that support pagination to nxt.maxAPIRecords at a time (default 100), unless the admin password is provided or is not needed.
      • AddPeer adds an isNewlyAdded boolean to the returned peer json, indicating whether the peer was not already known.
  • Client changes:
    • Extended UI in the "advanced" transaction modal dialog for every transaction type for invoking the different variants of phased transactions (to be approved by a certain number of accounts or balance/asset/currency holders).
    • New main sidebar item for the Voting System, modal to create the various types of polls, pages to find active polls and follow polls over time, list with own polls and votes casted.
    • Generic notification system for incoming transactions showing the number of transaction types and total new transactions.
    • Unconfirmed transactions are only displayed in the "Dashboard" and "My Transactions" pages and no longer appear in other tables.
    • Transaction info dialog for AE Bid and Ask orders now displays a table containing the actual trades mathcing the specific order.
    • New account login feature for faster login just by Nxt account.
    • User specific client DB with new logout option to clear user data.
    • Streamlined sidebar/navigation structure.
    • Send Currency button added to the toolbar which invokes the transfer currency dialog
    • Environment information, client settings and various diagnostic information is logged to the browser's JavaScript console during startup and login.
    • Phasing tab was added to the transaction info dialog of phased transactions.
  • Various bug fixes.
  • Client Plugin System:
    • Functionality - The NRS client comes with a new plugin system, enabling third party developers to provide additional functionality for the client. Plugins can be activated/deactivated on startup, the status of installed plugins can be seen on a separate settings page. Plugins can hook into the new "Plugins" sidebar navigation item or provide their own navigation structure.
    • Security - Plugins are not sandboxed or restricted in any way and have full access to client functionality including the passphrase. It is essential to only install plugins from trusted sources and in doubt don't use plugins together with accounts storing larger amounts of NXT. There are prominent security warnings both on the login page and within the plugins folder.
    • Installation - A Plugin is provided as an archived file containing the necessary HTML/JS/CSS files and can be installed by extracting the file in the plugins/client directory.
    • Developer - For a plugin to be valid is has to follow a certain minimal file structure and be shipped with a manifest.json file with some meta information. Detailed information can be found in the DEVELOPERS.md file in the plugins/directory. There is also a "hello_world" example plugin to get an idea how things work.
  • Other important changes:
    • Fixed transaction ordering in AE order matching to always be by transaction index instead of by id, to take effect after Voting System Block.
    • Enforce nxt.adminPassword if set, even if the APIServer is listening on localhost only.
    • Added nxt.ignorePeerAnnouncedAddress and nxt.cjdnsOnly properties, relevant only for cjdns users or multihomed nodes.
    • Default initial peers are now stored in nxt.defaultPeers and nxt.testnetDefaultPeers instead of being populated by NxtDbVersion on database creation.
    • Allow the API server to handle both http and https requests on different ports, if nxt.apiServerSSLPort is set to a port different from nxt.apiServerPort and nxt.apiSSL=true. If the SSL and non-SSL ports are configured to be the same, the nxt.apiSSL property determines whether SSL is used or not. On testnet, non-SSL port is hardcoded to 6876 and SSL, if enabled, to 6877.
    • Reduced the default nxt.maxRollback to 800. Also added a nxt.trimFrequency setting to control how often the trim is run, default 1000.
  • This release requires Java 8 and will not run or compile with Java 7.
  • run.bat has been updated to search for a Java 8 installation using the Windows registry.
  • Updated Jetty to version 9.2.10 and Bouncy Castle to version 1.52. If unpacking on top of a previous installation, delete the old lib folder first.
  • This release will perform a database upgrade with a full rescan on first start.

13 Version 1.4.18

May 15, 2015

  • This is a bugfix release. Everyone is required to update.
  • Set the content type to "text/plain; charset=UTF-8" when sending http requests to peers. This is an important bug fix, as the incorrect encoding of outgoing blocks and transactions containing some Unicode characters can prevent their propagation and lead to forks.

14 Version 1.4.17

April 19, 2015

  • This is a critical bugfix release. Everyone is required to update.
  • Fixed validation of asset exchange order cancellations.
  • Fixed excessive memory usage in unconfirmed transaction processing.

15 Version 1.4.16

February 24, 2015

  • Updated jetty to version 9.2.9 due to a critical security bug:

http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00074.html There are no code changes, only the jetty libraries have been updated. Delete the old lib folder before unpacking on top of a previous installation.

16 Version 1.4.15

February 13, 2015

  • Possible fix for the invalid CurrencyMint counter exception.
  • Made URLs in descriptions clickable and fixed potential XSS exploit problem.

17 Version 1.4.14

February 9, 2015

  • Added debugging output for failing currency mint transactions.
  • Reduced default numberOfForkConfirmations to 2.

18 Version 1.4.13

February 9, 2015

  • Peer networking improvements, better logging, bugfixes.
  • News page now loads correctly when the wallet uses https.
  • Nxt forum message updates are displayed instead of new topics.
  • Feed refresh is performed whenever the news page is refreshed.
  • Minor UI bugfixes.

19 Version 1.4.12

February 4, 2015

  • Improved fork resolution by allowing a better difficulty block pushed from a peer to replace the current last block.
  • When forging, do not accept a peer block with hit time after the next hit time of a currently forging account (i.e. prevent front-running in forging).
  • Removed the possibility of a forger to miss his turn. Even if late, the block will still be generated and submitted.
  • Delay forging and submission of blocks by 20 s, configurable via the nxt.forgingDelay property, in order to be able to accumulate more transactions in the forged block. The arrival of a front-running block from a peer however cancels that delay and the next block is generated up to 3 s earlier instead, which can be controlled via the nxt.forgingSpeedup property.
  • The above time shifts apply to the physical time of block generation and submission only. Block timestamps are always fixed by the forging algorithm within 1 s accuracy, and are not possible to modify.
  • Better logging of peer networking errors. Log, but do not blacklist missing or malformed JSON responses.
  • UI for adding and blacklisting peers. Blacklisting from the UI is possible only when admin password is not needed (disabled or running on localhost).
  • Database optimization. Moved the public key of accounts, transaction senders, and block forgers to a separate table, resulting in 15% reduction of total database size. This change will be performed at first start and will take some time. A shutdown after the first start is recommended to compact the database.
  • Forging API improvements: getForging and stopForging now allow access using admin password instead of account secret phrase. This respectively retrieves the status of, or stops the forging of, all currently forging accounts. As with other admin password protected APIs, password is not required when the API server is listening on the localhost interface only. The getState API now also returns a needsAdminPassword boolean, to indicate this.
  • Enforce that the nxt-default.properties file used matches the version of the current release.
  • Added currency distribution dialog invoked using a link from the currency transaction info dialog.

20 Version 1.4.11

January 27, 2015

  • Fixed a bug in transaction validation that could break blockchain downloading.The default (and minimum allowed) value for nxt.maxRollback is now 1441.
  • Restrict maximum HTTP request and response size in peer networking to prevent potential out of memory attacks.
  • Ctrl-C can now stop the server without having to wait for initial rescan to complete.

21 Version 1.4.10

January 25, 2015

  • Improved display of blockchain downloading status in the client UI.
  • Added client translations, changed state from beta to stable for the following languages: Italian, Dutch, Ukrainian.
  • Fixed a bug in transaction bytes parsing which could cause signature verification failed errors and break forging.
  • When downloading the blockchain, require at most one fork confirmation when still below the last hardcoded checkpoint (currently MS block).
  • New API calls for peer management: addPeer and blacklistPeer. AddPeer will add a peer address or IP, optionally with port number, to the list of known peers and will try to connect to it. BlacklistPeer (password protected) will blacklist a peer, for the default blacklisting period.
  • These APIs, and a few others related to peer networking, have been grouped under a new Networking tab on the test page.
  • Peer port handling has been improved to allow different peers to share the same IP address provided they use different ports.
  • To prevent overloading a node with invalid peer addresses, the maximum total number of known peers is limited to nxt.maxNumberOfKnownPeers (default 2000).
  • Once this number has been reached, new peer addresses are not added, and peers that have been last connected to more than a week ago are removed from the known peer list, provided the node has enough connected public peers, until the number of known peers is again reduced to below nxt.minNumberOfKnownPeers (default 1000).
  • Improved database performance by storing currency supply and reserve per unit data in a separate table.
  • This release will perform a rescan on first start.
  • Updated jetty to version 9.2.7. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

22 Version 1.4.9

January 18, 2015

Server Logic:

  • Password protect the Debug APIs. The nxt.enableDebugAPI property is no longer used. Instead, the debug APIs which allow direct manipulation of the blockchain database are always enabled, but are now protected with a password, which needs to be set in the nxt.adminPassword property. Password is not required when the API server is listening on the localhost interface only (the default). The password protection can be disabled by setting nxt.disableAdminPassword=true.
  • Some refactoring to allow creation and signing of transactions using the Java API even in the complete absence of blockchain data, as needed for the MintWorker.
  • Minor peer networking improvement, addPeers and processBlock requests are now executed in the background.
  • Improvements in fork resolution. The peer networking getNextBlocks API no longer limits the number of blocks returned to 1 MB total payload size, but always returns 720 blocks, if available.

MintWorker:

  • Added nxt.mint.stopOnError property, default false. Minting will now continue, by default, even after an error occurred when sending the mint transaction to the server.
  • Minting transactions are now signed locally and sent to the server using the broadcastTransaction API. Thus the secretPhrase for the minting account is never sent to the server, and the server or the connection to it do not need to be trusted. The secretPhrase is also not logged to the log output anymore.

User Interface:

  • Added second row of info boxes on Dashboard.
  • Notifications for incoming messages.
  • Reworked page navigation.
  • Account leasing dialog now displays the number of blocks until lease expiration.
  • Fixed named account links on the transaction info dialog.

Client Translation:

  • Added language selection to welcome screen.
  • Added translations for monetary system for different languages.
  • Stable: English, Spanish, French, Lithuanian, Portuguese (Brazilian), Russian, Chinese (Simplified), Chinese (Traditional)
  • Beta: German, Finnish, Galician, Croatian, Indonesian, Italian, Japanese, Dutch, Slovakian, Portuguese, Serbian (Cyrillic), Serbian (Latin), Ukrainian

23 Version 1.4.8

January 11, 2015

  • Removed some validations and logic no longer needed after the Monetary System block.
  • Added a checkpoint at block 330000.
  • Various minor UI bugfixes.
  • Fixed currency search. Fixed handling of very high minting difficulties.
  • Fixed concurrency issues with Scrypt minting, can use multiple threads now.
  • Allow use of https for submitting minting transactions, set nxt.mint.useHttps=true. Note that this will accept any SSL certificate as valid, therefore will not protect you against man-in-the-middle attacks when minting.
  • Allow no more than one unconfirmed minting transaction per account and minted currency to be accepted in the unconfirmed pool.
  • Improvements in translations handling, documented in DEVELOPERS-GUIDE.md.
  • Better validation of hallmarks for peers with multiple addresses. Do not blacklist peers with invalid hallmarks but just treat them as not hallmarked.
  • Blacklist peers with versions older than 1.4.
  • As more than 720 blocks have passed since the MS block, nodes older than 1.4 are now on a fork that will not be resolved by itself. To fix that, upgrading such nodes from a version older than 1.4 to this release will cause deletion and full download of the blockchain.

24 Version 1.4.7.1

January 10, 2015

  • Always enable Monetary System menu in the UI as we are after block 330000 now.
  • There are no other changes from 1.4.7.

25 Version 1.4.7

January 6, 2015

  • This is a mandatory update. Everyone should update to 1.4.7 or later before block 330000.
  • The Message Pattern in AccountInfo feature, introduced in 1.4.0e, has been disabled, and will not be activated at block 330000. This is to prevent possible denial of service attacks by malicious regular expression patterns which can cause excessive CPU load with certain inputs. This feature will probably be introduced again in 1.5, but with a predefined set of allowed well behaved regex patterns.
  • Multiple minor UI improvements and bugfixes.
  • Enhanced nxt.allowedBotHosts property to also accepts a range of addresses using CIDR notation.
  • This release will perform a rescan on first start, on testnet only.

26 Version 1.4.6

January 1st, 2015

  • Set MS block to 330000 in the UI too, so that the MS features menu appears after that height.
  • Enforce that currency exchange offer expiration height is after the current blockchain height.
  • Refactoring of the UI html, splitting index.html into multiple files.
  • Added offer and transfer links to currency exchange booth UI.
  • This release will perform a rescan on testnet only, with a rollback to block 159305.

27 Version 1.4.5

December 28, 2014

  • Enable Monetary System at block 330000. This is a hard fork, therefore everybody should upgrade to 1.4.5 or later before that.
  • If upgrading from 1.3.x, read the 1.4.0e and later changelogs for the important changes and new features introduced in the 1.4 series.

28 Version 1.4.4e

December 25, 2014

  • Improvements and bugfixes in the UI of Monetary System, dividend payments, and account leasing.
  • Added contacts export/import feature.
  • Restrict currency exchange offer sell and buy supply not to exceed total sell and buy limit.
  • This release will force a rescan on testnet only, deleting blocks after 159306.

29 Version 1.4.3e

December 23, 2014

  • Added availableOnly parameter to getBuyOffers and getSellOffers, to return only exchange offers with non-zero supply and limit, default false. This parameter is however ignored when both currency and account are specified in the above APIs.
  • Added getExchangesByOffer API to get executed currency exchanges for an offer.
  • Do not log currency exchanges of zero amount.
  • Fixed setting of peer state. Improvements in connecting to peers.
  • Added README.md, DEVELOPERS-GUIDE.md OPERATORS-GUIDE.md, and USERS-GUIDE.md files.
  • Added search for currencies based on code, name, or description keywords.
  • Fixed bugs in unconfirmed balance handling in currency exchange and currency deletion.
  • This release will perform a rescan, on testnet only.

30 Version 1.4.2e

December 21, 2014

  • Additional validations of Monetary System transactions, and bugfixes in existing validations.
  • Allow setting a different file as default page for the API server, in nxt.apiWelcomeFile, default index.html.
  • Bugfixes in processing decimal point conversions in the UI, affecting MS and AE transactions.
  • Bugfixes in currency minting and in MintWorker. The mint dialog has been removed, you can mint using the mint worker utility or manually submit a currencyMint transaction from the test page.
  • Fixed the UI issue of client not responding after submission of certain MS transactions.
  • Fixed duplicate transactions on the dashboard UI issue.
  • The link to the founders table has moved from the currencies table to the transaction info dialog. Other Monetary System UI improvements.
  • Improved peer networking to run the sending of blocks and transactions to peers in a background thread.
  • This release will force a rescan on testnet only, deleting blocks after 159306.

31 Version 1.4.1e

December 17, 2014

This is a bugfix release following 1.4.0e.

  • Fixed Currency Exchange Booth not working.
  • Fixed currency decimals issue.
  • Fixed minor bugs in MS transaction validation.
  • Show total alias count in aliases page.
  • Alias deletion and dividend payment UI fixes.

32 Version 1.4.0e

December 17, 2014

This is the experimental release to test the new Monetary System major feature. It is enabled on testnet, and those running testnet nodes should upgrade to this release, even if they don't plan to use the MS features, otherwise will be left on a fork. This release is also possible to run on main net, but is not to be considered stable for production use there. The Monetary System block is not yet defined for main net.

New features:

  • Dividend payment transaction. Asset issuers can make a dividend payment to all asset holders with a single transaction. Required parameters are the blockchain height at which asset holders shares will be counted (must be less than 1440 blocks in the past), and the amount to be paid per share.
  • Delete alias transaction. The owner of an alias can now delete it completely, thus making the alias available for anyone to reserve again if desired.
  • Message pattern in AccountInfo. An account owner can set a regular expression pattern in the AccountInfo for his account, using the setAccountInfo API. Once such a pattern has been set, incoming transactions to this account are only accepted if they contain a plain text message which matches this pattern. The syntax follows the java.util.regex.Pattern specification.

API changes:

  • After MS block, adding a public key announcement when sending a transaction to an account without a public key will be optional.
  • Added withMessage boolean parameter to getAccountTransactions and getAccountTransactionIds APIs, to return only transactions having a message attachment, either non-encrypted or decryptable by the account.
  • Added optional includeLessors, includeAssets, and includeCurrencies boolean parameters to getAccount API. Set to false when retrieving those data is not needed, in order to improve the getAccount performance.
  • After MS block, sending messages, selling aliases, and leasing balances, to the Genesis account, will be disallowed.
  • The popOff debug API now allows pop off of more than max rollback number of blocks, triggering a full rescan in such case.

Internal changes:

  • After the Monetary System block, the order in which transactions in a block are executed will be determined by the block forger, instead of by id, default being by arrival time at the forger's node.
  • Improvements in blockchain download to prevent getting stuck on the wrong fork. Nodes will download blocks in batches of not more than 719 blocks at a time from a single peer, and after each such batch will verify with nxt.numberOfForkConfirmations other peers (default 5) if this is the best fork, before continuing, unless the downloaded batch is of less than 10 blocks.
  • Rescan status is now saved in the database, to prevent the database from being left in an inconsistent state when a rescan fails or is interrupted. Once a rescan has been scheduled, it will be triggered again at restart, until it completes successfully.
  • Improvements in the processing of unconfirmed transactions.
  • This release will perform a rescan on first start.

33 Version 1.3.5

December 14, 2014

  • Added getDGSTagCount API, allow getDGSGoodsCount and getDGSPurchaseCount to be used also to get total goods or purchase counts.
  • Added completed parameter to getDGSGoodsPurchases, getDGSGoodsPurchaseCount, getDGSPurchaseCount, getDGSPurchases, to allow querying for completed purchases only. Added withPublicFeedbacksOnly parameter to getDGSPurchaseCount.
  • Secondary sort of search results after sorting by relevance, by timestamp if for any seller, or by name and then by timestamp if for a single seller.
  • Improved performance of Marketplace page, show counts for goods in stock only.
  • Increased default purchase delivery deadline to 168 hours (1 week).
  • Include full peer info in getPeers API if includePeerInfo=true, to avoid having to do a separate getPeer request for each peer.
  • Include cumulativeDifficulty in the block JSON.
  • Allow transaction signing in signTransaction to skip the validation of the transaction bytes being signed, if an optional validate=false parameter is added. This would be useful when signing transaction bytes on a machine that doesn't have the full blockchain downloaded, which normally prevents validation.
  • Allow sending messages with no recipient.
  • Automatically blacklist peers with version older than 1.2.0.
  • UI improvements of the API /test page.
  • Changed nxt-default.properties to enable MVCC by default, to avoid database lock timeout errors.
  • Updated jetty to version 9.2.6. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

34 Version 1.3.4

November 20, 2014

  • This release is focused on improving the Nxt Marketplace (Digital Goods Store) by adding search and browse capabilities.
  • Implemented full text search using the Lucene library, as supported by H2. Table columns currently indexed are asset.name, asset.description, goods.name, goods.tags, goods.description. A rebuild of the search index can be forced using the luceneReindex debug API.
  • The full text search query parameter supports the standard Lucene syntax, which makes AND, OR, phrase queries, or wildcard queries possible. The default query operator is OR, to do an AND search need to specify AND between keywords explicitly.
  • Added searchAssets API which takes a query parameter and returns assets having name or description matching the query.
  • Added searchDGSGoods API which takes a query parameter and returns goods having name, tags, or description matching the query. The results can also be restricted to a specific seller, goods in stock only, or goods with a specific tag only.
  • getDGSPurchases API now takes an optional withPublicFeedbacksOnly parameter. If true, results are filtered to include only purchases with public feedbacks.
  • Added getDGSGoodsPurchases API to retrieve purchases for a specific goods, optionally those with public feedbacks only.
  • Added getDGSTags API returning all DGS Goods tags, sorted by number of goods in stock with that tag and total number of goods with that tag. Takes an optional inStockOnly parameter, default true, to retrieve tags for goods in stock only. At most three tags per goods are used, tags longer than 20 characters or shorter than 3 are ignored, and the parsing of tags is done using the Lucene StandardAnalyzer.
  • Show purchase counts and public feedback counts in all API responses returning Goods JSON, unless includeCounts parameter is false.
  • Include total numbers of Goods, Purchases, and Tags in the getState API.
  • Added getAccountAssetCount, getAliasCount, getDGSGoodsCount, getDGSGoodsPurchaseCount, getDGSPurchaseCount APIs, to be able to retrieve the corresponding total counts directly.
  • To populate the tags table in the database, a blockchain rescan will be done at first start.
  • Updated jetty to version 9.2.5. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.
  • UI changes:
    • The Marketplace page now shows a listing of tag keywords, ordered by number of goods in stock with that tag.
    • Clicking on each tag brings the list of goods having that tag.
    • Searching for goods is now possible using keywords from the goods name, description, or tags.
    • The list of goods also display the number of completed purchases, and for goods with a public feedback available, a link to display that feedback.

35 Version 1.3.3

November 12, 2014

  • Fixed incorrect guaranteed balance bug in getAccountLessors API.
  • Added getAccountBlockCount API returning number of forged blocks for an account.
  • Added includeCounts parameter to the getAssets API, to avoid getting trades,accounts, and transfers counts, if not needed.
  • Cache hallmarked peer account balances to reduce number of database calls.
  • Other minor performance improvements and bugfixes.
  • Fixed decryption of purchased DGS goods. Fixed missing DGS purchase feedbacks. To repopulate the feedbacks table, this release will perform a blockchain rescan at first start.
  • Added a hideDelisted parameter to the getDGSGoods API, default false. If true, delisted goods are not included in the results. This parameter has effect only if inStockOnly=false, as delisted goods are considered not to be in stock.
  • UI bugfixes and improvements. Added themes settings and a corporate theme.
  • Hide fee input when sending NXT in basic mode, and set to the minimum fee.
  • Improved the http://localhost:7876/test page interface, allow custom API call selection, syntax highlighting of the response JSON.
  • Added getAccountAssets API request, returning account asset balances for the specified account. If an asset parameter is also specified, only return balance for that asset. Unlike the getAccount API, this request can also take a height parameter, to return asset balance as of that height.
  • Added getAssetAccountCount API request, returning number of accounts holding the specified asset, again with optional height parameter.
  • Updated jetty to version 9.2.4. If unpacking on top of a previous installation, delete your lib directory first to remove the old jetty libraries.

36 Version 1.3.2

October 30, 2014

  • Allow re-broadcasting of transactions already in the unconfirmed pool.
  • Added clearUnconfirmedTransactions debug API to force clearing of the unconfirmed transactions pool.
  • Show correct timestamps in asset transfer history.
  • Only try to set account public key when inside a database transaction, fixes a bug in setting public keys for accounts that never had an outgoing transaction.
  • getAccountLessors API now returns the guaranteed balance of each lessor too, as of the height specified in the optional height parameter. The format of the returned json has been changed to allow adding this guaranteedBalanceNQT property.
  • getPeers now accepts an optional "state" parameter, to return only peers in that state. Possible values: CONNECTED, NON_CONNECTED, DISCONNECTED. If present, the active=true parameter takes precedence.
  • getBlock now accepts an optional "timestamp" parameter, to return the last block as of that timestamp. The parameters to getBlock: "block", "height", "timestamp", are processed in that order of precedence, i.e. if both height and timestamp are specified, height is used and timestamp is ignored. If no parameters, current last block is returned.
  • getState now accepts an optional "includeCounts" parameter, default true. If set to false, database table counts, which are slow to retrieve, are not included in the response.
  • getTrades, getAllTrades, and getAssetTransfers API now accept an optional "includeAssetInfo" parameter, default true. If set to false, asset name and decimals are not included in the result Trade json, and not having to retrieve those speeds up the request processing.
  • Added getBlocks API, returning the blocks ordered by height descending, and using firstIndex, lastIndex parameters for pagination. Restricted to return up to 100 blocks at a time. If includeTransactions is true, also includes the full transaction JSON.
  • Improved default H2 cache size allocation. If nxt.dbCacheKB is not set, the H2 cache will vary linearly from 16MB for JVM heap size 160MB, to 256MB for heap size 640MB or higher. This should allow low end devices to run without needing a custom setting for the nxt.dbCacheKB parameter, and prevent excessive memory use on machines with plenty of memory too.
  • Disabled the SSLv3 protocol when using SSL for the API.
  • Client UI improvements:
    • Added pagination to the Blocks page. The default number of rows per page can be changed in settings.
    • Show account balance in the sidebar on all pages.
    • Improvements and bugfixes in the asset trade and transfer history pages.
    • New design of the dashboard, and an improved recent transactions list.

37 Version 1.3.1

October 16, 2014

  • This is a critical bugfix release, everyone using 1.3.0 should upgrade.
  • Fixed a bug in transaction loading which was causing transaction id's and signatures for some transactions with invalid ecBlock values to change after saving and reloading from the database.
  • Report requestProcessingTime in the JSON of all API responses.
  • Delay loading of block transactions from the database until they are needed.

38 Version 1.2.9

October 16, 2014

  • This is a critical bugfix release, everyone using 1.2.8 or earlier should upgrade.
  • After installing 1.2.9, set nxt.forceValidate=true in nxt.properties and restart, to force a revalidation of blocks already in the database. Set this property back to false after the first run.
  • Fixed a bug in transaction loading which was causing transaction id's and signatures for some transactions with invalid ecBlock values to change after saving and reloading from the database.

There are no other changes from 1.2.8.

39 Version 1.3.0

October 14, 2014

This is the first release which stores all derived objects in the database, instead of keeping all of them in memory only.

Derived objects are those that are constructed based on the information already available in the blockchain blocks and transactions - i.e, Accounts, Aliases, Assets, Goods, Purchases, Orders, Trades. Storing them in the database instead of in memory means the Asset Exchange and the Digital Goods Store can scale to much higher number of assets, orders, and goods, without requiring an ever growing amount of memory for each node.

Using a standard SQL database tables to store those records also allows for much more sophisticated queries, and allows third parties to write and execute custom queries against those tables directly, without being dependent on the NRS http API only.

By storing the state of all derived objects as of the current height, plus their state at previous heights up to 1440 blocks back, it is possible to completely eliminate the need for blockchain rescans on startup, and on fork resolution.

On upgrade from 1.2.8 and older releases, this version will perform an initial build of the derived objects tables, which on a fast machine takes about 4 min, but may take longer depending on your hardware. The database size will again grow during this rescan, but after shutdown should shrink back to around 550 MB.

There will be no rescans on subsequent restarts, and the startup time is now reduced to a few seconds only. There will also be no rescans at runtime on block pop offs.

Derived object tables are kept small by trimming them, only records needed to allow rollback of up to 1440 blocks back are kept. If you need to preserve and query historical information going back all the way to height 0, this trimming can be disabled by setting nxt.trimDerivedTables=false (default is true) in nxt.properties. After changing this property, a rebuild of the derived tables can be triggered using the new scan API request, see below.

The default number of rollback records kept can be increased while still keeping trimming enabled, by setting nxt.maxRollback to a higher value (default and lowest possible is 1440). This should provide a compromise for those who want to keep history of more than the default 1440 blocks, yet want to avoid the performance penalty of never trimming the derived objects tables.

To allow for the increased use of database, default max number of database connection has been increased to nxt.maxDbConnections=30, and lock timeout increased to nxt.dbDefaultLockTimeout=60 in nxt-default.properties.

Slower machines and high traffic public nodes may experience database lock timeouts with the default settings. To prevent those, MVCC mode can be enabled by appending MVCC=TRUE to the jdbc url in nxt.properties. MVCC is not enabled by default however, because while providing for higher concurrency under multiple simultaneous connections, and thus avoiding timeouts, it is also slower overall and less well tested.

To help with debugging potential bugs, default logging level has been set to nxt.level=FINE in logging-default.properties for this release, which will cause more output than usual in the log.


API changes:

  • The following existing APIs now allow optional pagination using firstIndex, lastIndex parameters:
    • getAccountBlockIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds, getAliases, getAllAssets, getAllTrades, getAskOrderIds, getBidOrderIds, getAskOrders, getBidOrders, getAssetIds, getAssetsByIssuer.
  • The limit parameter is no longer accepted by the getAskOrderIds, getBidOrderIds, getAskOrders and getBidOrders APIs, as firstIndex/lastIndex parameters are now used instead for pagination.
  • getAccountBlockIds in addition to allowing pagination now returns the blocks in descending order, as this is more useful when showing the newest blocks on top in the client.
  • getTrades now accepts an optional account parameter, in addition to asset, to allow retrieving trade history for a specific account, for either all assets or a specific asset only.
  • getUnconfirmedTransactions and getUnconfirmedTransactionIds now also accept the RS account number format.
  • The Trade JSON now includes buyer and seller account ids, the height at which the trade occurred, the asset name, and the heights at which the ask and bid orders were accepted in the blockchain.
  • The Asset JSON now includes total number of transfers, and number of accounts holding the asset.
  • parseTransaction does not just return an error when trying to parse an invalid transaction bytes or JSON, but adds a validate=false field, plus the actual error message, in addition to the parsed transaction JSON.
  • getState no longer includes total effective balance.

New API requests:

  • getAccountBlocks - like getAccountBlockIds, but returning full block JSON. If includeTransactions parameter is true, also includes the transaction JSON.
  • getAccountCurrentAskOrders and getAccountCurrentBidOrders - like getAccountCurrentAskOrderIds and getAccountCurrentBidOrderIds, but returning full order JSON.
  • getAllOpenAskOrders and getAllOpenBidOrders now replace getAllOpenOrders, but only returning ask or bid orders respectively, and allow firstIndex/lastIndex pagination.
  • getAssetTransfers - retrieves the asset transfers for an asset, account, or both, sorted by height descending.
  • getAssetAccounts - accepts an asset parameter and returns all accounts holding this asset as of the current height, and the asset quantity each one owns, sorted by asset quantity descending. Takes an optional height parameter to allow retrieving asset holders as of a previous blockchain height.
  • getAccountLessors - retrieves the accounts that have leased their balance to the specified account, takes an optional height parameter to allow querying previous blockchain heights.

The historical height query feature in getAssetAccounts and getAccountLessors depends on the specified height records still being available, i.e. either table trimming disabled, or maxRollback set high enough to cover that height.

  • longConvert - an utility API to convert between signed long ids as used in the database and unsigned long ids represented as strings. Accepts an id in either form and returns both the signed and unsigned versions.
  • getECBlock - returns the ecBlockId and ecBlockHeight given an optional timestamp, current time if not supplied.

New debug API requests:

  • The following requests are used for debugging purposes only and should not normally be needed. They are disabled by default, set nxt.enableDebugAPI=true in the properties to enable them. Do not enable on a public node where the API is accessible to anyone.
    • fullReset - delete and redownload the whole blockchain.
    • popOff - accepts a numBlocks or height parameters, and pops off that many blocks or back to that height. If table trimming is enabled (default), at most 1440 blocks can be popped off. Derived object tables are rolled back to the specified height and blocks and transactions after that height are deleted.
    • scan - accepts a numBlocks or height parameters, rolls back the derived object tables to that height and rebuilds them by rescanning the existing blockchain from that height up again. Does not delete blocks or transactions from the blockchain, unlike the popOff request. A request to rescan more than 1440 blocks when table trimming is enabled will do a full rescan starting from height 0. Setting validate parameter to true will also re-verify signatures and re-valudate blocks and transactions during the rescan.

DbShellServlet: A command line access to the H2 database at runtime is now possible at: http://localhost:7876/dbshell This page uses the H2 shell tool to allow querying the database at runtime, directly from the browser, without having to enable auto server mode in the jdbc url. This servlet is only enabled if nxt.enableDebugAPI=true, and is very unwise to enable on a publicly accessible node as it allows full read and write access to the database.

The usability of the http://localhost:7876/test API access page has been further improved.

Packaging changes: To prevent intentional misunderstanding of why jar files hashes are never reproducible, the class files are now left unpacked in a classes subdirectory after compilation, instead of being packaged in a nxt.jar file. The run.sh and run.bat scripts have been modified to include this directory on the classpath instead of the nxt.jar file. Those who still prefer to build a nxt.jar file, can easily do that with the included jar.sh script, and modify the classpath to use it. A pre-built nxt.jar file will still be included for a few releases, as it is expected by the restart code when upgrading from an older version, but is not otherwise used.

Other internal changes:

  • Everywhere, object ids that used to be Longs are now primitive longs, as their use as HashMap keys is no longer needed.
  • Preserve and re-process unconfirmed transactions after fork resolution pop-off.
  • Improved propagation of unconfirmed transactions.
  • Multiple minor improvements and optimizations based on profiling results.
  • Merged in code to enable future variable fees based on transaction type and transaction size.
  • Updated Jetty to version 9.2.3.
  • Added an option to disable transaction re-broadcasting by setting the property nxt.enableTransactionRebroadcasting to false (default is enabled).

Testnet: This release will reset the testnet blockchain back to height 77431. Testnet nodes staying with 1.2.8 are already on a different fork.

There is no urgency to upgrade on main net, both 1.2.8 and 1.3.0 versions can coexist on the network and there is no hard fork involved. The local database changes however are not reversible, if you upgrade to 1.3.0 and decide to go back to 1.2.8, you will need to delete the nxt_db folder and re-download the blockchain.

40 Version 1.2.8

September 3, 2014

API changes:

  • The timestamp parameter in getAccountTransactionIds and getAccountTransactions now refers to the timestamp of the block in which the transaction was included rather than the transaction timestamp itself. Transactions are sorted in descending order of block timestamp and transaction id, instead of transaction timestamp. This is so that the sorting matches the order in which transactions are processed, and because transactions with earlier timestamps may appear in the blockchain after transactions with later timestamps have already been processed, thus being unintentionally skipped while navigating the transactions list by transaction timestamp.
  • The getAccountTransactionIds and getAccountTransactions requests now accept an optional numberOfConfirmations parameter, which can be used to retrieve only transactions with at least numberOfConfirmations number of confirmations.
  • The getBlock API now optionally accepts height instead of block parameter, to retrieve the block at that height. If both block and height are specified, height parameter is ignored.
  • The getBlock API now also accepts includeTransactions parameter, if set to true, full transaction JSON is returned instead of only transaction ids.

There are no other changes between 1.2.7 and 1.2.8, so those who rely on the old behavior of the above APIs can continue to use 1.2.7 for the time being.

Client GUI:

  • Added the option for merchants to specify a specially formatted message that is required to be added to a payment transaction or an asset transfer.
  • To activate this behavior, you must set your account info description to the following format: #merchant:[0-9]+#
    • This example will only accept a numeric message.
  • If the message should be of a particular length use this: #merchant:[a-zA-Z0-9]{4,8}#
    • This format will only allow messages that have a length of 4 to 8 characters and is alphanumeric.
  • Note that the regex is case sensitive.
  • Fixed issue with public key field not showing when using a contact in the recipient field.

41 Version 1.2.7

August 26, 2014

  • No longer allow creation of pre-DGS block transactions, and ignore such transactions received from old version peers on a fork.
  • Improvements in exception handling, transaction validation, error logging. Updated run.bat file. Blacklist unreachable peers on connection timeout. Prevent server from starting if any of the startup tasks failed.
  • Added an optional "active" parameter to the getPeers API request. If true, only active peers are returned (those in state CONNECTED or DISCONNECTED).
  • Avoid unnecessary DNS queries.
  • No longer process or return "comment" parameters in Asset Transfer.

42 Version 1.2.6

August 17, 2014

  • Preserve unconfirmed transactions during rescan instead of relying on being able to get them again from peers.
  • Keep retrying the block generation in the case it fails due to an invalid transaction. Prevent block generation failures due to minimum transaction size changes.
  • Ignore peer weights in choosing a random peer when hallmark protection is disabled (it is enabled by default). When hallmark protection is enabled, the nxt.maxNumberOfConnectedPublicPeers count is now based on hallmarked peers only, i.e. the node will keep trying to connect to more peers until it is connected to at least that many hallmarked peers.
  • Added peer networking addPeers request. After sending a getPeers request and processing the response, the peer will also send to the other peer all peer addresses it is connected to which are not present in the other peer's peers set, to improve the propagation of peer addresses through the network.
  • Minor bugfixes.

43 Version 1.2.5

August 13, 2014

  • Added peer networking gzip compression. It is enabled by default, and will make downloading of the blockchain faster, but in case it causes extra load on your public node can be disabled by setting nxt.enablePeerServerGZIPFilter=false in nxt.properties.
  • Enabled serving gzip compressed static resources (html, javascript, css files)by the API Server. This would make loading the wallet UI from remote servers faster. The compressed .gz files are included in the installation package.
  • Allow gzip compression of API Server responses too, however this is disabled by default. This would be helpful when running the server on a remote machine, for online wallets and service providers, to enable it set nxt.enableAPIServerGZIPFilter = true in nxt.properties.
  • Fixed client-side rescanning bug that caused UI to appear outdated.

44 Version 1.2.4

August 11, 2014

  • Fixed important bugs affecting arbitrary message and asset transfer transactions before DGS block.
  • Minor client UI bugfixes.
  • Updated jquery to version 2.1.1 and bootstrap to version 3.2.0.

45 Version 1.2.3

  • Everyone should upgrade to 1.2.3 before block 213000.
  • Those upgrading from the previous stable release, 1.1.6 or earlier, should also consult the changelogs for 1.2.0e, 1.2.1e and 1.2.2e for important changes introduced in the 1.2 branch.
  • Minor bugfixes.
  • ParseTransaction, signTransaction, and broadcastTransaction API can now accept transaction in JSON format instead of transaction bytes.
  • Moved DGS block forward, will be enabled at 213000 instead of 210000.

46 Version 1.2.2e

This is a development release for testing only. Source code is not provided. Change log:

  • This is still a test release intended to get testnet working. Please update your testnet nodes.
  • Bugfixes in transaction attachment versioning and version validation.
  • Added encrypt-to-self message attachment type. Any transaction can optionally have such an attachment, intended to be used for private notes that only the transaction sender can read. This feature is not yet supported by the GUI.
  • Added nxt.isOffline property. If set to true in nxt.properties, peer networking will not start, no peers will be loaded from the database, and no outgoing connections will be made.

47 Version 1.2.1e

This release is still considered experimental, but is now enabled to run on main net too. The DGS milestone block is set to 210000 for main net. A stable release is expected before that, but all exchanges and websites should already start trying the 1.2.1e release, because the upgrade to 1.2.2 stable will be mandatory before block 210000.

  • Multiple bugfixes in DGS and Alias Transfer transaction validation. Restricted some types of alias and DGS transactions to one per alias / DGS purchase per block.
  • Alias sale transactions now use null recipient instead of genesis when the sale is open to any buyer. Alias buy transaction uses amountNQT instead of priceNQT parameter, as the price is being stored in the amount field anyway.
  • GetDGSGoods request now always skips delisted goods.
  • Improved handling of IPv6 addresses.
  • Improved the http://localhost:7876/test interface by adding support for tagging of API requests in multiple categories. All http API requests are now classified under separate tabs for easier navigation.
  • Reduced startup time by running in parallel the initial peer loading and address resolution, and the initial blockchain scanning.
  • To improve database performance, transactions that do not have a recipient now have null instead of the genesis account id as recipient in the transactions table. Such transactions will also not have a recipient field in their JSON.
  • Added support for pagination to the getAccountTransactionIds API. The results are now returned sorted by timestamp in descending order.
  • Added getAccountTransactions API also returning the full transactions json.
  • Refresh peer info for already connected peers every hour.
  • Call setReuseAddress(true) for all jetty ServerConnectors.
  • Refactoring of transaction attachment handling. Added support for transaction versions and global options. Transactions will switch to version 1 at DGS block.
  • Added Message and EncryptedMessage attachments that can be attached to any transaction types, and can have either text or binary content. All APIs that create a new transaction now accept additional parameters to allow attaching a Message or EncryptedMessage (or both). This removes the need for creating new transaction types for encrypted messages or payments with messages.
  • After DGS milestone block, Asset Transfer transactions can no longer have a "comment" field. Switch to using a plain text "message" attachment instead.
  • Added transaction attachment versioning. Transactions of version 1 and later will have a version field in the attachment too, which allows future optional changes to one attachment type only, e.g. adding expiration field to asset issue attachment without having to add a new transaction type.
  • Added PublicKeyAnnouncement attachment. Those will be accepted after DGS block, but only enforced after block 215000. After that block, transactions with recipient account that does not have a public key will be required to have such an attachment in order to announce and set the public key of the reciepient. To add a PublicKeyAnnouncement, just add a "recipientPublicKey" parameter with the hex-encoded public key string when sending the first transaction to that account. It is harmless (but useless) to keep adding the same recipientPublicKey for further transactions to the same account. But trying to set a different public key for an account that already has a public key will result in rejectionof the transaction.
  • The getAccountId request can be used to get the public key for a secret phrase (even when not yet announced to the blockchain).
  • Added first part of Economic Clustering - fork detection. After DGS block, each transaction will include a reference to a recent blockId. For now this is used only to detect forks, and transactions refering to a different fork are still not rejected.
  • Next step of Transparent Forging will be enabled at block 215000: accounts that miss their turn to forge will not be able to forge for the next one hour.
  • Updated jetty to version 9.2.2 and bouncycastle to version 1.51.
  • This release will cause a reset of testnet, deleting blocks and transactions after block 117907.
  • Client Updates:
    • Redesign login page.
    • Multilingual interface. Some translations are incomplete and still considered experimental.
    • Most forms now allow you to add an encrypted or public message to them.
    • Added public key announcement support.
    • Passphrase login length check.
    • Automatically enable certain features at DGS block.
    • Several DGS bug fixes.

48 Versión 1.2.0e

29 de Junio de 2014

  • Esta versión solamente funciona en la red de pruebas. Define nxt.isTestnet=true en nxt.properties.
  • Nuevas características:
    • Mercado Digital (Digital Goods Store/DGS)
      • Nuevas llamadas API http para crear transacciones: dgsListing, dgsDelisting, dgsPriceChange, dgsQuantityChange, dgsPurchase, dgsDelivery, dgsRefund, dgsFeedback
      • Nuevas llamadas API http para consultas a DGS: getDGSGood, getDGSGoods, getDGSPurchase, getDGSPurchases, getDGSPendingPurchases
      • Los bienes y mensajes intercambiados entre compradores y vendedores están encriptados con AES, y comprimidos en gzip antes de ser encriptados. El tamaño máximo para bienes digitales es de 10240 bytes tras la compresión y el encriptado.
    • Transferencia de Alias.
      • Nuevas llamadas API http: sellAlias, buyAlias
      • La venta de alias puede ser restringida a un comprador específico, o abierta a cualquiera. La venta de alias a precio 0 se trata como una transferencia inmediata y no requiere una transacción de compra de alias separada. Para cambiar el precio, envía una nueva transacción sellAlias. Para cancelar una venta, envía una nueva transacción sellAlias a tí mismo con precio 0.
      • La transacción de compra de un alias sólo puede emitirse si el alias ya se encuentra a la venta. En este momento no es posible pujar por un alias que no esté a la venta.
    • Mensajes encriptados.
      • Los mensajes encriptados con AES ya están soportados en el núcleo, por lo que ya no es necesario utilizar sistemas externos de encriptado en los mensajes arbitrarios. Utiliza mensajes arbitrarios para texto simple, y mensajes encriptados para mensajes confidenciales.
      • Nuevas APIs: sendEncryptedNote y readEncryptedNote. La longitud máxima del mensaje es de 1000 bytes, tras compresión y encriptado.
      • Nuevas llamadas API http: encryptTo/decryptFrom pueden usarse para encriptar y desencriptar texto arbitrario de/para una cuenta. Pero estas llamadas solamente se ocupan del encriptado y desencriptado, no envían los mensajes.
  • Nueva consulta http rsConvert http para convertir un número de cuenta al formato RS y viceversa.
  • Nueva API getBlockId para obtener la Id del bloque a una altura determinada.
  • Mejorado el registro para manejar los casos en que Nxt esté integrado como librería.
  • Mejoras menores: getState y getBlockchainStatus también muestran ahora el nombre de la aplicación, el JSON de un bloque también muestra generatorPublickKey, getAccountId también acepta publicKey como parámetro.
  • Jetty actualizadp a la versión 9.2.1.
  • Actualizaciones en el cliente:
    • IU para el Mercado Digital.
    • IU para el intercambio de Alias.
    • Mensajes encriptados.
  • Sólo se permiten números de cuenta RS. Los intercambios y servicios deberían cambiar al formato RS tan pronto como sea posible.
  • Función para Decodificar Token.
  • Tarifa y Tiempo Límite ocultos por defecto, aparecen en la visualización avanzada.
  • Muestra un mensaje de aviso si el usuario está en una bifurcación (si su cuenta ha generado por lo menos los 10 últimos bloques).
  • Varias opciones (recordar contraseña por defecto, formato de 12/24 horas).

49 Versión 1.1.6

27 de Junio de 2014

  • Arreglados errores lógicos en el manejo de transacciones sin confirmar y en la detección de transacciones de doble gasto.
  • Mejorado el rendimiento de la consulta getTransactions.
  • Añadido el parámetro nxt.debugLogUnconfirmed (falso por defecto) para controlar el registro de errores en saldos sin confirmar.
  • Mejorada la IU del servlet de pruebas API, parche enviado por Holger Drewes.

50 Versión 1.1.5

20 de Junio de 2014

  • Arreglado un caso especial en el cálculo del saldo sin confirmar. Añadidas comprobaciones adicionales para el saldo de la cuenta.

51 Versión 1.1.4

  • Limpieza de las API http referentes a los Alias. Ahora hay solamente dos llamadas API para conseguir un alias:

getAlias
parámetros: o bien "aliasName" (el nombre del alias) o "alias" (la id del alias)
devuelve: JSON completo del alias

getAliases
parámetros: "timestamp" (marca de tiempo opcional) y "account" (la id de la cuenta, requerida)
devuelve: lista de alias (JSON completo) poseidos por la cuenta, opcionalmente filtrados por marca de tiempo

  • Las viejas llamadas getAliasId, getAliasIds, getAliasURI y listAccountAliases se han eliminado por ser redundantes, ya que las llamadas nuevas proporcionan toda la información necesaria.
  • assignAlias se ha renombrado como setAlias, con los parámetros "aliasName" y "aliasURI".
  • Eliminada la API getAssetsByName.
  • La API getAssetsByIssuer acepta ahora un parámetro "account" con valor múltiple y devuelve una lista de listas de valores emitidos por las cuentas especificadas.
  • Utiliza el framework de registro slf4j. ¡Gracias a ScripterRon por adaptar nuestro Logger para usar slf4j! El registro se puede configurar en conf/logging.properties, ver conf/logging-default.properties para posibles parámetros y sus valores por defecto, y crear un archivo conf/logging.properties nuevo con configuración personalizada si es necesario.
  • Mejoras menores en DebugTrace - registra eventos de Mensajes Arbitrarios, remitente y destinatario, e ids de bloques generados.
  • Mejoras en la validación de transacciones y la lógica de re-escaneo.
  • Actualizacione en el Cliente:
    • Ya no muestra la lista de valores completa. Deben añadirse ahora manualmente mediante la ID del valor o la ID de la cuenta emisora.
    • Búsqueda instantánea de valores favoritos (enter no es necesario).

52 Versión 1.1.3

  • Maneja el undo de la asignación inicial de alias para minimizar el número de re-escaneos. Limpia el mapa de transacciones sin confirmar después del re-escaneo en lugar de hacerlo antes.
  • Añadido el parámetro nxt.forceValidate para permitir la re-validación de bloques y transacciones en el arranque.
  • IU del Cliente:
    • Asignado el formato de cuenta reed solomon por defecto.
    • Búsqueda por número de cuenta reed solomon.
    • Color de fondo distinto para los valores en propiedad en la barra lateral de valores.
    • Diferencia el color de fondo de los valores emitidos.
    • Enlace automático a las URLs en la descripción de valores y los datos de alias.
    • Muestra un aviso al inicio si hay una actualización de NRS disponible.
    • Añadido en la configuración un aviso de transferencia máxima de valores.
    • Añadido un menú de ayuda.
    • Corregidas las cantidades en la página my assets.
    • Búsqueda de alias en la página de alias.
    • Añadido el número global de transacciones sin confirmar a la página de transacciones.
    • Muestra la cantidad de valores disponibles para transferir en el modo de transferencia de valores.

53 Versión 1.1.2

  • Evita el procesamiento innecesario de bifurcaciones que resultaba en demasiados escaneos.

54 Versión 1.1.1

  • Arreglado el problema con las bifurcaciones. Esperamos.
  • Incluido guaranteedBalanceNQT (1440 confirmaciones) en el JSON de getAccount.
  • IU del Cliente:
    • Arreglada la visualización del AE en Safari.
    • Eliminadas partes de la lógica pre-NQT. AE visible por defecto.

55 Versión 1.1.0

  • Los adjuntos se almacenan ahora en la base de datos como matrices de bytes en lugar de objetos serializados. La conversión se producirá en el primer arranque de esta versión y llevará algo de tiempo y de espacio en disco, pero tras cerrar la base de datos encogerá todavía más (cerca de un 25%).
  • Añadido punto de chequeo en la cadena de bloques en NQT_BLOCK.
  • Se confía en la necesidad de firmas parcialmente canónicas después de NQT_BLOCK para detectar ataques a la maleabilidad en la firma, eliminada la lógica que forzaba a los hashes de transacción a ser únicos (con la excepción de las firmas). Sólo el hash completo (incluyendo la firma) es ahora único. Por esta razón, la propiedad "hash" se ha eliminado del JSON de transacción y ahora solamente se devuelve "fullHash".
  • Uso del hash completo en lugar de la id para transacciones de referencia. Las transacciones existentes en la base de datos se reprocesarán como parte de la conversión de la base de datos.
  • Las transacciones de referencia pueden referirse a transacciones de no más de 60 días de antigüedad. Esta limitación es obligatoria a lo largo de toda la cadena de transacciones de referencia en el caso de que la misma transacción referenciada se refiera a su vez a otra anterior, y así. Además, la longitud de estas cadenas está limitada a 10 transacciones.
  • Elimiados algunos chequeos NotYetEnabled que ya no son relevantes. Eliminada toda la lógica obsoleta posible que trabaja con cantidades en NXT, ya que todas las transacciones nuevas se crearán a partir de ahora en el formato NQT.
  • Más pares que causan RuntimeExceptions incluidos en la lista negra.
  • Los intercambios devueltos por la API getTrades están ahora en orden inverso, los más recientes primero.
  • Actualizaciones en el Cliente:
    • Las transacciones in confirmar se añaden a la pantalla de forma inmediata.
    • Muestra el correspondiente mensaje al re-escanear la cadena de bloques.
    • Limita el historial de intercambios a los últimos 50 intercambios.
    • Muestra notificaciones de la compra y venta de valores.

56 Versión 1.0.3

11 de Mayo de 2014

  • Account.getPublicKey() debe devolver null si la clave pública no ha sido aún incluida en un bloque. Relacionado con el problema de descarga de la cadena de bloques bloqueada en el bloque 133933.
  • Incrementados los valores por defecto de timeouts en nxt-default.properties.
  • IU del Cliente:
    • Arreglado un error de revisión de NQT.
    • Arreglado el problema de la barra de desplazamiento en el asset exchange.

57 Versión 1.0.2

10 de Mayo de 2014

  • Añadida la API getUnconfirmedTransactions, que devuelve los objetos JSON completos para todas las transacciones sin confirmar, opcionalmente filtradas según el parámetro de cuenta.
  • Añadido el script win-compile.sh para compilar en Windows.
  • GetForging también muestra el tiempo "restante" para forjar un bloque.
  • Se borra el estado de Generator al re-escanear, probablemente la causa del problema de escaneos repetidos.
  • Actualizaciones en el Cliente:
    • No forjar automáticamente mientras se descarga la cadena de bloques.
    • Esperar hasta que la cadena de bloques termine de descargarse antes de permitir el envío de formularios.
    • Arreglada la notificación de actualizaciones.
    • Las páginas de bloques y pares se actualizan automáticamente.
    • Mostrar notificación de compra/venta de valores.

58 Versión 1.0.1

9 de Mayo de 2014

  • Añadida la API getAssetsByIssuer para obtener todos los valores emitidos por una cuenta.
  • Añadidas las llamadas API getAskOrders y getBidOrders, que devuelven los objetos JSON completos.
  • Añadido BlockchainProcessor.getLastBlockchainFeederHeight(), para ayudar a determinar el estado de descarga de la cadena de bloques. Ten en cuenta que esto sólo está presente cuando el par que suministra los datos también lo soporta, esto es, a partir de esta versión.
  • Añadido BlockchainProcessor.isScanning() para comprobar si hay un re-escaneo en curso.
  • Añadida la API getBlockchainStatus que contiene el estado mencionado arriba. Es más eficiente usar esta llamada API que getState.
  • Mejorado DebugTrace para registrar eventos de inicio y fin de un leasing, y los saldos garantizados por bloque de cada usuario que ha hecho un leasing en el archivo nxt-trace.csv.
  • Añadido soporte en el servidor para la codificación Reed-Solomon de los números de cuenta, gracias a ChuckOne que convirtió la versión javascript a java. Todas las llamadas API que aceptan números de cuenta pueden reconocer ahora IDs de cuenta o direcciones Reed-Solomon. Las respuestas con datos JSON que contienen números de cuenta también los suministran ahora en formato Reed-Solomon.
  • Añadidos los métodos Crypto.getPrivateKey() y Crypto.curve(). Añadida la librería Bouncy Castle, para su uso en encriptación AES en lugar de la implementación por defecto con fuerza limitada.
  • Añadido Account.getForgedBalanceNQT() para hacer un seguimiento del total de comisiones por forja obtenidas por cada cuenta, disponibles como forgedBalanceNQT en getBalance y getAccount.
  • Aumentado el timeout por defecto para consultas a la base de datos a 10 segundos, nxt.dbDefaultLockTimeout en nxt-default.properties.
  • Se revisan los pools sin confirmar para prevenir transacciones de doble gasto tras enviar cada bloque.
  • Soporte para conexiones IPv6, parche proporcionado por ScripterRon.
  • Actualizado jetty a versión 9.1.5. Asegúrate primero de borrar los archivos jar antiguos de jetty de la librería si descomprimes esta versión encima de una instalación anterior.
  • Actualizaciones en el Cliente:
    • Soporte para Reed Solomon integrado. Aún no activado por defecto. Usa los settings para cambiarlo.
    • Añadido aviso al usuario cuando la cantidad de NXT o la tarifa en NXT son mayores de lo especificado en los settings.
    • Añadido el saldo forjado al dashboard.
    • Se puede ahora buscar en el Asset exchange.
    • El progreso en la descarga de la cadena de bloques usa ahora la nueva API.
    • Muestra las transacciones sin confirmar en el dashboard inmediatamente después de enviarlas.

59 Versión 1.0.0

28 de Abril de 2014

  • La antigua interfaz de usuario NRS está ahora desactivada por defecto. Sólo la nueva IU está disponible, en http://localhost:7876
  • Añadidos los eventos para el leasing de cuenta, se pueden registrar 'listeners' para LEASE_SCHEDULED, LEASE_STARTED and LEASE_ENDED. Esto solamente interesa a los usuarios de la API Java.
  • Arreglados errores menores. Evitados errores de validación para transacciones nuevas en el escaneo de la cadena de bloques. Eliminados los chequeos NotYetEnabled para los bloques ya pasados.
  • Añadido archivo README.txt, consultar para instrucciones de instalación y configuración.

60 Versión 0.9.10e

27 de Abril de 2014

  • Añadida la API getAllAssets que devuelve todos los Valores, y la API getAssets que toma un parámetro "asset" con valores múltiples y devuelve los Valores con sus assetIds correspondientes.
  • Añadida la API signTransaction que toma unsignedTransactionBytes y secretPhrase y devuelve los bytes de transacción firmados, la id de transacción, el hash completo y el hash de la firma. La transacción no es transmitida.
  • Para prevenir ataques de denegación de servicio, todas las transacciones que deban quedarse en el 'pool' de transacciones sin confirmar, mientras esperan que lleguen sus transacciones de referencia, recibirán un cargo reembolsable de 100 NXT. Esto se deduce del saldo sin confirmar de la cuenta en el momento en que la transacción es aceptada dentro del 'pool' de transacciones sin confirmar, y es reembolsado cuando la transacción es confirmada, o expira y es retirada del 'pool'.
  • Añadida la interfaz de Wesley dentro de html/ui, disponible por defecto en http://localhost:7876

61 Versión 0.9.9

25 de Abril de 2014

  • Todas las llamadas API http que envían una nueva transacción permiten ahora el parámetro opcional "broadcast". Si se define como falso, la transacción no será transmitida, y con cualquier otro valor será transmitida. Por supuesto, las transacciones sin firma nunca serán transmitidas. Los bytes firmados y sin firmar son siempre devueltos en el JSON de transacción, de modo que los bytes firmados pueden ser transmitidos manualmente más tarde.
  • Arreglados errores menores en el manejo de la id de transacción de referencia.
  • El cálculo del hash de transacción completo (y por tanto de la id de transacción) ha sido cambiado, con efecto en el bloque NQT_BLOCK. En lugar de usar la firma como parte de los bytes a partir de los que se calcula el hash, se usa ahora el hash sha256 de la firma.
  • Después de NQT_BLOCK, el cambio anterior permitirá una forma sencilla de escrow para transacciones, basada en la función de transacción de referencia que ya tenemos:
    • Alicia prepara y firma una transacción A, pero no la transmite (definiendo el nuevo parámetro broadcast=false). Manda a Roberto los bytes de transacción firmados, el hash completo de la transacción, y el hash de la firma. Todos ellos están incluidos en el JSON devuelto por la API. (Aviso: es importante no enviar los bytes de transacción firmados, o la firma, porque entonces Roberto podría transmitir él mismo la transacción A).
    • Roberto prepara, firma y transmite la transacción B, definiendo el parámetro referencedTransactionFullHash como el hash completo de A proporcionado por Alicia. Él puede verificar que este hash corresponda a la transacción que espera por parte de Alicia, utilizando la nueva API calculateFullHash, que toma los bytes de la transacción sin firmar y el hash de la firma (ambos valores enviados por Alicia a Roberto). Él también puede usar la API parseTransaction API para decodificar los bytes sin firmar e inspeccionar todos los campos de la transacción.
    • La transacción B es aceptada en el 'pool' de transacciones sin confirmar, pero mientras A siga sin aparecer, B no será confirmada. Esto es, no será incluida en la cadena de bloques. Si A no se envía nunca, B expirará tarde o temprano - por lo que Roberto debería definir un tiempo límite lo suficientemente largo, como el máximo de 1440 minutos.
    • Una vez está en el 'pool' de transacciones sin confirmar, Roberto no tiene forma de cancelar B. De modo que Alicia puede ahora enviar su transacción A con seguridad, transmitiendo solamente los bytes de la transacción firmada que obtuvo en el primer paso. La transacción A será incluida en la cadena de bloques primero, y en el bloque siguiente la transacción B de Roberto también será incluida.
      • Ten en cuenta que aunque el esquema anterior es adecuado para un escrow simple, la cadena de bloques no obliga a que si A es incluida, B también lo sea. Podría darse el caso de que, debido a bifurcaciones o una reorganización de la cadena de bloques, B no llegue a tener la oportunidad de ser incluida y caduque sin confirmar, mientras A permanece en la cadena de bloques. Sin embargo, no es posible para Roberto causar intencionadamente esta cadena de eventos para evitar que B sea confirmada.
  • Debido al cambio en el cálculo de la id de transacción, en la red de pruebas se ha movido NQT_BLOCK a 76500, lo que causará un reset menor borrando los bloques posteriores a 76000.
  • En la red principal NQT_BLOCK está definido ahora en 132000, FRACTIONAL_BLOCK en 134000, ASSET_EXCHANGE_BLOCK en 135000. Cualquier error en NQT o AE debe ser localizado y resuelto con anterioridad.
  • El tiempo límite para actualizar a 0.9.9 es el bloque 130000, cuando se activa la función de leasing de saldo. Los nodos 0.8.13 se quedarán en una bifurcación después de ese bloque. Los nodos 0.7.7 probablemente ya se encuentren en una bifurcación.
  • Como la rama 0.9 de la API sólo acepta cantidades en NQT, cualquier cliente, sitio web, o intercambio que aún utilice cantidades en NXT, basado en la API 0.8, debería actualizar a la API 0.9 con NQT antes del bloque 130000. En caso contrario se quedarán colgados en 0.8.13, que como ya he comentado estará en una bifurcación pasado dicho bloque.

62 Versión 0.9.8e

20 de Abril de 2014

  • Esta versión es sólo para la red de pruebas. Causará otro 'reset' en la red de pruebas, de modo que requiere actualizar todos los nodos.
  • Cambiado al uso del hash completo de 256-bit para IDs de transacción de referencia. El cambio completo hacia el uso del hash completo sólo se implementará tras NQT_BLOCK, pero como vuelve a necesitar un 'hard fork', el cambio en el formato de los bytes de transacción está programado que se produzca en NQT_BLOCK.
  • La primera ejecución realizará algunas nuevas actualizaciones en la organización de la base de datos, y borrará los bloques en la red de pruebas tras el número 63000. NQT_BLOCK quedará definido como 76000 en la red de pruebas, de modo que tenemos una última oportunidad de probar las cantidades no fraccionarias y los cambios en las actuales referencias de transacción antes y después de NQT_BLOCK. El leasing de saldo será ahora habilitado en la red de pruebas en el bloque 75000. Tras el reset, la red de pruebas arrancará desde el bloque 74590, de modo que tenemos unos 1000 bloques antes de NQT_BLOCK en la red de pruebas.
  • El fullHash de transacción, que incluye la firma a diferencia del otro hash que tenemos actualmente, también está ahora disponible en el JSON de transacción. También es posible obtener una transacción en base a su fullHash utilizando getTransaction.
  • El parámetro de la http API referencedTransactionId ha sido sustituido por referencedTransactionFullHash, un hash completo de 256 bits codificado en hexadecimal.
  • El JSON de transacción también incluye ahora referencedTransactionFullHash, si no está vacío, y por el momento también incluye referencedTransactionId. Hasta pasar NQT_BLOCK, los usuarios de esta API deberían revisar ambos, debido a que en transacciones anteriores a NQT_BLOCK no se puede garantizar que referencedTransactionFullHash vaya a estar disponible al no ser parte de la matriz de bytes del formato de transacción. Tras NQT_BLOCK, esto cambiará para incluir siempre referencedTransactionFullHash en el JSON (también para transacciones antiguas), y referencedTransactionId será eliminada.
  • Añadido nxt.usePeersDb a nxt-default.properties, activado por defecto. Esto sirve para deshabilitar el uso de direcciones de pares guardadas, solamente útil para hacer pruebas.

63 Versión 0.9.7

18 de Abril de 2014

  • Añadida la API parseTransaction, que a partir de los transactionBytes recupera la representación JSON de la transacción, incluyendo la variable booleana "verify" que comunica si la firma ha sido verificada correctamente. Ten en cuenta que la interpretación y la validación de los bytes depende de la altura del último bloque actual - de si es antes o después de NQT_BLOCK.
  • Para evitar depender de unos pocos nodos públicos controlados de forma centralizada, todos los pares conocidos se guardan ahora regularmente en la base de datos. Al crearla desde cero, la base de datos se siembra con 200-300 pares públicos incluidos en el código DbVersion. Después de eso, en cualquier momento que el nodo encuentre pares nuevos en la red los añadirá a la tabla de pares, y borrará aquellos que aparezcan en la lista negra o que resulten inaccesibles en su dirección anunciada.
    • Esta funcionalidad es opcional, y el parámetro nxt.savePeers puede definirse como 'false' en nxt.properties, para quienes no quieran dejar rastro en su disco duro de a qué pares se ha estado conectando su nodo, de cara a prevenir potenciales ataques de correlación de red.
    • Los parámetros nxt.wellKnownPeers y nxt.testnetPeers aún se utilizan, y los pares que contienen se añaden a la base de datos en el arranque.

64 Versión 0.9.6

17 de Abril de 2014

  • Valida que la cuenta recipiente en un leasing tenga clave pública definida antes de aceptar la transacción. Esta comprobación causará algo de reducción en la red de pruebas porque los bloques que contengan dichas transacciones de leasing serán borrados.
  • Optimizaciones en el leasing de saldo. Los valores negativos de saldo garantizado se reducen sólo a los cálculos internos, el saldo efectivo ya nunca es negativo. Otras mejoras y parches menores.
  • El leasing de saldo efectivo se activará en la red principal en el bloque 130000. Esto significa que todos los nodos deberían actualizarse a la versión 0.9.6 o superior antes de eso, o se producirán bifurcaciones. Tenemos hasta entonces para encontrar y arreglar cualquier error serio en el leasing de saldo. Y todos los clientes usados en la red principal deberían haber cambiado a manejar cantidades en NQT antes de eso, ya que la API 0.9 sólo acepta cantidades en NQT. El bloque concreto para la transición a NQT se decidirá luego.

65 Versión 0.9.5e

14 de Abril de 2014

  • Añadida la API http leaseBalance para permitir el leasing del saldo efectivo. El parámetro period, definido en número de bloques, determina la duración del leasing. El periodo mínimo es de 1440 bloques, el máximo es de 32767. El leasing comienza 1440 bloques después de que se emita la petición leaseBalance, no de forma inmediata. Si un leasing se encuentra en curso y se envía uno nuevo, el nuevo surtirá efecto una vez finalizado el actual, pero no antes de 1440 bloques contados desde el bloque corriente.
  • Durante un leasing, todo el saldo de la cuenta que hace el leasing, con al menos 1440 confirmaciones, se añade al saldo efectivo de la cuenta destino.
  • Las comisiones por forja solamente las obtiene la cuenta destino, y no hay ningún mecanismo en la cadena de bloques para asegurar que la cuenta destino distribuya esas comisiones obtenidas, de modo que depende de los propietarios del pool organizar y tramitar esa distribución.
  • La información sobre ambas partes del leasing aparecerá en el resultado JSON de la API getAccount.
  • Esta característica se activará en la red de pruebas en el bloque 73000 para poder probarla extensivamente.

66 Versión 0.9.4e

14 de Abril de 2014

  • Añadida las funcionalidades para la Tienda de Bienes Digitales, el Leasing de Saldo Efectivo y el Terminal Hub. Aún no están testeadas, carecen de API http, y en este momento están desactivadas incluso en la red de pruebas para que no interfieran con las pruebas del Intercambio de Valores.
  • Exige firmas canónicas y llaves públicas canónicas, después del bloque NQT_BLOCK.
  • Añadida la API http setAccountInfo, que usa una transacción de Información de la Cuenta para definir las propiedades de nombre y descripción de una cuenta. Si se definen estos campos, se devolverán como parte del JSON getAccount. La información de cuenta se activará en el bloque NQT_BLOCK, así que debería funcionar en la red de pruebas desde esta versión.
  • Arreglado un error en el manejo de cantidades en la Transferencia de Valores que impedía la confirmación de transacciones en la red de pruebas.
  • Dos propiedades nuevas en in nxt-default.properties, para simplificar la importación de nxt.trace como archivo csv:
    1. Carácter separador para el registro trace
      • nxt.debugTraceSeparator=\t
    2. Carácter de Cita en el registro trace
      • nxt.debugTraceQuote="
  • Jetty se ha actualizado a la versión 9.1.4, y H2 a la versión 1.3.176. Asegúrate de borrar primero las versiones antiguas de la carpeta lib, si actualizas descomprimiendo el archivo zip encima de una instalación existente.
  • Arreglo de errores y mejoras en la validación de transacciones. Las transacciones existentes serán revisadas una vez en la primera ejecución de esta versión, lo que podría causar turbulencias en la red de pruebas ya que los bloques inválidos serán borrados.

67 Versión 0.9.3.1e

9 de Abril de 2014

  • Arreglado el procesamiento de las transacciones de Emisión de Valores. Los nodos de la red de pruebas deberían actualizar.

68 Versión 0.9.3e

7 de Abril de 2014

  • Eliminados los valores de retorno quantityINT, balanceINT, amountNXT, priceNXT, feeNXT en la API de JSON, y eliminado el soporte para procesar parámetros INT y NXT. Ahora solamente NQT (para importes) and QNT (para cantidades) son soportados como unidades.
  • Habilitada la ejecución en la red principal. El bloque NQT_BLOCK se ha definido como 150000 para la red principal, y hasta entonces las cantidades fraccionarias están deshabilitadas. Las tarifas y cantidades enteras de NXT también deberían funcionar con normalidad en la red principal, y esta versión debería ser compatible con los pares ejecutando 0.8.13. NOTA: pares ejecutando 0.7.* ya no están soportados. Todos deberían actualizar a 0.8.13 como versión estable, y estar preparados para actualizar a la rama 0.9 cuando sea declarada estable.
  • Como la interfaz de usuario java NRS dejará de ser soportadam y nadie tiene tiempo para convertirla al uso de la librería javascript BigInteger, aún acepta cantidades y tarifas en NXT, que serán convertidas a NQT por el servidor. Los valores de retorno están en NQT, y pueden resultar en un overflow en javascript para cantidades mayores de 2^53 NQT (unos 90 millones de NXT). Este problema sólo debería afectar a la interfaz de usuario, las entradas se manejan como cadenas de caracteres y convertidas a entero largo en el servidor. En cualquier caso, para transacciones de ese tamaño, mejor quedarse en la rama estable 0.8.13 o usar un cliente distinto.
  • En su primera ejecución en la red principal, al igual que ocurrió en la red de pruebas, el código de versión de la base de datos convertirá a NQT las columnas de cantidad y tarifa en las tablas de bloques y transacciones, lo que podría llevar algo de tiempo. Durante ese proceso, el tamaño de la base de datos crecerá mucho de forma temporal, hasta alrededor de 1 GB. Volverá a encoger al cerrar el servidor (lo que volverá a llevar algo de tiempo) hasta unos 180 MB.

69 Versión 0.9.2e

6 de Abril de 2014

  • Cantidades de valores fraccionarias. Disfrutad el nuevo reset de la red de pruebas.
  • Al emitir un valor, se puede especificar el número máximo de dígitos permitido tras el punto decimal en la cantidad del valor (valores permitidos de 0 a 8). Por ejemplo, esto sería 2 para una divisa como EUR, o 8 para Bitcoin.
  • Al igual que los precios, las cantidades de valores se pueden especificar como quantityQNT, expresado en la unidad de cantidad más pequeña posible ("quant") para un valor específico, o como quantityINT, expresado en unidades del valor completo (que pueden no obstante incluir una parte fraccionaria a pesar del nombre). Por ejemplo, 9.97 USD se pueden expresar como quantityINT="9.97", o quantityQNT="997", suponiendo que en el caso de USD decimales=2.
  • Las respuestas JSON que contienen cantidades o saldos de valores se devuelven tanto en quantityINT como en quantityQNT, en forma de cadena.
  • Al colocar una orden de oferta o demanda, si se especifica quantityQNT, el precio es interpretado para aplicarse a las unidades de cantidad QNT (al margen de si el precio en sí se especificó en NXT o en NQT). Si se especifica quantityINT, se entiende que el precio se aplica a las unidades de cantidad INT. Por ejemplo, una orden de oferta para quantityQNT="300", priceNXT="2", para el valor USD se interpretará como $3.00 a 1 centavo = 2 NXT, esto es 200 NXT por un dólar, 600 NXT en total. Si los parámetros se envían como quantityINT="7", priceNXT="50", la orden será de $7.00 a 50 NXT por dólar, 350 NXT en total.
  • Internamente, la verificación y seguimiento de órdenes y saldos de valores se realiza siempre en quantityQNT. Por ahora, un desafortunado efecto secundario es que al colocar una orden usando quantityINT, el precio calculado en NQT para una unidad QNT debe ser un entero. De modo que no puedes colocar una orden de quantityINT="1", priceNXT="10.12345678" (o de forma equivalente, priceNQT="1012345678"), porque entonces el precio de un quantityQNT será 10123456.78 NQT. PriceNXT tendrá que ser 10.12345600 o bien 10.12345700. Si esto resulta confuso, especifica la orden como quantityQNT="100", priceNQT="10123456".

70 Versión 0.9.1e

3 de Abril de 2014

  • Siempre devuelve cantidades tanto en NXT como en NQT, representadas en JSON como cadenas.
  • Reestructurado el código de generación JSON, elimiado getJSONObject de Block y Transaction.
  • Las transacciones que hagan fallar a la generación de un bloque serán siempre eliminadas del pool de transacciones sin confirmar.
  • Arreglado overflow en el cálculo de peso de los sellos de calidad.
  • Arreglado un error en la verificación JSON de las transacciones.
  • Todos los nodos de red de pruebas deberían actualizar a esta versión.

71 Versión 0.9.0e

3 de Abril de 2014

  • Esta es una versión experimental de prueba, que solamente correrá en la red de pruebas. Rechazará ejecutarse en la red real, así que no lo probéis. No obstante, todos los nodos de red de pruebas deberían actualizar a 0.9.0e para que podamos comenzar a probar transacciones con cantidades de NXT fraccionarias.
  • Todas las cantidades de transacción y las tarifas comenzarán a manejarse en NQT, 10^-8 NXT, empezando en el NQT_BLOCK, que en la red de pruebas se define en la altura 63000. Cuando hagamos la transición a la red real, se realizará en varios pasos, para preservar la compatibilidad con versiones anteriores, y por supuesto para no resetear la cadena de bloques principal. Esto también debería probarse primero en red de pruebas, así que esperamos como mínimo un reset adicional de la red de pruebas más adelante. Pero para esta versión para testnet, los valores existentes volverán a ser borrados, la cadena de bloques reseteada al bloque 63000, y las cantidades fraccionarias y el intercambio de valores activados de forma inmediata en el bloque 63000.
  • Detalles de implementación:
    • Internamente, todas las cantidades se manejan en NQT, usando números largos Java (64-bit). Las columnas cantidad y tarifa de la base de datos también serán convertidas a NQT y almacenadas como BIGINT. Este cambio es tanto para transacciones antiguas (antes del NQT_BLOCK) como nuevas. Sólo al verificar las firmas, los bloques y transacciones antiguos se representan en bytes usando int (32-bit) en lugar de cantidades y tarifas largas. Para compatibilidad entre pares, la JSON de transacción para las transacciones antiguas contendrá cantidades tanto en NQT como en NXT. Para prevenir overflows, todas las sumas y multiplicaciones de enteros largos se realizan usando métodos de prueba de pre-condición, Convert.safeAdd y Convert.safeMultiply, que revisan la posibilidad de overflow antes de ejecutar la operación.
    • Todas las APIs Java relevantes han sido renombradas para indicar que el valor devuelto es en NQT, excepto en el caso de getEffectiveBalanceNXT que solamente se utiliza al forjar y allí se necesita en NXT.
    • La API http se ha cambiado para aceptar cantidades tanto en NQT como en NXT, con las cantidades fraccionarias recibidas como cadena en los parámetros de la petición http y entonces traducidas directamente a números largos. Los objetos JSON devueltos solamente utilizan NQT. Todos los nombres de parámetro http y JSON relevantes se han cambiado para indicar si son en NQT o NXT.
    • Los precios de los valores también se cambian para usar NQT, en lugar de céntimos de NXT. Pero no he probado las transacciones de intercambio de activos en absoluto, solamente he probado transacciones de dinero simples, así que cabe esperar errores.
    • Las cantidades de activo fraccionarias aún no están implementadas.

72 Versión 0.8.13

1 de Abril de 2014

  • Previene los hash de transacciones duplicados en el pool de transacciones sin confirmar.
  • Añadido un campo de comentarios al tipo de transacción Asset Transfer, de hasta 1000 caracteres. Esto forzará el borrado de todos los bloques en la red de pruebas comenzando en el primero que contenga una transacción de envío de valores, tan pronto como esta versión sea ejecutada.
  • Añadido un filtro opcional por cuenta a la API getUnconfirmedTransactions.
  • Añadida la petición API getAllOpenOrders.
  • Añadidos a Account 'AccountAsset Listeners', para recibir notificaciones de los cambios en el saldo de valores especificando el valor cuyo saldo ha cambiado.
  • Devuelve un error al intentar transmitir una transacción con fondos insuficientes, y no intenta volver a transmitir dichas transacciones.
  • Mejoras a las funcionalidades DebugTrace y VerifyTrace.
  • Jetty actualizado a la versión 9.1.3.

73 Versión 0.8.12

21 de Marzo de 2014

  • Esta versión es solamente para pruebas y depuración de errores. No es necesario actualizar si no estás interesado en hacer pruebas.
  • Añadido DebugTrace.java, que escucha a cualquier cambio en el saldo de la cuenta o los saldos de activos, y a todos los eventos que causan dichos cambios - transacciones, tarifas por generar un bloque, emisión de órdenes, emisión de activos, transferencia de activos, cancelación de órdenesa intercambio.
  • Esta función utiliza dos propiedades nuevas en nxt-default.properties:
    • nxt.debugTraceLog=nxt.trace
    • nxt.debugTraceAccounts=
  • Para permitir el seguimiento del saldo de una cuenta, define nxt.debugTraceAccounts como una lista de id's de cuenta a rastrear, separadas por "; " . El resultado será guardado en nxt.trace, o el archivo definido en nxt.debugTraceLog. Los valores en este archivo están separados por tabulador, para hcer fácil su exportación a una aplicación de hoja de cálculo.
  • Se puede habilitar el rastreo de todos los saldos de cuenta existentes, definiendo nxt.debugTraceAccount=* .
  • En el reinicio, y en los re-escaneos, el registro de nxt.trace será sobreescribido.
  • Añadido VerifyTrace.java, que puede buscar en el archivo nxt.trace (o un archivo especificado como parámetro en la línea de comando), y realizar ciertas verificaciones. Actualmente, verifica que para cada cuenta rastreada el saldo final coincida con el total de todos los cambios que han afectado a esa cuenta, según lo registrado en el registro de nxt.trace También verifica que, para cada activo, el total de las cantidades de activos en todas las cuentas coincida con la cantidad original emitida de ese activo. Esta verificación fallará si no se incluye a todas las cuentas que poseen un activo en debugTraceAccounts.
  • Para ejecutar VerifyTrace, usa el script verify.sh. El servidor Nxt debería ser detenido primero, para que el registro de nxt.trace deje de ser actualizado mientras VerifyTrace lo verifica.
  • Los saldos sin confirmar y los saldos de activos sin confirmar son registrados, pero no verificados por VerifyTrace, porque la presencia de órdenes abiertas o parcialmente completadas puede volver el proceso demasiado complicado. Puede resultar más sencillo programar una aplicación de hoja de cálculo para incluir estos cálculos.
  • Añadido el evento TRADE, activado cuando ocurre un intercambio. Ten en cuenta que el evento Trade ocurre antes de la actualización de los saldos.
  • Añadidos los eventos BEFORE_BLOCK_APPLY y BEFORE_BLOCK_UNDO, activados justo antes de los operaciones correspondientes en el proceso de los bloques.

74 Versión 0.8.11

19 de Marzo de 2014

  • Permite nombres no únicos para valores.
  • Añadida la petición API getAssetsByName API para obtener un listado de todos los valores con el assetName proporcionado.
  • Añadida la petición API getAllTrades para obtener todos los intercambios a partir de una marca de tiempo dada (contribución de Antanst).
  • Mejoradas las respuestas JSON para varias peticiones API: getAsset también devuelve ahora numberOfTrades. getAccount también devuelve ahora unconfirmedBalance. broadcastTransaction también devuelve ahora el hash de la transacción. getAsk/BidOrder también devuelven ahora la altura de la orden. El rendimiento de getTrades debería haber mejorado mucho, y ahora también devuelve la id de bloque para cada intercambio.
  • Cierra de forma explícita todos los servidores jetty cuando se invoca Nxt.shutdown().
  • Insertado texto Escape en el campo software del par o dirección anunciada del par dentro del html del cliente NRS, para evitar scripts cruzados entre sitios y otros ataques maliciosos similares.
  • Ahora que Crypto.sign() ya no produce firmas erróneas, ya no hay necesidad de llamadas adicionales para verificar() tras el signo del bloque, o para múltiples intentos de firmar una transacción.

75 Versión 0.8.10

15 de Marzo de 2014

  • Mejorada la validación al adjuntar transacciones. Los bloques que se aceptaron de forma incorrecta y luego no pudieron ser procesados por alguna razón serán borrados de la base de datos.
  • Mejorada la validación de la tarifa mínima para distintos tipos de transacción.
  • La llamada API GetAccount también devolverá saldos no confirmados de valores.
  • BroadcastTransaction verifica ahora la firma de los bytes de transacción recibidos antes de transmitir la transacción.
  • Eliminado el código de forja que ya no se utiliza. Generar bloques bajo la altura 30000 (fase 1 de la forja transparente) ya no está soportado.
  • Db.getConnection() se ha hecho pública y se han añadido los métodos Blockchain.getBlocks y getTransactions aceptando PreparedStatement como parámetro, para su uso por los clientes API Java.
  • Añadido un APITestServlet para la depuración manual y pruebas en la API. Todas las llamadas API http se listarán ahora automáticamente bajo http://localhost:7876/test o si solamente necesitas probar una llamada específica, p.ej. getBalance: http://localhost:7876/test?requestType=getBalance
    • A diferencia de la página admin.html, este listado se genera de forma automática e incluirá todas las llamadas API disponibles sin que sea necesario actualizarlo manualmente cuando se añade una nueva llamada.
  • Aplicado el parche a Curve25519.sign() sugerido por DoctorEvil. La firma de bloques y transacciones ya no debería fallar en la verificación.

76 Versión 0.8.9

13 de Marzo de 2014

  • Soporte para la firma de transacciones por parte del cliente. Todas las peticiones http API que crean una nueva transacción aceptan ahora los parámetros secretPhrase o publicKey. Si se proporciona secretPhrase, se crea la transacción, se firma en el servidor y éste la transmite como de costumbre. Si en lugar de secretPhrase se proporciona el parámetro publicKey, como tabla de bytes en hexadecimal, el servidor preparará la transacción y la devolverá en la respuesta JSON en forma de transactionBytes. Esta tabla de bytes puede ser ahora firmada por el cliente, y entonces devuelta al servidor para su transmisión usando la API broadcastTransaction.
  • Los hashes de una transacción, que se pueden utilizar para identificar transacciones de forma única para evitar ataques de maleabilidad en la firma de las transacciones, se pueden obtener ahora mediante Transaction.getHash(), y también están disponibles en la representación JSON de las transacciones. El hash también se puede usar para recuperar una transacción del servidor, en lugar de utilizar la id de transacción, suministrando un hash como parámetro a la petición http API getTransaction en lugar del número de transacción.
  • Para mejorar el rendimiento, se han añadido los métodos Java API getBlockId y getBlockTimestamp a la clase de Transacciones, para evitar la necesidad de solicitar getBlock lo que puede necesitar consultas adicionales a la base de datos. Los clientes Java deberían usar estos métodos en lugar de getBlock. De forma similar, el campo blockTimestamp ha sido añadido al JSON devuelto por getTransaction y otras llamadas API que devuelven un JSON de transacción, de modo que los clientes http también pueden evitar llamadas innecesarias a getBlock.
  • Al actualizar a 0.8.9 se modificará la base de datos para agregar las columnas hash y block_timestamp a la tabla de transacciones.
  • Las transacciones que han resultado inválidas serán eliminadas del pool de re-transmisión.
  • Movidas todas las constantes globales a Constants.java.
  • Mejorada la validación de transacciones para la transacciones de Emisión de Valores para evitar errores engañosos de transacción inválida.
  • Corregida la gestión de transacciones con marcas de tiempo idénticas en la generación de bloques y en la IU del cliente NRS.
  • Añadidos los eventos ASSET_BALANCE y UNCONFIRMED_ASSET_BALANCE a la cuenta, arreglado un prosible problema con el cálculo del saldo de valores.

77 Versiones 0.8.8 / 0.7.7

7 de Marzo de 2014

  • Arreglado un detalle de configuración incorrecto en la marca de tiempo del bloque génesis cuando el tiempo local está definido dentro del horario de verano. Esta debe haber sido la razón por la que algunos usuarios en el hemisferio sur no podían forjar.
  • Como el horario de verano empieza el 9 de Marzo en los Estados Unidos, es crítico que por lo menos aquellos en EEUU actualicen a 0.8.8 o 0.7.7.
  • No hay otros parches o nuevas funciones en 0.7.7, en relación a 0.7.6, al margen de este arreglo relativo al horario de verano.

78 Versión 0.8.7

6 de Marzo de 2014

  • Arreglados los cálculos del saldo sin confirmar para la cuenta del bloque génesis.
  • Arreglada la visualización del saldo de la cuenta génesis en la IU de NRS.

79 Versión 0.8.6

5 de Marzo de 2014

  • La re-transmisión de transacciones no funcionaba bien en algunas versiones anteriores, ahora debería volver a funcionar.
  • Arreglada la actualización del número de confirmaciones de las transacciones en la IU de NRS.
  • Revisa si una transacción sin confirmar se ha vuelto inválida, y de ser así, la elimina del pool de transacciones sin confirmar.
  • Añadidos algunos pares conocidos más para la red de pruebas en las propiedades por defecto.
  • Convertido run.bat al formato de salto de línea CRLF.
  • Arreglos específicos para el Intercambio de Valores:
    • Las cancelaciones de una orden solamente deberían actualizar el saldo sin confirmar.
    • Al rechazar un bloque, los saldos de valores no deberían actualizarse.
    • Cuando se ejecuta un intercambio a un precio menor que la demanda, la diferencia se corrige en el saldo sin confirmar del demandante.

80 Versión 0.8.5

4 de Marzo de 2014

  • Más arreglos relacionados con el cálculo del saldo sin confirmar.
  • Arreglos menores para evitar algunos errores inofensivos.

81 Versión 0.8.4e

3 de Marzo de 2014

  • Varios cambios en el cálculo del saldo sin confirmar y el saldo de activos sin confirmar. Esto es un intento de solucionar el problema de saldo sin confirmar en negativo y el error "Not enough funds", pero no ha sido probado, de ahí que esta versión sea experimental.
  • Habilitado el uso de red de pruebas simplemente definiendo la propiedad nxt.isTestnet en nxt.properties. No son necesarios otros cambios.
  • Al cambiar a red de pruebas definiendo nxt.isTestnet=true, el puerto de pares pasa a ser 6874, el puerto de la IU 6875, y el puerto servidor de API 6876. Estos valores están fijados para evitar errores y tienen prioridad sobre cualquier otro valor personalizado para los puertos en nxt.properties. Además, cuando NO se utiliza la red de pruebas, el servidor no se ejecutará si el puerto de pares está definido como 6874, de nuevo para prevenir un cruce accidental de las cadenas de bloques real y de pruebas.
  • Para la red de pruebas, se creará automáticamente un subdirectorio nuevo para la cadena de bloques de pruebas, nxt_test_db.
  • Debes definir nxt.testnetPeers como una lista de nodos públicos de pruebas conocidos. He definido bug.airdns.org con el código 0.8.4e, y una copia de la cadena de bloques de pruebas, según la obtenido desde holms. Espero que otros usuarios instalen nodos de pruebas y los anuncien en el foro.
  • En esta versión, al cambiar a la red de pruebas, las funciones de Votación e Intercambio de Activos están habilitadas de forma automática. En la red real seguirán deshabilitadas. La IU del cliente NRS no soporta aún estas funcionalidades, de modo que deberías usar una IU distinta, o usar directamente la API http.
  • Añadido el parámetro nxt.knownBlacklistedPeers, para añadir pares manualmente a la lista negra en el archivo nxt.properties.
  • Ya no se sobreescribe la dirección de los pares con su dirección anunciada en el panel de pares activos, se usa solamente la IP para identificar de forma única a cada par.
  • Permite desactivar el DoSFilter para el servidor de la red de pares. Añadido el parámetro nxt.peerServerDoSFilter.maxRequestMs=300000, porque el valor por defecto para maxRequestMs en DosFilter fuerza el cierre de peticiones que tarden más de 30 s, lo que interrumpe las descargas de la cadena de bloques en los pares lentos. Es muy probable que ésta haya sido la causa de los errores de Jetty que aparecían en los días de la versión 0.5.x.
  • Añadido el método Generator.getAccount, y los eventos START_FORGING y STOP_FORGING, de interés para los clientes de API Java.
  • Añadido el script run.bat para los usuarios de Windows.
  • El código fuente se incluye ahora en el paquete dentro del directorio src. Los scripts compile.sh y javadoc.sh se pueden utilizar para compilar el código, y regenerar nxt.jar y la documentación javadoc.

82 Versión 0.8.3

26 de Febrero de 2014

  • Arreglados problemas en la IU al mostrar Mis Transacciones y su actualización. Cuenta consistente de las confirmaciones de transacción. Se considera que las transacciones incluidas en el último bloque tienen 0 confirmaciones.
  • Al empujar un bloque, el evento BLOCK_PUSHED se emite ahora antes de los eventos REMOVED_UNCONFIRMED_TRANSACTIONS y ADDED_CONFIRMED_TRANSACTIONS.
  • Añadidos los eventos BlockchainProcessor.RESCAN_BEGIN y RESCAN_END, activados antes y después de un re-escaneo (no durante el re-escaneo habitual de arranque).
  • Arreglados algunos punteros vacíos causados por mala información de los pares.
  • Mejorada la festión de las direcciones de pares y los sellos de calidad.
  • Añadido el estado 'blacklisted' a la información de pares.

83 Versión 0.8.2e

25 de Febrero de 2014

  • Principalmente, arreglos menores a problemas reportados con la versión 0.8.1e.
  • Arreglada la cadena 'hallmark' en la información json de los pares.
  • Mejorado el registro, añadidos métodos removeListener.
  • A la hora de enviar peticiones POST usando XMLHttpRequest, no definir cabeceras de longitud de contenidos.
  • Añadido el jar jetty-security.
  • worker_sha256.js movido a tools.
  • Se añaden nodos aleatorios de mynxt.info al valor por defecto de wellKnownPeers.

84 Version 0.8.2e

February 25, 2014

  • Mostly minor fixes for problems reported with 0.8.1e.
  • Fixed hallmark string in json peer info.
  • Improved Logger, added removeListener methods.
  • Don't set Content-length headers when using XMLHttpRequest to send POST requests.
  • Added jetty-security jar.
  • Moved worker_sha256.js to tools.
  • Also add random mynxt.info nodes to default wellKnownPeers.

85 Versión 0.8.1e

24 de Febrero de 2014

  • Gestión mejorada de las direcciones y puertos anunciados por los pares. Definir nxt.myAddress es ahora opcional, lo que será de ayuda a los usuarios con direcciones IP dinámicas. Al conectar con un par, mientras nxt.shareMyAddress esté habilitado, intentará conectar más adelante con tu dirección anunciada, y de no estar definida, a la dirección de la que provino tu petición. Si tiene éxito, el par usará esta dirección para conectar contigo en el futuro y la compartirá con otros.

Esto también se encarga de la verificación de direcciones anunciadas, y considera a tu nodo como conectado sólo después de establecer con éxito una conexión a la dirección anunciada. Esto prevendrá que direcciones anunciadas inválidas sean comunicadas a otros pares.

  • Si necesitas usar un puerto distinto al puerto por defecto, debe ser anexado también a tu dirección anunciada. No tiene por qué ser el mismo que nxt.myPeerServerPort, de modo que puedes ejecutar el servidor en un puerto pero dirigir hacia él un puerto distinto en el router. Sin embargo, si el puerto no queda definido en la dirección anunciada, pero nxt.myPeerServerPort contiene un valor distinto al valor por defecto, nxt.myPeerServerPort será automáticamente anexado a la dirección anunciada.
  • En resumen: Los usuarios con IP dinámica no necesitan poner nada en nxt.myAddress, pero aún deben redirigir el puerto en su router.
  • La verification de los sellos de calidad (hallmarks) ha sido mejorada para intentar resolver los nombres de host como direcciones IP. Ten en cuenta que si usas un puerto distinto del valor por defecto, el sello de calidad debería incluir solamente tu dirección, sin el puerto.
  • Añadida la petición API generateToken. Los parámetros son secretPhrase y sitio web, la respuesta es la cadena del token empaquetada en JSON. Esto también está disponible en la página admin.html.
  • Mejorada la gestión del arranque y el cierre. Nxt.shutdown() es ahora pública y los desarrolladores de clientes pueden utilizarla. Cuando Nxt arranca como aplicación independiente al invocar main(), programará un gancho de cierre. Si se ejecuta usando init(), quien invoca init() es responsable de invocar shutdown() o programar un gancho de cierre.
  • Retrasado el inicio del escaneo de la cadena de bloques y los servlets jetty hasta que se ha completado la inicialización de todas las clases. Esto debería permitir registrar con ellos listeners, y ayudará a prevenir errores debidos a servlets que comienzan a aceptar peticiones antes de que el sistema se haya inicializado por completo.
  • Si no se encuentra nxt-default.properties en el classpath, Nxt también intentará cargarlo desde el archivo definido en las propiedades de sistema como nxt-default.properties, de modo que puedes definirlo desde la línea de comandos: java -Dnxt-default.properties=conf/nxt-default.properties. Esto es solamente de interés para los programadores de clientes.
  • Soportado el uso de POST además de GET en todas las peticiones HTTP API y de la IU. Para forzar el uso de POST solamente, en aquellas peticiones que requieren la contraseña secreta del usuario, se pueden definir en nxt.properties nxt.apiServerEnforcePOST y nxt.uiServerEnforcePOST (el valor por defecto es falso para la API, y verdadero para la IU). De este modo los programadores de clientes pueden forzar que solamente se utilicen peticiones POST a la hora de manejar datos delicados.
  • La IU por defecto a través de navegador NRS ha sido modificada para que utilice solamente POST, al igual que las herramientas - admin.html, message.html, alias.html. Así, la contraseña secreta del usuario ya no será almacenada en la memoria caché del navegador.

86 Versión 0.8.0e

22 de Febrero de 2014

  • Esta versión presenta un cambio importante en la arquitectura del servidor Nxt. En lugar de un servlet ejecutado por Jetty, ahora Nxt es una aplicación independiente que lanza servlets Jetty por sí misma cuando son necesarios. Esto debería facilitar su uso como librería Java, al no necesitar ya ser ejecutada dentro de un contenedor de servlets.
  • La configuración de Nxt es ahora más flexible, tanto para el usuario como para los programadores de aplicaciones. Nxt ya no usa web.xml, ni ningún otro archivo xml. En su lugar, se utiliza un archivo de propiedades más accesible.
  • La composición de la distribución se ha cambiado y simplificado. Al descomprimir el archivo zip aparece la siguiente estructura de directorios:
    • nxt/conf/
      • Aquí es donde se guardan los archivos de configuración. Todas las propiedades por defecto están en in conf/nxt-default.properties. Nunca deberías editar este archivo, salvo que estés preparando un paquete o desarrollando un cliente que requiere valores por defecto distintos en su distribución. Todos los valores por defecto son razonables, de modo que se puede ejecutar Nxt sin ninguna configración. Si por cualquier motivo el usuario quiere personalizar parámetros, la forma de hacerlo es crear otro archivo de propiedades, conf/nxt.properties, que contenga SOLAMENTE las propiedades que deban ser distintas al valor por defecto. Nxt leerá tanto nxt-default.properties como nxt.properties, y los valores en nxt.properties tendrán preferencia sobre los valores en nxt-default.properties.
    • nxt/html/
      • Contiene los archivos html necesarios para el cliente javascript NRS dentro de html/nrs, las herramientas basadas en html como admin.html y update.html dentro de html/tools, y la documentación javadoc para la API Java dentro de html/doc.
    • nxt/lib/
      • Aquí están todas las librerías Java necesarias - Jetty, H2 database, y la librería JSON-simple. Todas las librerías Jetty que Nxt no utiliza ya no están incluídas, lo que ayuda a reducir el tamaño del paquete distribuido.
    • nxt/nxt.jar
      • Este jar contiene todas las clases Nxt compiladas.
    • nxt/run.sh
      • Este script es la forma más sencilla de iniciar Nxt, bajo Linux:

        java -Xmx1024M -cp nxt.jar:lib/*:conf nxt.Nxt

        Como ves, el classpath necesita incluir nxt.jar, todos los jars dentro de lib, y el directorio conf.
  • Desapariciones notables incluyen start.jar, webapps, y los directorios de configuración Jetty, que ya no son necesarios.
  • Además del cambio a Jetty integrado, se han realizado reestructuraciones significativas en el código, lo que puede interesar a los usuarios de la API Java. Los cambios son demasiados para describirlos aquí, pero puedes hacerte una idea comparando el javadoc de 0.8.0 con el de la rama 0.7. Lo más notable es que se han definido interfaces para las clases de bloques y transacciones, la clase Blockchain se ha dividido en varias, y se ha hecho limpieza en las clases de Pares y Usuarios.
  • Los programadores de Clientes que utilicen la API Java pueden pasar por encima de las propiedades por defecto enviando un objeto Properties personalizado a Nxt.init().
  • Las propiedades configurables en nxt-default.properties están todas documentadas en el mismo archivo. Algunos detalles adicionales sobre ellas:
  • Nxt se iniciará con hasta tres servidores Jetty distintos, si es necesario.
  • El servidor de la red de pares acepta peticiones http de otros pares. Sólo se inicia si nxt.shareMyAddress=true (valor por defecto). Si estás tras un cortafuegos y tu IP no es visible externamente, puedes definirlo como 'false' para deshabilitarlo.
  • El puerto y la interfaz de host del servidor de pares se pueden configurar. Si defines un puerto distinto al valor por defecto en nxt.peerServerPort, será anexado a la dirección que anuncies a los pares (esta dirección debería definirse en nxt.myAddress). Aunque no se han hecho muchas pruebas usando puerto de red personalizado para los pares.
  • En equipos con múltiples interfaces de red, ahora se puede especificar a qué interfaz enlazar cada servidor. Por defecto, nxt.peerServerHost=0.0.0.0 para que el servidor de la red de pares escuche en todas las interfaces.
  • No hay pares definidos en nxt.wellKnownPeers en los archivos de propiedades por defecto. Deberías definir tus pares preferidos en nxt.properties. Sin embargo, si no se define ninguno se empleará una selección aleatoria de nodos públicos en nxtcrypto.org y nxtbase.com.
  • El filtro DoS sólo está habilitado en el servidor de pares.
  • El servidor API acepta peticiones API http/json. Por defecto, ahora se ejecuta a través del puerto 7876, y escucha sólo a través del interfaz local 127.0.0.1. Si ejecutas un nodo público y deseas aceptar peticiones API de cualquiera, define nxt.apiServerHost como 0.0.0.0, y nxt.allowedBotHosts como * (o en blanco).
  • Nxt.apiResourceBase apunta hacia un directorio de archivos html estáticos vacíos que también maneja el servidor API. Los programadores de clientes que utilicen la API http/json desearán personalizarlo para apuntar hacia los archivos html y javascript de su cliente.
  • El Jetty Cross Origin Filter se puede habilitar en el servidor API definiendo nxt.apiServerCORS=true (por defecto deshabilitado).
  • El servidor de la IU se usa para la IU del cliente javascript NRS. Por defecto se ejecuta en el puerto 7875 y sólo acepta peticiones de localhost. Los programadores de clientes que utilicen las mismas llamadas API que el cliente NRS (no las http/json) deberían personalizar nxt.uiResourceBase para que apunte hacia los archivos html y javascript de su cliente.
  • SSL puede ser habilitada tanto en el servidor API como el servidor de la IU (deshabilitada por defecto). Si se hace esto, los puertos correspondientes solamente aceptarán peticiones http. Ahora mismo no es posible soportar http y https a la vez, pero ésto se puede agregar. Simplemente no lo vi necesario. Si habilitas SSL, debes definir nxt.keyStorePath y nxt.keyStorePassword, y obviamente necesitas tu propio certificado SSL (firmado por tí mismo o por una autoridad) en un archivo de llave. Sólo lo he probado con un certificado firmado por mí mismo.
  • Los programadores de clientes que usen la API Java tal vez quieran deshabilitar tanto el servidor API como el servidor IU, y los usuarios sin una IP visible incluso el servidor de pares.
  • La salida de depuración está ahora desactivada por defecto, pero se puede activar definiendo nxt.debug=true. Los errores en la pila aún se registrarán, en tanto nxt.enableStackTraces=true. Espero que no haya ninguno.
  • La conexión a la base de datos se puede personalizar por completo, ya que la url jdbc completa que se utiliza para conectar a ella está visible en el archivo de propiedades y se puede modificar. Los programadores de clientes que insistan en ser capaces de acceder a la base de datos desde otro proceso separado, mientras se ejecuta Nxt, pueden conseguirlo agregando ;AUTO_SERVER=TRUE a la url jdbc, lo que permitirá modo mixto automático. Esto está desactivado por defecto, pero si lo activas y escribes en la base de datos mientras Nxt está ejecutándose, espera desperfectos.
  • También es posible tener la base de datos en otro lugar, y no sólo en el directorio de trabajo, si cambias la url jdbc adecuadamente.
  • Para cambiar la cantidad de memoria usada por el caché de la base de datos, utilizau el parámetro nxt.dbCacheKB, en kilobytes. Si está a 0, por defecto el 50 % de la memoria disponible para la máquina virtual de Java se usará para el caché de la base de datos.
  • No ha habido cambios en la organización de la base de datos, deberías usar tu carpeta nxt_db existente también con esta versión, en lugar de descargar la cadena de bloques desde cero.
  • Esta versión se marca como experimental, pero por favor pruébala. En particular, los programadores de clientes deberían probarla bien, y si no hay problemas significativos, la rama 0.7 estará obsoleta pronto.

87 Versión 0.7.6

19 de Febrero de 2014

  • Compactado de la base de datos en cada cierre. Esto debería ayudar a reducir el tamaño del directorio nxt_db tras la primera ejecución, comprueba el espacio usado en disco antes y después.
  • Prevenido el listado de pares por duplicado en las ventanas de pares conocidos y pares en la lista negra.
  • Prevenido un potencial ataque con llave de cuenta duplicada, del tipo descrito aquí: https://bitcointalk.org/index.php?topic=397183.msg4569817#msg4569817
  • Añadido sistema de votaciones, aún no habilitado.
  • Un poco de reestructuración de las clases relativas a bloques y transacciones.
  • Arreglo de errores en el intercambio de activos a partir de la red de pruebas, y más peticiones API.
  • Mejorada la validación de transacciones para prevenir la adición errónea de pares a la lista negra, y para controlar mejor la validez de cada transacción.

88 Versión 0.7.5

14 de Febrero de 2014

  • Varias mejores en el rendimiento y el uso de memoria.
  • Mejorada la validación de las direcciones de pares y el manejo de los cambios de estado de la conexión de los pares.
  • Mejoras en el interfaz de usuario relativas a la visualización de los pares.
  • Optimizaciones adicionales en getMilestoneBlockIds, con compatibilidad retroactiva.
  • Más limpieza de las clases del núcleo de nxt en todos los parámetros relacionados con la IU.

89 Versión 0.7.4

13 de Febrero de 2014

  • Otro arreglo en la transición hacia Forja Transparente, comenzando en el bloque 67000. Actualiza antes de ese bloque, porque se producirá una bifurcación.
  • Esta versión abandona el soporte para el protocolo antiguo getMilestoneBlockIds. Clientes anteriores a 0.7.3 no podrán solicitar bloques a los nodos 0.7.4. En cualquier caso todos deben actualizar a 0.7.4, antes del bloque 67000.
  • Algunas optimizaciones en las peticiones a la base de datos durante el desbloqueo de cuenta, a ver si a los usuarios de Raspberry les sirven de ayuda.
  • Otras mejoras menores.

90 Versión 0.7.3

12 de Febrero de 2014

  • La serie 0.6.x ya no está soportada. Comenzando con esta versión, solo habrá desarrollo para la versión que utiliza base de datos.
  • Optimizado el protocolo getMilestoneBlockIds. Esta es la petición peer to peer que ahora mismo coloca la mayor carga en los nodos públicos, y es causa de una gran cantidad de tráfico de salida innecesario. Sin embargo, por razones de retro-compatibilidad, la versión 0.7.3 todavía soporta tanto el protocolo viejo como el protocolo getMilestoneBlockIds mejorado, de modo que cuando un cliente anterior conecte a nodos 0.7.3, desafortunadamente aún provocará una carga innecesaria y tráfico adicional.
  • AVISO: El soporte para el protocolo getMilestoneBlockIds antiguo desaparecerá en 0.7.4. No necesitas actualizar de forma inmediata, pero si no lo haces antes de que se publique la versión 0.7.4, tus nodos con versiones anteriores no podrán solicitar bloques y actualizarse en la cadena de bloques. Mejor actualizar pronto que tarde.
  • Más y más reestructuración. La lógica del interfaz de usuario y la de los procesos del núcleo están completamente separadas. Ya nada en el núcleo del paquete depende de las clases en el paquete nxt.user. En su lugar, se usa un marco de oyente, de forma que la IU puede solicitar ser notificada de los cambios en el núcleo sobre los que necesita estar informada. Esto también está dirigido a los desarrolladores de Java en el API del cliente.
  • Añadidos algunos índices más a las tablas de la base de datos para mejorar el rendimiento. Se crearán automáticamente la primera vez que arranques esta versión con tu base de datos existente - no hace falta comenzar desde cero, no hace falta borrar tu vieja carpeta nxt_db.
  • Cambio relativo a la privacidad: Antes de esta versión, los nuevos bloques generados y las nuevas transacciones se transmitían a los pares por duplicado. Esto podía permitirles deducir que era tu nodo el que había generado dichos bloques o transacciones. Ahora esto está solucionado. Ten en cuenta que alguien que sea capaz de espiar todo tu tráfico de internet aún podrá darse cuenta de que fuiste tú quien generó un bloque, porque el nodo generador manda el bloque antes de haberlo recibido de ningún otro par. Todavía no veo una forma físicamente posible de evitar eso. Ten también en cuenta que la función de re-transmisión de las transacciones seguirá re-transmitiendo tus transacciones hasta recibirlas de vuelta desde por lo menos otro nodo, pero no se comportará así con transacciones recibidas desde otros nodos. Esto aún se podría usar para deducir que tu nodo ha sido la fuente de una transacción, en el caso de que el intento inicial de enviarla fallase, y fuera re-transmitida (pero alguien hubiera sido testigo del primer intento fallido).
  • Separada la lógica de la forja de bloques a una clase 'Generator', que también pueden usar los clientes Java API para empezar y parar de forjar.
  • Añadidas las peticiones API startForging y stopForging. Parámetros: secretPhrase, necesaria tanto para empezar como para detener la forja.
  • Arreglados bugs menores. Arreglado un error en la supervisión del tráfico de descarga de los pares.

91 Versión 0.7.2

9 de Febrero de 2014

  • Mejoras en el rendimiento al escanear la cadena de bloques.

92 Versión 0.7.1 / 0.6.2

8 de Febrero de 2014

  • Arreglado un bug al calcular el saldo garantizado que en ciertos casos podría resultar en un saldo efectivo mayor que el saldo real. Como este cambio podría producir bifurcaciones, un cambio al cálculo correcto se activará en el bloque 640000. Todo el mundo debería actualizar a 0.7.1 o 0.6.2 antes de ese bloque, o veremos bifurcaciones.
  • Mejorada la validación de las direcciones de pares, para prevenir que direcciones sintácticamente incorrectas o irresolubles se incluyan en la lista de pares.
  • Habilitado el registro de todas las salidas de depuración a un archivo de registro. Todo lo que vaya a la consola será también registrado en el archivo nxt.log. Esto debería ayudar en el envío de informes de errores en caso de cuelgues y otros problemas, porque ya no pasa nada si tu ventana de comandos de windows desaparece. El archivo nxt.log se sobreescribe a cada reinicio del servidor.
  • Limpiado el procesamiento de tokens para autorización y sello de calidad. Añadidas categorías de Token y Sello de Calidad, que pueden ser usadas ahora por los programadores del cliente Java para generar y validar tokens y sellos de calidad sin pasar por la interfaz http.
  • Mejorado el registro de fallos al empujar bloques y otros eventos pop-off en los bloques, que ahora incluirá la id del bloque y la razón por la que ha sido rechazado.
  • Mejorada la lista negra de pares y el registro de motivos para su inclusión. Las peticiones http de pares en la lista negra son ahora ignoradas por completo.
  • Todas las categorías para manejar peticiones API son ahora visibles bajo el paquete nxt.http en la documentación javadoc, para documentar los parámetros y los valores devueltos en la API http.
  • No ha habido ningún error de base de datos en la serie 0.7. Todos los cambios anteriores se han aplicado tanto a la rama 0.6 como a la 0.7. Animo a los usuarios a que prueben la 0.7.1, no hay ninguna necesidad de seguir manteniendo la rama 0.6 más tiempo si no vemos problemas con la versión que utiliza base de datos.

93 Versión 0.7.0e

6 de Febrero de 2014

  • Esta es la primera versión que utiliza una base de datos java anexada (H2) para almacenar la cadena de bloques, en lugar de objetos java serializados. Debido a que éste es un cambio mayor, esta versión debe considerarse experimental.
  • Los archivos blocks.nxt y transactions.nxt y sus respectivos .bak ya no se utilizan. Lo que es más, ya no se cargarán en el inicio, y cuando arranques con una base de datos vacía por primera vez necesitará descargar la cadena de bloques completa desde la red.
  • La base de datos se almacena bajo el directorio nxt_db, y en este momento necesitará unos 100 MB de espacio al descargarse. Si algo sale mal y necesitas comenzar de cero, es seguro borrar ese directorio nxt_db, será creado de nuevo.
  • No hay cambios en el archivo web.xml comparado con la 0.6.1. Añadiré parámetros para ajustar la configuración de la base de datos más adelante, si son necesarios.
  • La base de datos utilizará para su caché el 50% de la memoria disponible para java. El valor real se muestra en el arranque.
  • En este momento, sólo los bloques y las transacciones se guardan en tablas de la base de datos. Todo lo demás incluyendo cuentas, alias, activos, peticiones y mensajes se carga al inicio y se mantiene en memoria. La cantidad de memoria que ocupan es aún pequeña, en relación a lo necesario para todos los bloques y transacciones..
  • En el inicio, el escaneado de la cadena de bloques lleva un poco más de tiempo, esto es normal. Si algo más aparece más lento de lo habitual, procederé a identificarlo y optimizarlo.
  • No hay nuevas funciones visibles para el usuario comparado con la 0.6.1, ahora el código está sincronizado (incluyendo los arreglos de errores críticos). Tener tanto nodos con la 0.6.1 como la 0.7.0e en la red no debería producir bifurcaciones. Mantendré ambas ramas 0.6.x y 0.7.x activas durante algún tiempo, hasta que todos los problemas significativos con la base de datos sean descubiertos y solucionados. Por favor informad de cualquier error, incluyendo restos en la pila.

94 Versión 0.6.1

6 de Febrero de 2014

  • Arreglado un problema menor dentro de la corrección crítica de la 0.6.0. Probablemente no pueda ser explotado, pero arreglarlo no cuesta nada.
  • Incluídas algunas optimizaciones menores presentes en 0.7.0.
  • Mejor gestión de direcciones malformadas declaradas por los pares.

95 Versión 0.6.0

5 de Febrero de 2014

  • El parche crítico se revelará más adelante. Esto es sólo para documentar los otros cambios realizados de la 0.5.12 a la 0.6.0, porque hay bastantes.
  • Resulta muy engorroso trabajar con la rama 0.5.x , una vez acostumbrado al código completamente reestructurado de 0.6.x y 0.7.x. Por lo tanto, he decidido dejar de mantener 0.5.x por completo y avanzar a 0.6.x.
  • El último parche en la 0.5.12 no era suficiente, y todos los usuarios que forjen deberían actualizar a 0.6.0 lo antes posible. La 0.5.12 está rota y no será reparada.
  • La rama 0.6.x aún usa archivos de objetos serializados, pero ya no son compatibles con 0.5.x. Las versiones antiguas de blocks.nxt y transactions.nxt de la 0.5.x se importarán automáticamente y serán convertidos al formato nuevo la primera vez que se ejecute 0.6.0.
  • El parámetro blockchainStoragePath en web.xml ya no es necesario.
  • El código ha sido reestructurado de manera significativa y ya no es un único archivo java. Todas las clases previamente incluidas en Nxt han sido movidas a sus respectivos ficheros.
  • Todo se encuentra bajo un paquete nxt de nivel superior, y en consecuencia el parámetro servlet-class en web.xml debe ser cambiado a nxt.Nxt. Disculpas por no mencionarlo al lanzar la 0.6.0:

    <servlet-name>Nxt</servlet-name>
    <servlet-class>nxt.Nxt</servlet-class>

  • Hay tres subpaquetes, nxt.user, nxt.peer, y nxt.http, con gestores de peticiones en clases separadas para todas las peticiones API de tipo IU, de pares, o de http respectivamente. Esto sustituye por completo las declaraciones antiguas switch/case en los métodos doGet y doPost del servlet.
  • Toda la lógica de negocio se ha sacado de la clase servlet Nxt.
  • Se ha añadido una nueva jerarquía de clase Transaction.Type para manejar la lógica en validación de transacciones, gestión de adjuntos en transacciones, y aplicación de transacciones. Esto sustituye por completo las declaraciones switch que solían sostener la validación de transacciones y la lógica de procesamiento.
  • Deshacer Transacción, en un pop-off de bloque, se ha implementado para transacciones que puedan ser revertidas. Para todas las demás, una UndoNotSupportedException forzará un re-escaneado de la cadena de bloques.
  • La jerarquía de errores específica NxtException se utiliza ahora para contribuir a la validación de bloques y transacciones. La mayoría de los parámetros de bloques y transacciones deben ser ahora forzosamente válidos en los constructores de bloques y transacciones, lo que vuelve bastante difícil olvidarse de validarlos.
  • Se han aplicado muchas optimizaciones menores y no tan menores de rendimiento y uso de memoria, basadas en medidas de perfiles actuales.
  • Se han revisado todos los modificadores de acceso a campos y métodos. Ningún campo o método java es más accessible de lo estrictamente necesario. Todo lo que puede ser privado, ahora es privado. Todo lo que puede ser final, ahora es final.
  • Todas las respuestas JSON y la gestión de errores han sido depuradas y optimizadas.
  • Las conversiones innecesarias de y hacia ByteBuffer en bloques y proceso de transacciones han sido eliminadas.
  • Se ha forzado un límite de tiempo de no más de 1440 minutes para las nuevas transacciones.
  • Los pares que transmitan datos inválidos de bloques o transacciones pasan ahora automáticamente a la lista negra.
  • La documentación de la API Java está ahora disponible en http://localhost:7874/doc/ , todas las peticiones API siguen sujetas a cambios a medida que avanza el trabajo.
  • Cambios Menores en la IU: añadido avisos en los diálogos de desbloquear cuenta y message.html, añadido sendMoney a admin.html.
  • APIs Nuevas o mejoradas:
    • getAccount
      • parámetro: cuenta (la id de la cuenta)
      • devuelve: clave pública (si es conocida), saldo, saldo efectivo, y saldos de activos
    • getAsset
      • parámetro: activo (la id del activo)
      • devuelve: Id de la cuenta del emisor del activo, nombre del activo, descripción y cantidad
    • getAssetIds
      • devuelve: todas las id existentes de activos.
    • getAskOrderIds y getBidOrderIds requieren ahora un parámetro de activo, y devuelven las id de las demandas/ofertas para ese activo en particular.

96 Versión 0.5.12

5 de Febrero de 2014

  • Arreglado un error crítico. Todo el mundo debería actualizar de inmediato.

97 Versión 0.5.11

30 de Enero de 2014

  • Arreglados problemas de rendimiento en getState, getEffectiveBalance y getGuaranteedBalance. El cálculo de getGuaranteedBalance usa ahora un algoritmo distinto y en algunos casos puede dar resultados distintos al cálculo de guaranteedBalance en la versión 0.5.10 que contenía algunos errores, así que se recomienda que todo el mundo actualice a 0.5.11 para evitar el riesgo de una bifurcación.
  • Arreglado un error relacionado con las claves públicas de cuentas que forjaban bloques sin tener transacciones salientes.

98 Versión 0.5.10

23 de Enero de 2014

  • Esta publicación soluciona errores. Todos los usuarios de 0.5.9 y anteriores deberían actualizarse.
  • Arreglado un error en la Forja Transparente. El parche surte efecto en el bloque 51000. Los usuarios que no actualicen antes de este bloque se quedarán en una bifurcación.
  • Arreglado un error menor en el cálculo del peso de los pares.
  • Informe de Progreso:
    • La reestructuración de la versión 0.6.0 va bien. El proyecto Nxt consta ahora de 86 archivos java en lugar de 1. Los programadores seguirán trabajando en los bloques y transacciones persistentes en una base de datos durante la semana que viene. No tienen previsto publicar 0.6.0 hasta que no sea absolutamente necesario, porque no contiene ninguna funcionalidad visible para el usuario y en este momento probablemente sea menos estable que la serie 0.5.x. Los parches urgentes y los nuevos comandos API, si son necesarios, aún se añadirán a 0.5.x. Los clones de Nxt que esperan ansiosamente la serie 0.6.x, para poderse beneficiar gratis de mi trabajo de reestructuración, tendrán que seguir esperando mientras los programadores avanzan.

99 Versión 0.5.9

19 de Enero de 2014

  • Resueltos todos los problemas restantes en la concurrencia de procesos en el manejo de bloques y transacciones. Todas las null pointer exceptions reportadas, división por cero, y errores relacionados ya no deberían producirse. Si ves algún error en el registro, por favor repórtalo en nuestra base de datos de errores: https://bitbucket.org/JeanLucPicard/nxt-public/issues
  • Añadidas las llamadas API del Intercambio de Bienes y Divisas: getAskOrder, getAskOrderIds, getBidOrder, getBidOrderIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds.
  • Se previene que la ventana de Bloques Recientes en la IU del navegador crezca más allá de 60 bloques. Esto debería ayudar a evitar la ralentización en el navegador, y los cuelgues en la descarga de la cadena de bloques completa desde el inicio.
  • Añadida la re-transmisión de transacciones. Para asegurarse de que una transacción nueva ha sido recibida por la red, se transmite cada minuto, hasta que aparece en la lista de transacciones confirmadas o no confirmadas.
  • Los registros de depuración están tranquilos, de hecho no he visto ningún error durante las últimas 24 h de prueba para esta versión. Todos deberían probarla porque espero que sea realmente estable. En particular, los pares que aún ejecuten la 0.5.7 con todos sus fallos, serán añadidos a la lista negra mientras no actualicen, porque siguen transmitiendo bloques JSON defectuosos y serán tratados como zombies.

100 Versión 0.5.8

16 de enero del 2014'

  • Se ha corregido un problema de concurrencia que probablemente sea la causa de los errores OutOfMemory que algunos han experimentado. Se trata de una corrección de bugs críticos, usuarios de 0.5.7 deberían actualizar a 0.5.8.
  • Se han añadido filtros de "tipo" y "subtipo" para la API getAccountTransactionsIds.

101 Versión 0.5.7

15 de Enero de 2014

  • Tras las optimizaciones en el uso de memoria y CPU, esta versión optimiza la conectividad. En lugar de transmitir a todos los pares, los datos sólo se envían a 10 pares por defecto. El número se puede configurar en web.xml, en el parámetro sendToPeersLimit. Esto debería reducir el tráfico de la red, así como bajar de forma significativa el tiempo de espera del usuario al enviar una transacción. Además, los envíos se realizan ahora en paralelo, usando un pool de 10 procesos, lo que implica que los pares lentos no retrasarán el envío al resto.
  • Algunos de los problemas encontrados en la depuración de errores han sido solucionados, y algunos otros errores de red inofensivos serán ignorados a partir de ahora. Los registros están ahora mucho más tranquilos incluso con la depuración habilitada, así que he decidido activar el parámetro nxt.debug por defecto en nxt.ini.
  • La fase 2 de la Forja Transparente comienza en el bloque 47000. Todo el mundo debería actualizar por lo menos a 0.5.7 antes de alcanzar este bloque, de lo contrario podrían aparecer bifurcaciones.
  • Añadida la herramienta de Wesley para enviar mensajes, message.html.

102 Versión 0.5.6e

13 de Enero de 2014

  • Limpiado el registro de errores y el manejo de excepciones. Ahora hay dos propiedades del sistema que pueden utilizarse para obtener un registro de depuración adicional: nxt.debug y nxt.enableStackTraces. Están definidas em start.d/nxt.ini:

    # Habilitar mensajes de depuración
    #-Dnxt.debug

    # Habilitar también rastreo de excepciones
    -Dnxt.enableStackTraces

    # Deshabilitar todos los avisos e información de jetty
    -Dorg.eclipse.jetty.LEVEL=OFF
  • Por defecto, nxt.debug está deshabilitado. Si vigilas tu registro, por favor habilita la salida de depuración sacando el comentario ante la línea -Dnxt.debug en nxt.ini, e informa de cualquier error mediante nuestro seguimiento JIRA en Bitbucket:
    https://bitbucket.org/JeanLucPicard/nxt-public/issues
    Por favor evita enviar problemas duplicados, asegúrate de que no hay errores muy similares ya notificados.
  • El parámetro nxt.enableStackTraces activa la salida de resíduos de excepciones del stack hacia el registro, independientemente del parámetro nxt.debug deberías dejarlo activado.
  • Con nxt.debug precedido de comentario, Nxt todavía enviará mensajes al registro, pero muchos menos. Si se produce una excepción crítica, será registrada incluso si nxt.debug no está habilitado.
  • El ruidoso registro de avisos de Jetty está deshabilitado y ahora el registro debería estar mucho más limpio. Si te gusta ver los avisos de Jetty, añade un comentario frente a la línea -Dorg.eclipse.jetty.LEVEL=OFF en start.d/nxt.ini, pero no los notifiques como errores.
  • La razón por la que esta versión se considera experimental es que he actualizado Jetty desde la versión 9.1.0 a la 9.1.1.v20140108. La gente debería probarlo para ver si hay alguna incompatibilidad con los distintos sistemas y versiones de Java.

103 Versión 0.5.5

11 de Enero de 2014

104 Versión 0.5.4e

10 de Enero de 2014

  • Añadido el código para Mensajes Arbitrarios, que se activará en el bloque 40000.
  • Añadidas nuevas peticiones API:
  • Optimizaciones significativas en el consumo de memoria y el rendimiento para reducir la carga en el GC y los requisitos totales de memoria. Debería poderse ejecutar con -Xmx512M si es necesario, más es mejor pero no debería ser necesario. Espero que a los usuarios de Raspberry les haga felices esta versión.
  • Es experimental por las múltiples optimizaciones relacionadas con la memoria, pero devería rendir mejor que la 0.5.3.

105 Versión 0.5.3

8 de Enero, 2014

  • Arreglado el reescaneo de la cadena de bloques. Limpia las transacciones no confirmadas al reescanear.
  • Mejor validación del número de cuenta destino. No acepta números de cuenta excesivamente altos ni negativos. Al menos debería prevenir algunos casos de transacciones enviadas a destinos equivocados por error del usuario.

106 Versión 0.5.2

7 de Enero de 2014

  • Añadida validación de numberOfTransactions y payloadLength para prevenir ataques tipo OutOfMemory.

107 Versión 0.5.1

7 de Enero de 2014

  • Posible solución para https://bitcointalk.org/index.php?topic=397183.msg4343616#msg4343616; necesita más pruebas. Por favor notificad cualquier caso de bloques recientes y saldos negativos, e incluid el registro de errores si sucede.
  • Arreglada la adición a la lista negra de pares con sello de calidad.
  • Las cuentas con saldo negativo no pueden forjar.
  • Mejorada la verificación de la clave pública.
  • Actualizado update.html a la última versión y cambiado el enlace de descarga.
  • Arreglada la ausencia de IDs de transacción en Mis Transacciones.

108 Versión 0.5.0

Ésta debería considerarse versión estable. Registro de cambios:

  • Arreglados otros problemas de concurrencia, optimizado el rendimiento y limpiado el código. He arreglado todos los problemas visibles en el código que considero errores, el resto de mis tareas pendientes son limpieza del código y reestructuración.
  • Añadido un punto de control en el bloque 30000 (el bloque del inicio de la forja transparente).
  • Añadido el revisor de actualizaciones de wesley: https://bitcointalk.org/index.php?topic=345619.msg4294180#msg4294180
    • Utiliza https://localhost:7875/update.html para revisar actualizaciones - esta función podría contener aún errores, pero incluirla en el paquete es una buena forma de que la gente la pruebe en navegadores distintos.
  • Los desarrolladores aún no han podido encontrar una causa posible para el error más crítico reportado hasta la fecha, transacciones enviadas a un destinatario distinto del seleccionado. He vuelto a leer el código relevante, pero no veo ninguna forma evidente de cómo podría ocurrir. No estoy ignorando los informes y creo que puede ser un bug real y no un error del usuario, pero sin un modo de reproducir el problema, es muy difícil rastrear su causa.

109 Versión 0.4.9e

Este debe ser considerado un lanzamiento EXPERIMENTAL. Hay unos cuantos cambios así que tened cuidado. Quedaos con la versión estable 0.4.8 si no queréis asumir riesgos. Pero nuestra nave insignia NCC-1701-D has lleva ejecutando 0.4.9e desde ayer sin problemas.

  • Muchas optimizaciones y arreglos en la concurrencia. Deberían mejorar el rendimiento de forma significativa, y reducir la probabilidad de que el cliente se cuelgue y necesite un reinicio.
  • Optimizaciones en el rendimiento, reduciendo el número de objetos temporales creados en la red de pares, asegurándose de que las conexiones se cierran correctamente. Los requisitos de memory son ahora menores, mis servidores nunca pasan de 1.5 GB. Ahora deberíais poder ejecutarla en un node VPS de 2 GB con Xmx1536M sin problemas. Si no atraéis mucho tráfico (no publiquéis vuestra IP) la memoria se quedará por debajo de 1GB.
  • Ahora, al desbloquear una cuenta nos aseguramos de que todas las sesiones de esa cuenta en el servidor se cierren. En otras palabras, si abres varias ventanas de navegador al mismo servidor (localhost), sólo puedes estar conectado a la misma cuenta en una de ellas al mismo tiempo. Eso no te impide desbloquear la misma cuenta en equipos distintos (pero no deberías hacerlo).
  • Al generar un token de autorización te volverá a pedir una confirmación de la contraseña.
  • Quizá os hayáis dado cuenta de que la Forja Transparente ya ha comenzado. Mi decisión en el último momento de empezar en 32000 no llegó a tiempo de estar incluida en el paquete 0.4.8 (también cometo errores), de modo que la 0.4.8 salió con el cambio aún programado en 30000. Ya estamos en el bloque 30000, así que ya hemos empezado.
  • Cambios Menores: Agregados Get Account Aliases, Get Alias URI, and Get Multiple Account Balances features a la página https://localhost:7875/admin.html. Agregados algunos nodos bien conocidos más a web.xml por defecto.
  • Hay un problema serio de seguridad que no está completamente solucionado en 0.4.9e. Todas las URLs de peticiones se quedan en el caché del navegador, y aunque no aparecen en el historial de navegación (razón por la cual no vimos antes el problema) aún se encuentran en el caché. Podéis comprobarlo usando about:cache en firefox.
  • Esto es malo, porque implica que tu contraseña está siendo escrita en el caché como texto simple. Y estoy seguro de que aparecerán exploits en javascript que intentarán sacarla de ahí. Para solucionarlo de verdad, todas las peticiones API desde el navegador que incluyan la contraseña deben ser emitidas como peticiones POST, y no GET. Pero esto requiere cambios significativos en el cliente javascript, y llevarán algún tiempo. Como no está previsto mantener el cliente javascript actual, no sé si esa reescritura debería comenzarse ahora. En la 0.4.9e he añadido por lo menos los headers en la respuesta que impiden el volcado a disco. Firefox los respeta, pero aún guarda en memoria las URL de las peticiones. Por seguridad, sugiero encarecidamente usar un perfil de navegador separado sólo para acceder a tu cliente Nxt, o modo de navegación privada. Quienes utilicen 0.4.8 o anteriores deberían borrar de forma inmediata la caché de su navegador.

110 Versión 0.4.8

  • Añadida la Forja Transparente, que se activará en el bloque 30000.
  • Arreglado un problema de fuga de memoria.
  • Al enviar dinero desde el navegador también te pedirá la contraseña.
  • Sólo hay un parámetro nuevo en web.xml, myPlatform. Se usa para declarar tu plataforma - PC, Mac, Raspberry, NeXTstation, VAX, zombie...
  • de esta versión en adelante, el archivo zip no incluye blocks.nxt y transactions.nxt. ¡Asegúrate de conservar tus archivos *.nxt antes de actualizar!


111 Version 0.4.7e (versión de código fuente liberada)

  • El Sistema de Alias no está incluido en el código fuente al ser una característica avanzada.
  • La Forja Transparente tampoco está incluida, porque sólo ha sido implementada en la 0.4.8. Por lo tanto, los clientes compilados con este código fuente solamente podrán alcanzar en bloque 30000 en la cadena de bloques actual.
  • Todos los arreglos de fugas de memoria y optimizaciones de rendimiento que aparecen en 0.4.8 y 0.4.9e tampoco están incluídos.
  • Sólo como referencia, la sección de descargas contiene el paquete binario compilado 0.4.7e tal y como fue lanzado inicialmente. Las librerías json-simple y jetty que incluye serán necesarias para compilar el código fuente de Nxt.java. Como ya hemos mencionado, este paquete binario está desfasado y no trabajará con la cadena de bloques actual una vez pasado el bloque 30000.

112 Versión 0.4.6

  • La única diferencia con 0.4.5 es el contenido de los archivos de la cadena de bloques

113 Versión 0.4.5

  • Arreglo rápido del error de overflow.

114 Versión 0.4.4

  • Añadido Jetty DoSFilter (gracias a Edward Elric)
  • Añadidos parámetros myScheme, myPort y shareMyAddress (definir en valores adecuados, se usarán en la próxima versión)
  • Añadido enableHallmarkProtection, definir como "false" si quieres desconectar la protección, blacklistingPeriod se define ahora en milisegundos en lugar de segundos
  • logPeerCommunication sustituido por communicationLoggingMask (1 - registrar excepciones, 2 - registrar respuestas con códigos de respuesta no-200 HTTP, 4 - registrar respuestas con códigos 200 HTTP), los valores de máscara se pueden combinar de la manera habitual
  • Los fragmentos de suministro de bloques se incrementan de 128 KiB a 1 MiB.

115 Versión 0.4.2

116 Versión 0.4.1e

  • Añadido soporte para CORS (http://publicnxtnode.com:7874/nxt?requestType=getAliasURI&alias=Google sólo petición, habilitado de momento como concepto)
  • Scripts JS pueden sustituir los alias Nxt por sus URIs correspondientes utilizando XMLHttpRequest y document.links
  • Optimizado el algoritmo de recogida de transacciones. Los bloques se llenarán hasta su máxima capacidad, el algoritmo previo no escogía las transacciones con baja comisión para llenar pequeños huecos.

117 Versión 0.4.0

118 Versión 0.3.20

119 Version 0.3.19e

  • Added "peerScheme" and "peerPort" in web.xml. This is for migration to HTTPS and different ports.
  • Added "maxNumberOfConnectedPublicPeers" in web.xml. Your node will keep connecting to public peers until this number is reached. Previous version does it until total number of public and private peers < 100.
  • Removed code related to Colored Coins (to prepare source code for review). Now you don't have to copy so many .class files.
  • Made an attempt to fix blockchain downloading issue related to stuck "Catching up..." message. I removed it from .html files completely, so you won't see it anymore... It's a joke, I also changed a few lines of server code. Now blocks are downloaded faster (2 mins vs 30 mins in previous version) and you don't need to lock/unlock account to unfreeze Recent blocks widget (I hope). I wasn't able to check how the changes handle blockchain reorgs when orphaned blocks appear, that's why this version is experimental. If you can, please, install it and report if you see at least one orphaned block or the blockchain stops growing.

120 Version 0.3.18

December 11, 2013

  • Enabled hallmark protection for outbound requests
  • Added code for migration to non-standard ports for peer communication
  • Added code for migration to other blockchain file format (check "blockchainStoragePath" in web.xml, you can use absolute paths)
  • Added http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds
  • If you announce address of your host via "myAddress" you must set it to the "host" value returned by http://otherserver.com:7874/nxt?requestType=getMyInfo . In one of the next versions nodes will begin checking that it matches the address returned by http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
  • More info about the hallmark protection
    • Now marked hosts will attract more traffic. There are 2 types of outbound requests - Send (for getting unknown unconfirmed transactions, for blockchain downloading) and SendToAll (for pushing blocks and transactions). Send picks one of the connected peers depending on their weight (weighted random hit is made), peers with weight = 0 are considered as having weight = 1. SendToAll sends data to peers according to their weights in descending order.

121 Version 0.3.17

December 10, 2013

  • Removed accounts.nxt, the data are generated on the fly. If you see incorrect balance then rerun the client (but still report this bug, I can't reproduce it).
  • Enabled blacklisting, now it uses "blacklistingPeriod" (in seconds) in web.xml to automatically "unblacklist" nodes.
  • Added http://localhost:7874/nxt?requestType=getPeers to list all peers. Details of a peer can be obtained via http://localhost:7874/nxt?* requestType=getPeer&peer=88.198.210.245.
  • Trash icon now works for remote users if allowedUserHosts is set to anything except "*".


122 Version 0.3.16

December 8, 2013

123 Version 0.3.15

December 7, 2013

  • The list of well-known peers is not hardcoded in 0.3.15. Look at "wellKnownPeers" in nxt/webapps/root/WEB-INF/web.xml. Feel free to change it.
  • Added "myHallmark" in web.xml. If you are an owner of non-trivial amounts in NXT you should run your own node(s) accessible on the Internet to protect the network. Hallmark is used to mark such nodes

124 Version 0.3.14

December 6, 2013

  • Fixed Opera rounding issue

125 Version 0.3.13

December 5, 2013

  • Added warning for secret phrases < 30 symbols.
  • Added extra transaction validation (@hacker: attempt your trick again)

126 Version 0.3.12

December 5, 2013

  • Upgrade only if you have 0.3.11 installed and want to generate blocks. Contains a quick work-around against unconfirmed double-spending transactions.

127 Version 0.3.11

December 5, 2013

  • Enabled "sendMoney" API request.
  • Fixed expired unconfirmed transactions issue (@anonymousHacker: check it plz).
  • Fixed some issues related to memory leaks.

128 Version 0.3.10

December 4, 2013

  • API now available on 7874 (http) and 7875 (https) ports.
  • API request format changed from localhost:7876/?request=XXX to localhost:7874/nxt?requestType=XXX
  • 2 parameters in web.xml added:
    • "allowedUserHosts" (not enabled yet) and "allowedBotHosts". An example of "allowedBotHosts" value - "*" for all hosts or "173.194.70.102; 204.79.197.200" for some of them.
  • As a quick trick web interface can be "disabled" by deleting all *.html files in "nxt/webapps/root" directory.

129 Version 0.3.8

December 4, 2013

  • Rewritten web interface networking.
  • Now HTTP & HTTPS can be used (http://localhost:7874 & https://localhost:7875). The latter is preferable if you use "online" wallet. Browsers will show warning coz TLS certificate is self-signed, try to add it into the certificate vault to get rid of the warning.

130 Version 0.3.6

December 3, 2013

  • Added blacklisting and some interface changes.
  • There is a little bug in the interface, sometimes it's not refreshed, use F5. Unfortunately, I can't fix it now, someone crashed my node using Jetty vulnerability. I'm going to solve the Jetty issue first.

131 Version 0.3.5

December 3, 2013

  • Reduced peer timeout from 10 to 2 seconds. This is a work-around for missing blacklisting.

132 Version 0.3.4

December 3, 2013

  • Update if you see a lot of unconfirmed transactions.
  • An anonymous hacker did us a favor and spammed with double-spending transactions. New version has a quick work-around to get rid of such transactions. Luckily block validation code was OK and didn't let to include blocks with double-spending transactions into the chain.

133 Version 0.2.20

December 1, 2013

  • Contains only a quick fix proposed by Come-from-Beyond.

134 Version 0.2.19

November 30, 2013

  • Interface fix for very long peer address.

135 Version 0.2.18

November 30, 2013

  • Changed direct buffer allocation mechanism for peers and API bots

136 Version 0.2.17

November 29, 2013

  • Some minor changes in interface, now you can see transaction ids. Install it if you have disappearing transactions issue.

137 Version 0.2.16

November 28, 2013

  • For developers only.

138 Version 0.2.15

November 28, 2013

  • Two API requests were added

139 Version 0.2.13

November 28, 2013

  • Minor changes related to *.nxt files corruption.

140 Version 0.2.12

November 27, 2013

  • Should fix stalled "Catching up..."
  • If it still stalls then remove all Active peers one by one, after removing the one you were downloading the blockchain from, it should continue bootstrapping from other peer.

141 Version 0.2.10

November 26, 2013

142 Version 0.2.9

November 25, 2013

  • Mandatory for everyone who stuck on 303th block.

143 Versions 0.2.8 through 0.2.3

November 25, 2013

144 Version 0.2.1

November 24, 2013