Just make sure your wallet is either unlocked or "unlocked for staking". You can unlock for staking through the gui menu

I think its a matter of different approaches to anonymous transactions. We use a secondary block chain called a "Subchain" to direct and manage our anonymous transactions as they are encrypted, randomised and routed through the Anonymous Network. This approach is unique to Nav Coin and it has some inherent benefits, the primary one being its resilience. The system runs purely off two block chains, not relying on a database or any extra data storage to mark transactions as "waiting to process" or "processed". This means if our anonymous servers were blocked / deleted / taken down / destroyed or whatever, we could simply start up a new server somewhere else, restore the wallet.dat files and the servers would resume processing transactions without loss and without needing to worry about backing anything else up apart from the wallet.dat files.

Secondly, because we use two block chains, we are able to break the transaction chain between sender and receiver. We have a pool of NAV waiting to be sent on the outgoing server, which can be sent as soon as the outgoing server receives the instruction from the subchain. It doesnt have to wait for the real NAV to arrive because of the nature of how block chains work and the way the server is coded, we can trust the amounts recorded to the subchain as correct and send the amount of NAV from the pool before the sent NAV arrive. This means the NAV recieved are not able to be traced back to the NAV which were sent no matter how hard you look at the NAV block chain.

Third, we are coming fast to the point where we can decentralise the anonymous network and allow other users to setup their own processing servers. When this happens, users will be able to earn NAV for processing transactions and we will become the first fully decentralised, double encrypted, anonymous system running purely off block chain tech! Wow, what a mouthful!

So that's the technology, lets talk about features.

We are working towards being the first anonymous crypto which can send anon transactions from the mobile wallet. That will be massive. As well as anonymous merchant integrations, the raspberry pi staking unit and a few other things currently on our road map: http://www.navcoin.org/projects

Even if you were just to consider us to have the same features as DASH or XMR, then that still makes us hugely undervalued by at least 10x - 100x

By the way, i think the other anon coins are great and you should definitely look into them. See if they fit your needs and if the technology fits your ideals. Having multiple options in the financial privacy sector of cryptocurrencies is definitely a good thing. If there was just one, then firstly there is no competition to innovate and secondly it becomes a single point of failure. We offer a secure alternative, based on different technology served in a way which we believe is the best approach. We are part of the array of tools you can use to protect your financial privacy on the internet and we support the efforts of all the other anon coins.

That's my 2c anyway

It can take some time, remember we have 30 second blocks, so 3 weeks = 60480 blocks; the equivalent of more than 1 years worth of BTC blocks.

We will get a more recent block chain up on the website for you as soon as possible.

I suggest having a navcoin.conf file with the following settings to speed up the syncing:


Where the addnode=xxx.xxx.xxx.xxx entries are all the nodes found here:

https://chainz.cryptoid.info/nav/#!network

click on the [ nodes ] button next to /NavCoin:3.6.0/

Hey again

I can understand how you feel, we are also disappointed this has happened. I hope the Nav Community members have read our posts here and realised what they did was not cool and completely unnecessary. We are all on the same team in my opinion and we should all support each other in our efforts to disrupt the corrupt banking establishments however we can.

I'll send you a message when we push out our next release with the redundant code removed and the acknowledgements written up. If we've missed anything at that point, please just let us know. We do try our best to preserve accreditation but its easy for it to get lost when so much is shared around.

I'd also be glad to get some feedback on our anonymous system and decentralisation there of. I aim to put out updated whitepapers in the next couple of weeks! Thanks for the offer!

All the best,
Craig.

inside ~/.navcoin2/

you will find wallet.dat

this is your wallet file

We're still figuring out the best approach and will happily publish all the details once we've figured out what they are. We aim to have a low barrier to entry, but we also need to maintain the integrity of subchain and make sure its not worthwhile for people who posess subchain coins to attempt to use them maliciously to extract nav coins from other anon servers. You can hopefully appreciate the quagmire caused by handing out the subchain coin which we use to direct real nav coin transactions.

In terms of running it on Raspberry Pi I don't know if that will be possible. From my experience, raspberry pi's struggle to run one bitcoin daemon, let alone two at the same time. We will put together some minimum spec suggestions when we bundle it for release. Shahim can probably speak to the current server specs which we run our servers on.

