[This is a critical bugfix release. Everyone is required to update.]

May I draw your attention to Jean-Luc's release notes from the latest stable version of Nxt's NRS software:

Change log:

This is a critical bugfix release. Everyone is required to update.

Jean-Luc is good at looking out for Nxters security (like when the critical Jetty bug was announced and Jean-Luc patched Nxt within 24 hours in version 1.4.16) So.... it makes sense to listen to him  

When a large botnet or virus is found on many computers around the world making them vulnerable, the biggest most responsible antivirus companies have patches out very quickly and you are expected to upgrade for your own good.

If not, you are putting yourself at risk as a known exploit might be used against you. This is the same situation   The nodes that aren't running the latest NRS, you are at risk from a known bug. Not to try and scare you but you are putting yourself at risk when there is no need to  


So... moral of the story: Do the smart thing and upgrade to the latest version!  

You can do that here: https://nxtforum.org/nrs-releases/


LATEST STABLE VERSION IS: NRS v1.5.10 as of 7th June 2015

That is all  

Question in the title 

I feel like I am missing something here..

[Blockchain Pruning]

Blockchain Pruning to be included with the next release of Nxt. This will drastically reduce blockchain bloat in future, compared to the blockchain so far


Source: https://nxtforum.org/nrs-releases/nrs-v1-5-1e/

Release 1.5.1e

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.

Even if it promised you great things? How long can a crypto survive being closed source? Is it recommended? Can it be compatible with the 'culture' of crypto today?

Answers on a postcard  

Question is in the title, I am interested in your thoughts...  

This topic has been moved to [Altcoin Mining].

https://bitcointalk.org/index.php?topic=929548.0

[EGOLD]

TL:DR:


On the 10th January, Nxt launched the long awaited Monetary System feature.

This allows POW coins to be mined inside Nxt's POS system and is a first. The name for this class of minable coins have been called MSCoins.

So, the steps to follow are:

1) Download the latest Nxt software to be able to connect to the network. Select the latest version from here: https://nxtforum.org/nrs-releases/
2a) For CPU windows, follow the instructions here: https://nxtforum.org/monetary-system-153/how-to-setup-miner-for-windows/
2b) For GPU guys, start here: https://nxtforum.org/monetary-system-153/nxtmint-java-minter/
3) Choose your MScoin to mine. EGOLD, ELEMS or any other from: https://nxtforum.org/monetary-system-153/
4) Take care not to set your rig up to burn though your Nxt in fees. A balance has to be struck between how many coins you mine and how frequently. A fee is paid for each successful mine, to record it in the blockchain. Mine 1 coin every min will cost 1Nxt/minute and you won't be making anything when you try to sell for profit. Understand this point before your start. It would be better to mint 50 or 100 coins at a time, it will take longer but you pay much much less in fees.

5) Get mining!

I am here for questioning.
***

Extra information:

There is a learning curve and you have to know what you are doing before you start, but the rewards are there for the early adopters of this new and growing mining class.


For those who are willing to take the plunge, more information on how to get started can be found here for CPUs on windows: https://nxtforum.org/monetary-system-153/how-to-setup-miner-for-windows/


There are already POW coins that are well known in Nxt and being mined as they were the first, with more being added everyday:

EGOLD - https://nxtforum.org/monetary-system-153/(ann)-egold-1st-mintable-keccak25-coin-zero-premint/

ELEMS - https://nxtforum.org/elems/(ann)-elems-1st-mintable-scrypt-coin-no-initial-supply-fair-distibution/

SILVR - https://nxtforum.org/monetary-system-153/(ann)-silvr-1st-mintable-ms-copycoin-keccak25-asic-proof-mining-low-diff/


Full list of MSCoins [ANN]s can be found here (not all are mineable): https://nxtforum.org/monetary-system-153/



You will need a small amount of Nxt to pay transaction fees, which you can mine at hashrate.org or buy them on BTER/BTC38/Cryptsy/HitBTC/Poloniex/Bittrex.


Those who want to GPU mine, there has already been the first GPU miner developed: https://nxtforum.org/monetary-system-153/nxtmint-java-minter/


So, the steps to follow are:

