Quote from: electronicash on September 05, 2016, 02:35:27 AM

Quote from: Sall on September 04, 2016, 03:35:16 PM

Superior technology? I think you should watch this thread: https://bitcointalk.org/index.php?topic=679791.0 Wink

why is Navajo a much better coin than the rest?
Price doesn't say so but yes Nav is listed to a lot of exchanges, thats a good sign. Can you further tell us why is this a better coin than SDC and XMR?

Quote from: pakage on August 29, 2016, 09:42:22 AM

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:

http://i.imgur.com/saHxf5T.jpg

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:

http://i.imgur.com/PZSN9Nr.png

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':

http://i.imgur.com/p3anzYr.png

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.