Yes, I believe this approach is going to give us decentralisation much sooner than previously expected and also provide a more secure environment by allowing users to choose which anon servers they use.

More details to come

OSX wallet is on the list, soopy is looking into fixing the make file for it this week!

Yeah this is correct. Anyone who wants to participate can.

There will be some technical skills necessary because the system will need to run the navcoind and subchaind daemons which are compiled on Linux. It should be accessible to anyone with some basic Linux experience and we will fully document all the setup steps.

The other consideration is that we will need to distribute the subchain coins as they are the fuel for the anonymous transactions. However they are essentially redeemable for Nav at 1:1 and we need to protect the system from abuse. The solution Dash implemented in this regard is to get their anon participants to put forward a deposit which is refundable when they stop participating. We are currently looking at various solutions to this problem and will release full details closer to launch.

Yes, whoever sets up a server will earn the percentage from the anon transactions which that server processes.

The current idea is that similar to how you configure the TOR nodes in your navcoin.conf file, you will be able to add also the anon server addresses you wish to use. This gives the users the ultimate control and responsibility for which servers they trust and use.

We will offer the official navcoin ones which anyone can use but if your mate sets up a server you want to use instead you can use that by simply updating your configuration file.

We are implementing as many security checks to the system as possible, attempting to mitigate any possible attacks but in the end of the day trust will need to be built between users and whichever servers they decide to add because it is impossible to patch every single attack vector in a decentralised system like this.

As mentioned, I will be putting out updated whitepapers on  both the anon system and decentralization which will fully explain our implementations in the near future.

Hey Kwede,

I am sad to hear some NavCoin community members have been throwing mud at your project. That is not the spirit in which we operate here! We are always pleased to see other devs doing great work anywhere in the block chain landscape and especially in the financial privacy area. ShadowCash is a great project and you guys have built a lot of great features which help protect peoples financial privacy which is something we firmly believe to be a basic human right like the freedom of speech. We have a lot of respect for your team and what you do!

In regards to the use of some of ShadowCash's features, we are happy to pay credit where credit is due. There are actually a lot of redundant features in the code base which are never used by the UI. For example, we dont actually implement stealth addresses or the masternode system but the code is still dormant in the base because it was included in our original fork.

In an upcoming release, we will review which parts of the code we are actually using and remove the code which is unnecessary followed by detailed accreditation of the parts which are pulled in from other code bases. I don't believe we forked ShadowCash directly for the foundation of the wallet code, but perhaps the wallet we forked did.

As with all open source projects, and especially in the bitcoin space, this is common practice. However, we want you to know that we aren't intentionally using any of your proprietary features without due accreditation and we don't use your system for our main anonymous features.

The Anonymous system we implement is entirely unique to NavCoin and is not based on the ShadowCash tech. We have built that ourselves from the ground up.

Thanks for the heads up, and we hope our communities can build each other up in the future instead of slinging mud!

Best Regards,
Craig

Currently the anon system is closed source but we will open it when we decentralise

From my brief understanding, Coin Join is still technically transactionally linked, they just add a bit of misdirection in between sender and receiver. Its kind of like saying that I have $5 and you have $5 and we take both our $5 and swap it for a $10 note at the bank, then we take that $10 and get it changed into 2 differnet $5 at another bank and I buy an ice cream and you buy a can of coke. The $5 we used to buy icecream and coke isnt the same $5 each of us started with but in terms of bitcoin, all the data showing the inputs and outputs is available on the public block chain and is traceable just as if the bank recorded the serial numbers of the notes when we exchanged them. Using the example I have created, you probably couldn't (beyond reasonable doubt) prove it was me who bought ice cream and you who bought the coke. But you could say that One of us bought ice cream and one of us bought coke.

The difference of our system is that we use two block chains, which is kind of like using 2 currencies and it doesn't require a third party to join with. Its more like saying that I have $5 and i go on holiday to Russia, while there, i go to a foreign exchange desk and change the $5 into Roubles. I then give the Roubles to a friend of mine i meet with in Russia who privately changes it back into $5 for me from money he has under his mattress. He then flies to the US while I'm still in holiday in Russia and meets with my friend who I owe $5 to and pays the debt for me.

With this analogy, it is much much harder (i would say impossible) to prove that the $5 my friend received originated from me. I'm not even in the country when he receives the $5!

