elective-stereophonic
elective-stereophonic
NRS v1.5.1e singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Pages: [1] 2 3 4  All

Author Topic: NRS v1.5.1e  (Read 17079 times)

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
NRS v1.5.1e
« on: April 11, 2015, 07:54:59 pm »

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 1.5.1e

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.5.1e.zip

sha256:

7f56babc8bce1ab12117dea86c0225611bb6eb86796de6c7869438a575523722  nxt-client-1.5.1e.zip


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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVKXMXAAoJEFOhyXc7+e2ASF0QANeCGGCwaVVDi0i4YWvUVsAD
pUcy8R2NIvInbbL4dbYkfb8ZW2NaSws39hbCs7OPAGmR76JeOXRyTxyqimidGSpH
OAaupcnyEnz2bA3v/+orC8Nphaqh8HlvUffya940vn8G58y9FW5a6bnJYopB1C7x
NgE8NoUq8QnTu18zO/+KtNm7ymtAAwkCd5j25mpG9r2aalH31cf1YQ9NeKe1vO/G
qIfbOGfan0l1e08m3bzP1q71Lk/Brcioq5u6igRu1kRrdew2tg9NqcumsQN9s0YY
m1akOEpHfuAJZY2tjezOaZjRbPfr3JIBzlra7gIdSMcdA0OEFRNpb3cGqLfOQ82S
HPKoOjAQjTgDPzHmzjunFKyJiC7LFTDAtypg/Ko3bMxLghwAuWDtbwZYEptvEDzu
lhMB3UeGwrEYRsZtOVEa5fVXbqsascVtSAI/Zje+TeX+HOMfLob2rkpx1tC1jmBJ
YE6L32BfO+l4qooslgnbGFBCFHf3oyVle2bn+/2RMd6d56CvTQrpTC/pWFK2fpeO
JIPLBtkb/la/uS72AAZi7Uc9MGij+yWsJ9FZt9MKAPSXy8idYf8LcuAjFMflzXWy
ELHYz0U1yx4bciiO4Dx5raff7l1YsZ5j9+gIgo8iDP+pAw7sdU0Gv9e4zqkfyhq7
MK3oyuBnk9cGGwztb+QS
=8f8Y
-----END PGP SIGNATURE-----
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +589/-588
  • Offline Offline
  • Posts: 3093
  • Karmageddon
    • View Profile
Re: NRS v1.5.1e
« Reply #1 on: April 11, 2015, 08:00:12 pm »

Nice!
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3

abctc

  • Hero Member
  • *****
  • Karma: +148/-13
  • Offline Offline
  • Posts: 1396
    • View Profile
Re: NRS v1.5.1e
« Reply #2 on: April 11, 2015, 09:10:39 pm »

Great!
Logged
Welcome to the Nxt generation of crypto!   Magis quam Moneta (More than a Coin)
"Do not worry, it is an attack" (c) Jean-Luc

semibaron

  • Sr. Member
  • ****
  • Karma: +16/-7
  • Offline Offline
  • Posts: 333
    • View Profile
Re: NRS v1.5.1e
« Reply #3 on: April 11, 2015, 09:13:54 pm »

Last releases were big. Does the Notification System got removed?
Logged

lucky88888

  • Hero Member
  • *****
  • Karma: +42/-14
  • Offline Offline
  • Posts: 694
  • NXT-E328-UJDF-KTGH-9C6YQ
    • View Profile
Re: NRS v1.5.1e
« Reply #4 on: April 11, 2015, 09:19:41 pm »

wow you are a true genius! look at the way you make all these features come to life!
Logged
NXT-E328-UJDF-KTGH-9C6YQ
8897013707391239174

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: NRS v1.5.1e
« Reply #5 on: April 11, 2015, 09:19:59 pm »

Cool! Great Work!

I have a question. Would the method to prune the message, ie store only the hash in the long run, could be apply to all Nxt transactions? I probably do not understand the underlying methodology, but still asking tho. 
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.5.1e
« Reply #6 on: April 11, 2015, 09:23:58 pm »

Last releases were big. Does the Notification System got removed?
No, notifications for new transactions, messages, phasing, are showing up there in the header. It is in the previous changelog:

Generic notification system for incoming transactions showing the number
of transaction types and total new transactions.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.5.1e
« Reply #7 on: April 11, 2015, 09:28:35 pm »