1) Download the latest Nxt software to be able to connect to the network. Select the latest version from here: https://nxtforum.org/nrs-releases/
2a) For CPU windows, follow the instructions here: https://nxtforum.org/monetary-system-153/how-to-setup-miner-for-windows/
2b) For GPU guys, start here: https://nxtforum.org/monetary-system-153/nxtmint-java-minter/
3) Choose you MScoin to mine. EGOLD, ELEMS or any other from: https://nxtforum.org/monetary-system-153/
4) Take care not to set your rig up to burn though your Nxt in fees. A balance has to be struck between how many coins you mine and how frequently. A fee is paid for each successful mine, to record it in the blockchain. Mine 1 coin every min will cost 1Nxt/minute and you won't be making anything when you try to sell for profit. Understand this point before your start. It would be better to mint 50 or 100 coins at a time, it will take longer but you pay much less in fees.

5) Get mining!



Those on Linux, Mac etc. I am willing to help you get up and running and be a point of contact to get some help from others as required.


Please ask questions if you are unsure. This is a new and growing opportunity for miners.

[this thread began in the Bitcoin General section]


I have a crypto currency in my mind. Here are the fundamental properties:


***
The number of nodes in the network is limited to 95, so not all users will have the opportunity to secure the network themselves.


Opinions on the biggest decisions (i.e. increasing the limit on nodes) can be expressed by the users but they are none binding, as the devs who run a proportion of the nodes would have to agree first and then write the fork with a new upper limit of nodes.


Users can change the devs/node runners and replace them with new ones, (i.e. Replace Bitcoin Dev Gavin with someone else who is deemed better) by a ballot. Devs/node runners can run more than 1 node by default if users allow it. If users decide 1 entity = 1 node max, it may be hard to enforce (different online IDs belonging to the same person would have to be detected) but we can do RL passport checks etc to confirm identities are independent before allowing eligibility to be included in the node ballot.


The devs will always run a proportion of the nodes, as they get an income from running a node. There is nothing stopping devs becoming users and taking part in the ballots using tokens they buy.


***


Would you call my set-up decentralized?


I can answer questions to clarify anything, if required. You can change your vote later, if any discussion changes your mind.

Thanks in advance for your opinions  

The pieces fit!!!  

As I understand it, the MaidSafeCoin tokens are secured on by the Mastercoin blockchain. I am aware you can trade them on centralised exchanges (Polo) but they too must record changes on the Mastercoin public ledger. So does it follow that the success of MaidSafeCoin relies on the success and continuation of Mastercoin?

I presume MaidSafe will launch and separate from Mastercoin at some point, anyone know when this will be? Is anyone still involved in Mastercoin to comment?

Seems strange a $20M marketcap is dependent upon people caring about the continuation of platform that is less than 10% its size and you don't hear much of. If the Mastercoin network folded, the trustless record of who owns which MaidSafe fractures with the inevitable fallout. Seems like a little understood risk to me, unless I am missing something.

It is of course true any asset is reliant on it's platform, but the risks with Mastercoin seem an order of magnitude higher to me.

Nevermind

[Nxt Whitepaper]

Contrary to popular opinion, Nxt has had a whitepaper for several months (currently up to version 4 and another version expected)

Nxt also has a series of studies into forging and economics that others may find interesting. This thread is intended to allow anyone not registered on nxtforum.org to ask questions (or at least let me try to find answers for them   ).


Nxt Whitepaper
https://www.dropbox.com/s/cbuwrorf672c0yy/NxtWhitepaper_v122_rev4.pdf


Maths of Forging
http://www.docdroid.net/ecmz/forging0-5-2.pdf.html

Nxt forging algorithm: simulating approach
http://www.scribd.com/doc/243341106/nxtforging-1 (scroll down to read)