I hope this makes sense?

To answer your other questions:


When your wallet finds an active anonymous receiving server, the server checks that its Nav Coin and Nav Subchain wallets are running then it finds the latest generated public key and sends it back to your wallet as part of its 200 OK response. Your wallet then uses this public key to encrypt the transactions intended recipient address then sends the transaction to our servers wallet address with the encrypted recipient address attached.


RSA Private and Public keys are generated in pairs. Only the private key from the same pair can decrypt data which was encrypted with a particular public key. So if i send you publicKey#1 from my server and your wallet encrypts some data with it, then only privateKey#1 from my server can decrypt the data you've encrypted. No other private key on my server or anyother server can decrypt that data. We only ever send out the public key for wallets to encrypt with, we never send anyone the private keys. So there is no danger of someone else being able to decrypt the data which has been encrypted with the public key. We also only use a key pair for a short period of time then we generate a new pair to use. We also delete unused key pairs after a certain buffer period so that we cant access your transaction history, even if we wanted to.

Again, i think this is pretty straight forward. Instead of sending NAV from A to B, we encrypt address B and send the money to one of our servers with the encrypted address B attached to the block chain transaction. Then the rest of the magic happens iwth the subchain etc..


I'm not sure i can explain this very simply. It is best explained by the diagram.



In a regular Nav transcaction, NAV go directly from NAV(send) to NAV(dest). With our system NAV(send) encrypts NAV(dest) and makes a transaction to NAV(in). NAV(in) listens for incoming transactions, decrypts NAV(dest), asks NAV(out) for its encryption key, rencrypts NAV(dest) with the NAV(out) public key and creates random transactions using SUB(out) which have the reencrypted NAV(dest) attached and add up to the correct amount. These transactions are sent to SUB(in) which decrypts NAV(dest) and instructs NAV(out) to send the correct amount of NAV to NAV(dest).

I will try to draw a better flow diagram when I have the time. I think I am even going to re-do the white paper for both anon send and decentralisation in the near future.


We pre-load each receiving server with 100,000 NAV and 100,000 SUB, so when the instruction comes (via the subchain) to send 100 NAV to NAV(dest), the transaction is made using the coins from this pool. The coins which NAV(send) originally sends will eventually join this pool of NAV on NAV(out) to replace the ones which were sent and will be used for future transactions as needed.


The receiving and sending servers both work directly by reading unspent transactions on the block chain, there's no database or other datastore necessary to keep track of which transactions they have processed. Once a transaction is processed, it is literally "spent" on the block chain and the wallet knows it has completed processing that transaction.

So since it runs purely off the block chains it is completely restorable. Just like how I could set your laptop on fire and as long as you have a backup of your wallet.dat file and there is at least 1 copy of the Nav Coin block chain out there somehwere, you are able to recover your Nav Coins on a new machine. If we lost a particular server, as long as we have the wallet.dat of the server backed up, we can restore the server and it won't even lose any transactions that were sent to it. It will just look at the block chain, find the latest unspent transaction and begin processing again.

phew, some big concepts in there. Don't be worried if you dont get it all immediately. Im sure it will sink in over time and we are working towards demystifying the technology as soon as possible.

I hope this helps though!

I will respond to your questions during my lunch break today

Hi Nav Coiners,

Time for the weekly update from the Team.

When we last reported I had completed the first cut of the brand new Anonymous Transaction System. This week I have been focusing on refining the first cut of code to make sure everything is accounted for and there are no possible errors. Everything seems to be working great so far and I have sent a bunch of successful transactions over the test net!

For anyone wondering how our anonymous system works, I would like to attempt to explain it. We are unlike any other Anon Crypto in the market and we are definitely not just DASH with extra bells and whistles as has been quoted in this thread. Hold on to your hats, this is the definitive answer of how our system works. It's complicated (and long sorry) but its important..

Instead of sending coins directly from Address A to Address B (like a regular Bitcoin), or from Address A through Addresses X,Y,Z to Address B (like a mixer or Dash), our system uses double encryption and a secondary block chain (Nav Subchain) to securely and fully anonymously send transactions through our network. From a user perspective its very easy to use. All you have to do is tick the "Send NAV Anonymously" box and click send. There's no pre-mixing, there's no command line gobbledegook. Just tick the box and press send.