Would the method to prune the message, ie store only the hash in the long run, could be apply to all Nxt transactions?
No, not possible. Messages can be removed because internally nothing else depends on them. But almost all other attachments are needed to be able calculate the system state at later heights, as they affect account balances, etc.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

ThomasVeil

  • Hero Member
  • *****
  • Karma: +183/-11
  • Offline Offline
  • Posts: 1400
    • View Profile
Re: NRS v1.5.1e
« Reply #8 on: April 11, 2015, 11:59:50 pm »

Can't stop being amazed by the output! Great stuff once again.

Just out of curiosity: Does the  maxPrunableLifetime parameter mean there will be lots of different blockchains flying around?
Which one will a new node download? Assuming that some nodes will keep the full chain, then could I tell my node to get those? Else, if I would want to set up an archival node, I only could keep data from the moment of startup, no?
Logged
ARDOR-BPV3-837M-QZTQ-9DQ69  oxpal.com

slothbag

  • Sr. Member
  • ****
  • Karma: +74/-4
  • Offline Offline
  • Posts: 454
    • View Profile
Re: NRS v1.5.1e
« Reply #9 on: April 12, 2015, 12:23:10 am »

Trying out 1.5.1e now.. my first impression is that the UI is very busy now.. the initial login screen has many options, checkboxes, dynamic content depending on what you click/mouse over. Then when you log in its even busier with many dropdowns along the top nav, multiple notification dropdowns, the left nav has many options with sub options.. its great that Nxt is evolving so fast and has so many features we are running out of room to display them, but at the same time usability for novices must be taking a hit.

I'm actually thinking the opportunity for mass adoption of Nxt by non techies is probably gone, so perhaps having a complex UI is ok for those still building services on top of Nxt??

Edit: Or maybe I just dont like change :)
Logged

apenzl

  • Hero Member
  • *****
  • Karma: +246/-10
  • Offline Offline
  • Posts: 2493
    • View Profile
    • Nxter.org
Re: NRS v1.5.1e
« Reply #10 on: April 12, 2015, 12:51:32 am »

Thank you. Mind haven't stopped exploding.

Quote
Quote from: Jean-Luc on April 10, 2015, 03:29:22 pm
And I was just thinking that after prunable messages, my next idea, prunable tagged data, can be abused to host the pirate bay torrents on the blockchain…

Quote from: Cassius on April 10, 2015, 06:51:45 pm
Cool indeed. How would this work in practice?

Quote from: Jean-Luc on April 10, 2015,
Imagine the digital goods store UI, but no selling, buying, refunds or feedback. All items non-encrypted and viewable by anyone, but prunable and automatically deleted after some time. To make an item stay longer, anyone (not just the original poster) can pay a fee to extend the expiration deadline. This way useless stuff will go away (unless the poster keeps paying for it), and items (links, torrents, whatever) that people find are worth preserving will stay.

Each item will have name, description, and tags, and will be searchable by those and classified in a tag table just like in the DGS. And the item itself can be up to 42 kbytes, either text or binary.

In the pirate bay use case, we can't obviously upload and keep all torrents there on the blockchain, but this expiration with optional extension should hopefully ensure that only new and interesting torrents stay, the obsolete ones get pruned away. And listing fees and expiration deadlines should be adjusted depending on the data volumes we see. The point is that with prunable data, after it is pruned all that is left is a 32-byte hash (plus the regular transaction bytes which will be about the same as for an ordinary payment transaction).

Since the block payload limit remains at 44 kbytes, one can upload at most 1440 * 44 = 63360 kb = 62 MB per day. If expiration time is two weeks, for two weeks the blockchain will accumulate 866 MB of prunable content, and then it will stay at this level as any older data will get pruned. And this is the worst case scenario, if every single block is full to the max.

Note that forgers prefer to put in blocks transactions with higher fee/size ratio, in other words ordinary payment transactions will take precedence over data upload transactions (unless one pays a really high fee for that data upload one). So processing of regular transactions will not be harmed.

Quote from: box1413 on April 10, 2015, 07:39:16 pm
if this data storage method does get popular. its inevitable people will upload not so "legal" data. ex. classified data / "illegal" porn / other data not deemed "good"

this can very well be the kick to rattle the hornets nests...  i'd imagine the government / riaa / etc agencies will want to hold someone accountable.