PoS forging algorithms: formal approach and multibranch forging (Nov 2014)
https://nxtforum.org/consensus-research/multibranch-forging-approach/
(https://www.scribd.com/doc/248208963/Multibranch-forging)

PoS forging algorithms: multi-strategy forging and related security issues (Dec 2014)
https://github.com/ConsensusResearch/articles-papers/blob/master/multistrategy/multistrategy.pdf

Simulation Tools for Forging Algorithms
https://github.com/ConsensusResearch/


Economic Parameters of Nxt
https://docs.google.com/file/d/0BwAGADgnQcrtdXE5MkF5S05oaHM/edit?pli=1

Nxt Network Energy and Cost Efficiency Analysis
https://docs.google.com/document/d/1J8uhdshu9epGRrQHBaloGc4itdvuAHZDAUtNDjOhz-8/edit


https://www.scribd.com/collections/13142814/Nxt-Theses

https://www.scribd.com/collections/13142807/Nxt-Articles

https://nxtacademy.academia.edu/NxtAcademy


Source: https://nxtforum.org/general-discussion/nxt-papers-whitepapers-academic-and-economic/

[Development Roadmap]

Nxt has a long standing development plan that it has consistently delivered on (and more since there are features live today that were never in the plan)

The Nxt Development plan was created in partnership with Come-from-Beyond and based on the notes passed to him by BCNext. This thread will allow you to discuss each feature and become acquainted with future features before they are released.

The most up to date (and pretty    ) development plan can be found at nxttechnologytree.com

Development Roadmap

Disclaimer:
The NXT developers provide no commitment to deliver any of the features described herein, and reserve the right to change this product roadmap from time to time at their sole discretion.

NXT 1.7 (Dec 2015)
Coin shuffling
Account control for phased transactions
Immediate execution of phased transaction on approval
Stable block times, 60 s average, max 10 min
Fee spreading and throttling of unique resource allocation
Account properties
Singleton assets
Mac installer

NXT 1.8 (April 2016)
Two factor authentication
Account transfer (panic button)
Account control
Controllable assets
Exchange API

NXT 2.0 (December 2016)
White label prunable blockchains

Source: https://nxtforum.org/general-discussion/%28marketing-business-and-development%29-the-tennessee-project-fundraiser/msg197291/#msg197291

CORE FEATURE RELEASE HISTORY
Guidance on how you can build your project on Nxt using some of its hundreds of APIs can be found here. Examples are also provided, making them simple and easy to use.
Nxt's full release note histories can be found here and here.


NRS v0.4.8 - LAUNCHED at block 30,000 (1st Jan 2014)

Transparent Forging - WIKI   |   Video Discussion   |   Advantages of Transparent Forging (Login Required)   |   Sub Forum



NRS v0.5.4e - LAUNCHED at block 40,000 (13th Jan 2014)

Arbitrary Messages - WIKI   |   Video Discussion


[Further feature history to be added, watch this gap  ]


NRS v1.1 - LAUNCHED on 11th May 2014
Fundamental change as attachments switched to being stored in the database as
byte arrays instead of serialized objects, allowing the database to shrink back even more (about 25%).
V1.1.0 Release Notes


NRS v1.2 - LAUNCHED at block 213,000 (~15th Aug 2014)
Nxt Marketplace (previously Digital Goods Store) - WIKI   |   Video Walkthrough
Alias Transfer
Encrypted Messages


NRS v1.3 - LAUNCHED on 14th Oct 2014
Fundamental change from storing derived objects in memory to storing in a database,
enabling scaling to much higher number of assets, orders, and goods, without requiring an ever growing
amount of memory for each node.
V1.3.0 Release Notes


NRS v1.4 - LAUNCHED at block 330,000 (10th Jan 2015)

Monetary System - Documentation   |   WIKI   |   Video Walkthrough
Minting (Mining) of Monetary System Currencies - Documentation   |   WIKI
Dividend Payments
Alias Deletion


NRS v1.5 LAUNCHED at block 445,000 (~6 Jun 2015)

Voting System - WIKI   |   Teaser   |   Video Walkthrough
2-phased transactions (Advanced Multisig) - WIKI   |   Video Walkthrough
Plug-ins/Apps System - WIKI   |   Video Walkthrough
Prunable Data (Plain, Encrytped & Tagged) - WIKI
Windows Installer
Offline Transaction Signing (Cold Wallet) support - Release Notes

I have been reading the NXT thread on https://bitcointalk.org/index.php?topic=345619.16820 for a while and just wanted to check something that made my ears prick up.

Specifically, on page 842 post 16825 by CfB. He said

"U'll get the secret phrase that opens the genesis account, everyone will be able to play a role of "BCNext"."

What did he mean by this? The genesis account started with and balance of 0 and went into negative "AntiNXT" when issued to the 73 founders.

If BCNext plans to give the passphrase away, does that others will be free to issue more NXT and each one would devalue the ones in circulations, causing inflation? Or is the genesis account capped at issuing 1 billion and if so, what would be the point of being able to access the genesis account? You can't send NXT (negative balance) and you can't receive NXT without it being destroyed.

Maybe I've got this completely wrong/misinterpreted/missed the joke.

Please could someone re-post for me in the forum above?

Thanks