-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512Release 1.7.0esha256:431f0bc71e4ff4734cac1df493e89d9af4cd8d129db448ae1ab0cdadeb4a6617 nxt-client-1.7.0e.zipsha256:99e19887bb41a52197062f78e68c798eefb999c2db0e73d38100ef0b3c8588b9 nxt-client-1.7.0e.jarThe exe and jar packages must have a digital signature by "Stichting NXT".This is an experimental release for testing only. Source code is not provided.Change log:This is an experimental release. The new features will be activated at block483000 on testnet (Nov 30) and 621000 on production (estimated Jan 21, 2016).All testnet nodes are required to upgrade to this release. Those that don'twill remain on a fork.Production nodes will need to upgrade to the stable 1.7 version once it isreleased (expected before end of December), but in any case before thehardfork scheduled for block 621000.New features:Coin Shuffling. This feature is based on the paper by Tim Ruffing et al,Coin shuffling can be used to perform mixing of NXT, MS currencies (unlesscreated as non-shuffleable), or AE assets. Any account can create a newshuffling, specifying the holding to be shuffled, the shuffle amount, numberof participants required, and registration deadline. This is done using theshufflingCreate API. The subsequent shuffling steps can be done eithermanually, by using the shufflingRegister (for accounts other than thecreator), shufflingProcess, shufflingVerify or shufflingCancel APIs, or, muchmore conveniently, by starting an automated Shuffler, using the startShufflerAPI. Once started, the Shuffler monitors the blockchain state for transactionsrelevant to the specified shuffle, and automatically submits the requiredtransactions on behalf of the user, performing shuffle processing,verification, or cancellation as needed. To do this, the Shuffler is requiredto keep the user secret phrase in memory, therefore it should be run on atrusted local machine only. A restart or a crash of the node requires theshuffler to be started again using the startShuffler API, as it should neversave the user secret phrase on disk.To participate in a shuffling, a deposit of 1000 NXT is needed, in additionto the amount of currency or asset being shuffled. Or if shuffling NXT, theamount of the shuffle must exceed this 1000 NXT minimum. If the shufflingcompletes successfully, this amount is added to the recipient account balance,to allow it to send outgoing transactions (as it is required that only new,unused accounts are specified as recipients). If the shuffle fails due toa registered participant failing to participate as required, or intentionallysubmitting false data, the participant responsible for the shufflecancellation is penalized by retaining this deposit and sending it to theforgers of the shuffle finish block and the previous three blocks instead.If a shuffle is cancelled because the required number of participants is notmet, nobody is penalized and all deposits are refunded. On testnet, the depositand penalty is 7 NXT only.After shuffling registration is complete, participants must submit processingdata within a 100 blocks period each (10 blocks on testnet). For theverification and blame phase, the total allowance for all participants is 100+ numberOfParticipants blocks (again reduced to 10 + n blocks on testnet).Full blocks are not counted towards the limit. If at any stage the deadline isreached without some participant submitting the next required transaction, theshuffling is cancelled at this participant's fault. It is therefore criticalthat after registering for a shuffling, the shuffler started is left runninguntil its successful completion. If the node must be restarted, all previouslyrunning shufflers must be started again manually.Query APIs to retrieve currently running shufflers, shufflings, and shufflingparticipants are: getAllShufflings, getAccountShufflings,getAssignedShufflings, getHoldingShufflings, getShufflers, getShuffling, andgetShufflingParticipants.If desired, finished shufflings can be automatically deleted from the databaseif the nxt.deleteFinishedShufflings property is set to true (default is false).The fee for creating a shuffling or registering in one is 1 NXT, for theshuffling process or shuffling cancel transactions 10 NXT, and for the verifytransaction 1 NXT.Account control for phased transactions. Any account can be restricted to onlybe allowed to issue phased transactions subject to a specific voting model.This is achieved by the account submitting a setPhasingOnly transaction usingthe setPhasingOnlyControl API. The getPhasingOnlyControl API can be used toretrieve the status of an account phasing control, andgetAllPhasingOnlyControls to get all accounts subject to phasing control withtheir respective restrictions.Once set, the phasing only account control can only be disabled or changedwith another setPhasingOnly transaction, itself subject to the currently setphasing restrictions.Note that by-transaction and by-hash voting models are not allowed for phasingcontrol, and setting voting model to none is used to disable the control.To prevent deadlocks due to cyclic account control restrictions, approvaltransactions themselves (PhasingVoteCasting) are not subject to phasing onlyaccount control.When setting phasing account control, a maximum fees total can be specified,limiting the total fees for currently pending phased transactions of thecontrolled account, and limits can be placed on minimum and maximum phasingduration allowed.Transactions of accounts subject to phasing account control with restrictionon maximum fees are throttled at one per account per block.Immediate release of phased transactions on approval. Phased transactions witha voting model that does not depend on account balance (such as by-transactionor by-hash), or by-account with no minimum balance and with a whitelist, willbe released before their finish height as soon as approved (in the block inwhich the transaction causing their approval is executed), if possible. Suchearly finish is guaranteed for transaction types known to be phasing safe. Forothers, if the early finish does not succeed due to the transaction failingvalidation at this height or conflicting with another transaction in the sameblock, a second, final release attempt will be performed at finish height.New base target adjustment algorithm. Average block times will be 60 s, with1440 blocks per day. Block times should practically never exceed 10 min.Limit of 1000 NXT on minimum forging balance. This applies to the total of theaccount own guaranteed balance plus any balances leased to it, but not to eachindividual balance lease. An account with balance lower than the limit canstill lease its balance to another.Account properties. Those are name / value pairs that can be set on anyaccount (except Genesis), by either the account owner, or by another account.Names are limited to 32 characters, and values to 160 characters. Names areunique per account and per setter account, but not globally unique. Accountproperties cannot be transferred between accounts. The setter of an accountproperty can edit it by replacing its value with another. Either the setter,or the recipient (if different) of an account property can delete it. Thereis no limit on the number of properties an account can have. Fee for settingaccount property is 1 NXT for value up to 32 chars, with additional 1 NXT feefor every 32 chars after that.Account properties are managed using the setAccountProperty anddeleteAccountProperty APIs. To query the properties of an account, or thoseset by an account, the getAccountProperties API can be used.Singleton assets. Issuing an asset with a quantity of 1, decimals 0, anddescription length not exceeding 160 characters, will require a base minimumfee of 1 NXT only, instead of the regular 1000 NXT asset issuance fee. Fordescription of more than 32 chars, an extra 1 NXT fee is added for each 32chars. Asset name for singleton assets is limited to 10 chars, same as forregular assets.Throttling of unique resource allocation transactions. Asset issuance(excluding singleton assets), monetary system currency issuance, and aliasassignment (excluding re-assignment), will be limited to only one transactionof each type accepted per block.Spreading back block fees for asset and currency issuance. The transactionfees for asset (excluding singleton assets) and currency issuance will besplit between the forgers of the current and the previous three blocks in a4:3:2:1 ratio.Prunable plain and prunable encrypted message attachments both allowed in thesame transaction. The maximum data size for each such attachment is 42 kbytes,but when coexisting in the same transaction the sum of the two is still beinglimited by the maximum payload size of 44880 bytes.Peers that provide http or https API access open to anyone, configured withnxt.apiServerHost=0.0.0.0 and nxt.allowedBotHosts=* , are now labelled asproviding a service, API or API_SSL, and can be found using the getPeers APIwith the corresponding "service" parameter. This API has been modified toaccept multivalued "service" parameter, returning peers that match allrequested services. The ports on which the open API access is running areincluded in the peer info of peers providing those services as apiPort andapiSSLPort fields.Incompatible changes:Deletion of asset shares will be performed as a separate AssetDeletetransaction type instead of as sending the shares to Genesis. Sending sharesto Genesis will no longer be allowed. A new API, getAssetDeletes has beenadded to retrieve asset deletions, as using the getAssetTransfers API to findtransfers to Genesis account no longer can be used for that purpose. There isalso a new API, getExpectedAssetDeletes, to get asset deletes expected in thenext block, analogous to getExpectedAssetTransfers.Since both prunable plain and prunable encrypted messages can now be added tothe same transaction, the APIs getAllPrunableMessages, getPrunableMessage, andgetPrunableMessages cannot continue to use just a single "isText" boolean fieldin the JSON response to indicate if the prunable message is text or binary.For all prunable plain messages, a new "messageIsText" boolean field is added,and for all prunable encrypted messages, a new "encryptedMessageIsText" booleanfield is added in the response of the above APIs, for each message.For backwards compatibility, the "isText" field will continue to be added, butonly for transactions that have either plain, or encrypted, prunable messageattachment, not for those that have both.This change does not affect the attachment JSON returned from getTransactionAPI, as there are already separate messageIsText and encryptedMessage.isTextfields there.Fees and size limit changes. Several transaction types or attachments willhave new fees and size limits, to encourage users to utilize the prunableversions when available, and to make fees proportionate to actual blockchainspace consumed.Aliases:Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus URItotal length, after the first 32 chars. Name and URI size limits remain at100 and 1000 chars respectively.Messages and EncryptedMessages (non-prunable):Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after thefirst 32 bytes. For encrypted messages, the length is measured excluding thenonce and the 16 byte AES initialization vector, and to account for thosethere is an extra fee of 1 NXT.Fees and size limit for prunable messages remain unchanged.AccountInfo:Base fee 1 NXT, with 2 NXT additional fee for each 32 chars of name plusdescription total length, after the first 32 chars. Name and description sizelimits remain at 100 and 1000 chars. AccountInfo transactions throttled atone per block.Polls:Base fee 10 NXT for polls with up to 20 options, and total size of poll nameplus poll description plus total option length not exceeding 320 chars. Foreach option above 20, an additional fee of 1 NXT, and for each 32 chars after320, an additional fee of 2 NXT. Poll creation throttled to one per block.Name, description, and option length limits remain at 100, 1000, and 100 charsrespectively.DGS Listing:Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plusdescription total length, after the first 32 chars. Name and description sizelimits remain at 100 and 1000 max. DGS Listing throttled at one per block.DGS Delivery:Base fee 1 NXT, with 2 NXT additional fee for each 32 bytes of encrypted goodsdata after the first 32 bytes, nonce and AES initialization bytes excluded.Encrypted goods data size limit remains 1000 bytes.Phasing:In addition to the current fee for phasing (1 NXT for balance independent,20 NXT otherwise), 1 NXT will be added for each 32 bytes of hashedSecret orlinkedFullHash fields.Referenced transactions:An extra fee of 1 NXT for the 32 byte referencedTransactionFullHash if set,i.e. if the transaction is using the referenced transactions feature.To facilitate migration of legacy client code to the new fees, if the propertynxt.correctInvalidFees=true has been set in nxt.properties (default is false),the server will automatically replace insufficient fees for submitted unsignedtransactions with the minimum fee needed, depending on the transaction, as iffeeNQT=0 has been specified. Fees exceeding the minimum, or fees for alreadysigned transactions, will not be corrected.This release will perform a blockchain rescan on first start.-----BEGIN PGP SIGNATURE-----iQIcBAEBCgAGBQJWW3D0AAoJENqvaxkWiP4Z5kwQAMSyWK1g8SdtYLzN6GCc8dGVvIRCPOGOfZn1WfzfJwTY1itSg2EfFp88c7I9BaHex6QT++37YA4wmtzXE3cyQ+zPgGAj37IbcR/Tj4Y9L9BYjmVnoJAxvKx2/X1U+GkQf2k1XVr3PINtSlCbbedU1oMcmaS83CTgBO2OcCKEhP+zjwxAIBIbTSRPFdsIUB76yAD20tEdI7lbS7QRGGVyedoC+AfNVwmgYRtXJiWL8kN9bTj6nc6MVEJ0XwNkPStgS6sk2u0w0iacbHDId5NCDT/gkXlkKBaatSV5EfWf8echPJCGX5X2xuhUJ2YNIFMXtRxseqgaEcPcmFStacH2GlGPstiO+ot7eYA3A9tO9kjkAq8stToY2SIhd42SoNhPItYPb2UCEzEc8tAPz9l/Ez37HzglxdjW2vFQUnn5OMwPt/xUBP+ncb0Rx9YGCH4ugns8tT77sHAitKvUqqq9Q0sCt8nmeFaFcQ+x5U1XB7qni4MW+fD5Q4rGO3uyvwhGoDV9N22yQQt4+jMKEC/wqerAej5wLau8aEXOY7HajPsesOVlgvFVLFsxX6gq25sVoBd/IBOQdZblGF8WkuIbcVdq6euQ7Prrm3jEwkdkmWxqYnGekOeCn7giIYzZkR3BRI9VIE07Sn+CwM/axuX5sVxMF8RLOjPY+wrWs01crjzH=VYpu-----END PGP SIGNATURE-----