When you choose to perform an anonymous send, firstly your wallet asks one of our Anonymous receiving servers via HTTPS for a short lived RSA public key. Address B is then encrypted by your wallet with the public key the receiving server sent. Address B is never broadcast from the Address A's wallet over the network in an unencrypted stated, not even over HTTPS which has been proven to be vulnerable (read: heartbleed). If you understand about RSA Public / Private keypair encryption, it is by nature asymmetric. The public key which we send out can only be used for encrypting. The public key is physically incapable of decrypting data so there's no security issue with broadcasting the public key to Address A's wallet over HTTPS. Only the server which issues the public key is able to decrypt with the private key, which never leaves the server and which are periodically deleted. So after a short period of time, it is literally impossible even for the server which sent the public key to decrypt Address B.

Once Address B is securely encrypted by your wallet, the coins are then sent from Address A to a wallet address owned by the Anonymous receiving server which provided the RSA Public Key to your wallet. The encrypted Address B is attached as an extra argument on the Nav Coin block chain transaction itself. There are no sql databases involved, all data storage is happening on the block chain and by the very nature of how block chains work, is decentralised.

When the receiving server sees the unspent Nav transaction in its wallet, it decrypts attached Address B with the private key which matches the public key it sent to Address A's wallet, then communicates to one of the Anonymous sending servers to repeat the initial task. It asks the sending server for its own short lived public RSA key which the receiving server then uses to re-encrypt Address B. The receiving server then creates a random amount of randomly valued transactions NOT on the Nav Coin block chain but on the Nav Subchain (which is an entirely separate block chain). These transactions all have a freshly re-encrypted version of Address B attached them and are sent to random addresses owned by the chosen Anonymous sending server.

When the sending server sees the unspent Nav Subchain transactions arrive in its wallet, it decrypts attached Address B, adds up the transactions, re-randomizes the number of transactions and transaction values and creates them as real Nav Coin transactions back on the main Nav Coin block chain. These coins are taken from an existing pool of Nav Coin which are stored on the server and are not the original coins sent from Address A.

In fact, the Nav which Address A sent are only ever used to replenish the Nav pool on the sending server for future transactions, they are never used in the same transaction chain as what end up in Address B. This is how we explicitly break the link between Address A and Address B on the Nav block chain.

Think of the Subchain as a transaction director rather than actually performing transactions itself. Receiving severs use the subchain to instruct the sending server who to send Nav to and how much to send.

The reason we use a Subchain as the transaction director between servers is that it maintains all the advantages of a decentralised block chain and none of the risks of relying on a corruptible, hack-able database server or direct (read: intercept-able) communication.

If someone were to literally burn our anonymous servers to the ground, as long as there is still a copy of the Nav Coin and Nav Subchain block chains out there somewhere, we can restore their wallet.dat(s) to new servers and they will resume exactly where they left off at the oldest unspent transaction in their wallet. Ahhh, the beauty of block chain technology! I don't miss the horrors of MySQL for one moment!

I've drawn this diagram as a (over) simplified way to visualise what I am talking about:



The important points to remember are that the sent Nav and the received Nav can not be transactionally linked on the same block chain. Any information that is transmitted along the subchain is randomized and re-encrypted so it can not positively identified as connected to the original transaction on the Nav block chain. All encryption keys are only used for a short period of time and then deleted, making all expired transaction records impossible to decrypt.

I know this is confusing as hell if you're not a tech-wizard, Sophia and Mark are working on a layman's translation of this information for a press release as we speak.

For those who weren't around for the last iteration of the Anon system, here is what an anonymous transaction looks like in the transaction history:



You can see at 28/08/2016 20:22 I send 100 NAV to address NegpeVty... (an anonymous receiving address) and then at 28/08/2016 22:13 I received 7 transactions of various amounts which total to ~99.4 NAV (100 - 0.5% anon processing fee - regular transaction fees).

If I open the transaction details of the sent 100 NAV you can see the encrypted Address B (which in this case was my own address) attached here to the block chain transaction as 'anon-destination':



You will notice these sent to and receiving transactions are nearly 2 hours apart, this is only because I am running the Anon network in test mode where I am manually inspecting and running the scripts while I debug and refine the code. In reality it would be a maximum of around 5 minutes between Address A sending and Address B receiving.

