-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1Release 1.5.1esha256:7f56babc8bce1ab12117dea86c0225611bb6eb86796de6c7869438a575523722 nxt-client-1.5.1e.zipThis is a development release for testing only. Source code is not provided.Change log:This is an experimental release which adds the Prunable Messages feature. Itwill 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 runon main net.New features:Prunable plain and encrypted messages.Plain and encrypted messages can now be created as prunable. For a prunablemessage, 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 arebeing signed, used to verify the signature, or to generate the fulltransaction hash or id. This makes it possible to completely remove themessage data at a later time, keeping only that 32 byte hash, and still beable to verify the transaction signature and have the transaction hash andid unaffected by the pruning.Prunable messages have a predefined lifetime, after which their prunable partsare deleted from the blockchain. This lifetime is measured starting from thetransaction timestamp of the message. When a node receives a transaction ora block from a peer, it is only required that the prunable parts of anyprunable message are also included if their expiration time has not yet beenreached. If it has, and a valid message hash is included instead, the block ortransaction 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 setto two weeks, but this is subject to change before the stable release. Notethat pruning is performed at the same time as derived table trimming, whichby default is every 1000 blocks, so the actual removal of the prunable datafrom the database will happen with some delay after their expiration time.A node can choose to keep prunable messages longer, by setting thenxt.maxPrunableLifetime property to a larger value. It cannot be set toprune them earlier. Changing this value only affect transactions receivedafter the change. Pruning can be disabled completely by setting this propertyto -1.Prunable messages that have not yet been expired, but are past the minimumlifetime, are only retrievable using the getPrunableMessage(s) APIs, butare not included as part of their transaction JSON.If a transaction containing prunable attachments is phased, the prunableparts are nevertheless saved and available immediately, not at finish height.If their expiration deadline comes before the phasing finish height, theywill be pruned and not available at finish height.Fees for prunable message attachments are set at 0.1 NXT per 1024 bytes, withthe first 1024 bytes free (the regular transaction fee depending on its typestill applies). This is again subject to change before the stable release.The full size of prunable message attachments is limited to 42 kbytes. Notethat the full size is still included for the purpose of calculating the totalblock 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 beenrestricted back to 1000 bytes, and will likely be reduced even further, beforethe stable release. This will be done in order to encourage users to switch toprunable instead of regular messages. Fees for regular message attachmentswill also be increased substantially.Creating prunable plain messages of less than 28 bytes is not allowed, as atsuch small sizes it is more efficient to store the full message instead of a32 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 prunableencrypted message at the same time. It is also not possible to have bothprunable and regular message of the same type (plain or encrypted). It ishowever possible to have a regular plain message and an encrypted prunablemessage, or a prunable plain message and a regular encrypted message.Prunable encrypt-to-self messages are not currently supported as there seems tobe 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 tobe specified when decrypting. Regular encrypted messages are still compressedby default, but this compression can now optionally be disabled. For backwardscompatibility, since their current bytes format does not store the compressionstatus, this needs to be specified again when decrypting, else an error orunreadable 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 aboveAPIs.The UI for those APIs will be implemented in a later release.TrimDerivedTables - a debug API to trigger a derived tables trim, and prunabletables pruning.Changed APIs:All APIs that create a new transaction now also accept optionalmessageIsPrunable or encryptedMessageIsPrunable boolean parameters (defaultfalse). If true, the message or encrypted message attachment, if any, iscreated as a prunable message.To control whether compression is performed before the encryption or not,the new compressMessageToEncrypt and compressMessageToEncryptToSelf parameterscan be used (default true).Prunable messages, if not yet pruned, are also returned as part of thetransaction json by the getAccountTransactions API, using the same fields asthe corresponding regular messages, but adding a messageIsPrunable orencryptedMessageIsPrunable boolean flag.ReadMessage now also handles prunable message attachments, if any. It takesan optional uncompressDecryptedMessage and uncompressDecryptedMessageToSelf(default true) parameters, only used for non-prunable messages (not neededfor prunable ones).DecryptFrom accepts an optional uncompressDecryptedMessage parameter, andencryptTo accepts an optional compressMessageToEncrypt parameter, default true.INCOMPATIBLE changes:BroadcastTransaction has been modified to optionally accept all parameters thatare needed to create a prunable plain or encrypted message (client sideencryption only). This is required because the data for such messages is nevera part of the transaction bytes themselves, so trying to broadcast a transactionthat has a prunable part by only submitting its bytes to broadcastTransactionWILL FAIL, unless the corresponding parameters necessary to add the prunableparts are also supplied. Note that they need to exactly match the originalparameters with which the transaction bytes have been created and signed.For non-prunable messages, broadcastTransaction behaves as before, but usersare encouraged to start switching to prunable messages in view of the plannedsize restrictions and fee increases.The EncryptedData java class no longer handles compression internally, this isleft 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 nowpossible to create a transaction with a deadline of up to 32767 minutes. Thishas been done because many use cases of phasing require that the transactionbytes are prepared much earlier than the actual broadcasting of the transactionto 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.-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.12 (GNU/Linux)iQIcBAEBAgAGBQJVKXMXAAoJEFOhyXc7+e2ASF0QANeCGGCwaVVDi0i4YWvUVsADpUcy8R2NIvInbbL4dbYkfb8ZW2NaSws39hbCs7OPAGmR76JeOXRyTxyqimidGSpHOAaupcnyEnz2bA3v/+orC8Nphaqh8HlvUffya940vn8G58y9FW5a6bnJYopB1C7xNgE8NoUq8QnTu18zO/+KtNm7ymtAAwkCd5j25mpG9r2aalH31cf1YQ9NeKe1vO/GqIfbOGfan0l1e08m3bzP1q71Lk/Brcioq5u6igRu1kRrdew2tg9NqcumsQN9s0YYm1akOEpHfuAJZY2tjezOaZjRbPfr3JIBzlra7gIdSMcdA0OEFRNpb3cGqLfOQ82SHPKoOjAQjTgDPzHmzjunFKyJiC7LFTDAtypg/Ko3bMxLghwAuWDtbwZYEptvEDzulhMB3UeGwrEYRsZtOVEa5fVXbqsascVtSAI/Zje+TeX+HOMfLob2rkpx1tC1jmBJYE6L32BfO+l4qooslgnbGFBCFHf3oyVle2bn+/2RMd6d56CvTQrpTC/pWFK2fpeOJIPLBtkb/la/uS72AAZi7Uc9MGij+yWsJ9FZt9MKAPSXy8idYf8LcuAjFMflzXWyELHYz0U1yx4bciiO4Dx5raff7l1YsZ5j9+gIgo8iDP+pAw7sdU0Gv9e4zqkfyhq7MK3oyuBnk9cGGwztb+QS=8f8Y-----END PGP SIGNATURE-----