i think there should be some type of plan if stuff gets out of hand assuming this thing gets widely popular.

everyone will just have to brainstorm of some possible scenarios.

Quote from: Jean-Luc on April 10, 2015,
I agree. But think also about the positive use cases - decentralized wikileaks, whistleblowers posting anonymously, or just sharing cool content that is currently popular - and goes away once nobody cares anymore.

In addition to paying to extend expiration, can also add a pay-to-remove feature, or vote to remove / vote to stay. But this is going into feature creep, it is better to start with something minimal and only add complication if needed.

Note that existing arbitrary messages, and especially the larger prunable messages coming, can also be used to host illegal or questionable material. And even the DGS can, and already has, fortunately looks like nobody is buying those so hopefully they won't stay.

After the prunable data expires, it doesn't exist anywhere, can't be renewed unless the user re-uploads the content.

Yes, if users keep extending the expiration, the blockchain will accumulate more than 866MB/two weeks rolling content. To prevent that, a renewal transaction may also be counted as occupying 42 kb (or whatever the size of the original data was), even though it doesn't. This way it will take space in a block to prevent potentially another upload transaction from being included and the total will stay constant.

Regular (non-prunable) plain or encrypted messages will still be supported, but to discourage their use the fees should be increased and/or the size limits reduced. For encrypting a message to yourself only, there is also the encrypt-to-self-note feature, for which I didn't make a prunable version as it doesn't seem useful.

slothbag

  • Sr. Member
  • ****
  • Karma: +74/-4
  • Offline Offline
  • Posts: 454
    • View Profile
Re: NRS v1.5.1e
« Reply #11 on: April 12, 2015, 01:31:07 am »

Sync'd a 1.5.1e node on testnet from scratch.  The GUI said 4300 blocks remaining even though when I checked the blocks it was fully up to date. I reloaded the webpage and re-logged in and the "downloading blockchain" progress bar disappeared.
Logged

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: NRS v1.5.1e
« Reply #12 on: April 12, 2015, 07:29:06 am »

Trying out 1.5.1e now.. my first impression is that the UI is very busy now.. the initial login screen has many options, checkboxes, dynamic content depending on what you click/mouse over. Then when you log in its even busier with many dropdowns along the top nav, multiple notification dropdowns, the left nav has many options with sub options.. its great that Nxt is evolving so fast and has so many features we are running out of room to display them, but at the same time usability for novices must be taking a hit.

I'm actually thinking the opportunity for mass adoption of Nxt by non techies is probably gone, so perhaps having a complex UI is ok for those still building services on top of Nxt??

Edit: Or maybe I just dont like change :)

Maybe a chech box on the login screen for advanced client features?
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.5.1e
« Reply #13 on: April 12, 2015, 07:56:27 am »

Does the  maxPrunableLifetime parameter mean there will be lots of different blockchains flying around?
No, the prunable parts should not be considered to be part of the blockchain. As nothing else depends on them, it doesn't matter if some peers have some more than the others. The common requirement for all is to keep them for at least the minimum lifetime.
Quote
Which one will a new node download? Assuming that some nodes will keep the full chain, then could I tell my node to get those?
Even if a node keeps prunable data longer, or indefinitely, after the minimum lifetime has expired they are not included in the transaction json when other nodes download the blockchain from it. This is for efficiency, the node does not try to load the prunable parts at all if the expiration time has passed, and for saving bandwith. If a custom peer still includes those after their expiration, others will just drop that data.
Quote
Else, if I would want to set up an archival node, I only could keep data from the moment of startup, no?
Yes, there is no way to get older data - unless somebody starts providing a service that does that.

When you keep prunable messages longer on your node, you can get them using the getPrunableMessage or getPrunableMessages APIs, for your own use. Public nodes can also expose those APIs for others to use, but they need a specific transaction id or account id parameters, they are not designed to be able to download in bulk all stored prunable data.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

crimi

  • Hero Member
  • *****
  • Karma: +122/-11
  • Offline Offline
  • Posts: 863
    • View Profile
Re: NRS v1.5.1e
« Reply #14 on: April 12, 2015, 08:25:23 am »

The 1.5 GUI is really slick and fun to use i think the plugin section will boost interest for third party developers again.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.5.1e
« Reply #15 on: April 12, 2015, 08:40:12 am »