In regards to my progress, you can see here I have successfully sent and received transactions through the new Anonymous network. I am finishing my refinements this week and myself and Shahim will begin to deploy and test this on the live network next week. Once we are happy the live network is operating without a hitch we will open it to the public for use. We have not set an official launch date yet as we do not have crystal balls to predict what problems may arise when we begin live testing. We will keep you all posted with our progress and attempt to release the live network as soon as is practical and safe.

Once the new anon scripts are live, I think that will jump us to approximately 80% complete on the decentralisation project progress. I will immediately continue to work on that with the intention of getting that released as soon as possible. Hopefully you can see that the nature of the technology is very complex in itself and when you combine attempting to safely decentralise the system, it becomes exponentially more difficult. However, I believe that I am very close to a working solution for decentralisation and am confident that I can get it out there within a reasonable timeframe.

In the mean time, Soopy has been working on a fix for some of the syncing issues users have been reporting on the desktop wallet as well as investigating the compiling issues of the OSX wallet. Soopy and Shahim have been testing the thin desktop client which we also hope to release soon. Sophia, Mark and Strugg have been working hard on our marketing strategy, preparing press releases and marketing materials for our upcoming feature releases (thin client, mac wallet, anon-relaunch and decentralisation).

Everyone is working hard to pull this all together and we are glad to have you all along for the ride as supporters, investors and friends.

Till next week, please keep the questions coming and we will endeavour to answer them all.

Talk soon,
Craig.

The last publicised update was the Tor nodes which required no modification to the wallet source as we already accounted for it when we relaunched NAV2. Prior to that, we also released the Android wallet, which again required no update to the main github.

I am currently working on relaunching the anon network on a new tech stack in preparation for releasing it for decentralised use. But until i have tightened it for decentralisation, we do not have the anon server source on a public repo.

I have successfully sent anon transactions using the new code base and will be posting my weekly update about the teams progress later today. We're pretty close to relaunch all going well.

Cheers,
Craig.

Hi Nav Coiners, its time for the weekly update!

It's been a busy week at the Nav Headquarters. I've been working hard to get the new Nav Coin Anon System up and running. I have successfully sent coins that have been anonymised using the new system via the test net. This project now moves into the testing and refinement phase before we can relaunch the network.

As with any software, there are always refinements and optimisations to be made after the first working version is complete. I will be working this week to improve and strengthen this system. It is what we will end up distributing for decenrtalized anon network, so I want to make sure that it is perfect.

Strugg has emailed the TOR article to several news outlets and have been awaiting their publication. Meanwhile Sophia and Mark have been working on articles for our upcoming releases; Anon Network Relaunch and the Desktop Thin Client.

Soopy and Shahim will have to update us on their progress towards their projects (thin client, web wallet and raspberry pi) when they are available to do so.

Apart from that it's been a busy week with lots of progress happening in the background.

Sophia and Mark are settling into their roles and starting to provide some real value to our overall marketing strategy.

Talk Soon,
Craig.

You can try adding the latest nodes to your navcoin.conf file. You can find the nodes here:

https://chainz.cryptoid.info/nav/#!network

click the [ nodes ] button next to 3.6.0

Paste all of these into your navcoin.conf file found in your %AppData%/NavCoin2 folder

Then make sure you also set maxconnections=10, otherwise you will flood with too many connections and also go slow.

Another good setting for your conf file is: maxorphanblocks = 10000

It is a reality that we end up with a large amount of orphans because our block time is only 30 seconds, so limiting these is a good way to manage the wallets performance.

Hopefully that helps,

While we're very confident no one can irrefutably trace transactions which route through the anonymous system, it wouldn't be the end of the world if the bounty were claimed. The idea of bounties are that they attract very smart people to try and think of abstract attack vectors and companies reward these people for discreetly showing the flaw so it can be patched to help the product become even stronger.

I guess though you're right in a way. If someone can undeniably trace a NAV Anon transaction it means they can crack RSA encryption and basically the whole internet is fucked lol!

It's there: http://www.navcoin.org/bounty

It should be automatic, the bounty page reads from the chainz.cryptoid.info API. Perhaps the API is lagging behind the actual block explorer? Not sure.