I added getAllPrunableMessages API to be able to page through all. With this you could get them from a public node. And the maxPrunableLifetime will be exposed in getState and getBlockchainStatus, so you can first check if that node is keeping messages that old or not.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

ThomasVeil

  • Hero Member
  • *****
  • Karma: +183/-11
  • Offline Offline
  • Posts: 1400
    • View Profile
Re: NRS v1.5.1e
« Reply #16 on: April 12, 2015, 09:08:19 am »

Interesting. Thanks for the answer Jean-Luc.

I'm actually thinking the opportunity for mass adoption of Nxt by non techies is probably gone, so perhaps having a complex UI is ok for those still building services on top of Nxt??

I think the need to split the targeting for devs/traders vs. everyday users becomes more and more clear.
Likely best to not burden the NXT devs with both though.
« Last Edit: April 12, 2015, 09:11:40 am by ThomasVeil »
Logged
ARDOR-BPV3-837M-QZTQ-9DQ69  oxpal.com

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: NRS v1.5.1e
« Reply #17 on: April 12, 2015, 01:17:27 pm »

The common requirement for all is to keep them for at least the minimum lifetime.
Presumably this rule is enforced by the reference peer, not the core consensus mechanism. In other words, if I write a custom peer that prunes early, the blocks my peer forges could still be accepted by the NRS. Will my custom peer be blacklisted by NRS when NRS notices I am pruning early? Or am I misunderstanding something?

What are your thoughts on letting the creator of a transaction set the prune date for it? If I want my data in the block-chain for twice as long, shouldn't I just have to pay twice as much to make that happen? If I only need it there for an hour, why make everyone keep it longer?

I'm guessing if this takes off, people will want finer granularity than nxt.maxPrunableLifetime. I might want to keep all prunable data that relates to a particular set of accounts, for example. Or, I might keep 1% of everything; if 99 other people do the same, between us we'll have a complete history.

Anyway, this sounds like an exciting step forward for scalable storage which increases the potential of the block-chain. Good stuff.
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: NRS v1.5.1e
« Reply #18 on: April 12, 2015, 01:37:11 pm »

Trying out 1.5.1e now.. my first impression is that the UI is very busy now.. the initial login screen has many options, checkboxes, dynamic content depending on what you click/mouse over.
Some of that is to do with Testnet, and will disappear on MainNet.

Some of it is to do with Plugins. Perhaps the Active Plugins and Security Notice buttons should be hidden when Plugins are disabled. And perhaps Plugins should disabled by default. They seem a bit scary to me. The dire warnings in the Security Notice will either scare people away, or get them used to ignoring dire warnings.

Quote
Then when you log in its even busier with many dropdowns along the top nav, multiple notification dropdowns, the left nav has many options with sub options.. its great that Nxt is evolving so fast and has so many features we are running out of room to display them, but at the same time usability for novices must be taking a hit.
I don't mind most of that; it's hard to cut it down without losing stuff that will be important to some. I wouldn't want a simplified UI that excluded the Asset Exchange, for example.

However, I wonder if most of the big Dashboard blue boxes should be hidden if they contain 0. Quite a lot of space is devoted to telling me I have 0 assets, for example. The main Dashboard area would be less cluttered and more focussed if it only contained areas I had used in the past (plus the left-hand side list).
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.5.1e
« Reply #19 on: April 12, 2015, 01:54:50 pm »

The common requirement for all is to keep them for at least the minimum lifetime.
Presumably this rule is enforced by the reference peer, not the core consensus mechanism. In other words, if I write a custom peer that prunes early, the blocks my peer forges could still be accepted by the NRS. Will my custom peer be blacklisted by NRS when NRS notices I am pruning early? Or am I misunderstanding something?
If the prunable parts are pruned early, the block will be considered invalid and not accepted by anyone. Your peer will be blacklisted just like any peer that distributes invalid blocks for whatever reason.

Quote
What are your thoughts on letting the creator of a transaction set the prune date for it? If I want my data in the block-chain for twice as long, shouldn't I just have to pay twice as much to make that happen? If I only need it there for an hour, why make everyone keep it longer?
Some absolute minimum of about one day seems necessary, otherwise it cannot be guaranteed that all the peers received the data.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322
Pages: [1] 2 3 4  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly