OK first let me thank all who care about this coin. Due to the fact that I see no experienced dev come forward to take over the code and people expressed their opinions to release the source code, I released it now at github
https://github.com/supercoinproject/supercoin-p2p

So we have an open source now, anyone can maintain and continue developing it. I developed the p2p anonymous system with multisig technologies in a little more than a month time, it was an exciting and intense month that I spent a lot time developing the code and testing. A few people helped me testing the code, especially supercointeam, and with whom we supported the supercoin community for many months. The code works very smoothly, though it still have many aspects to be enhanced which I will list below for the potential future developers.

It was fun and exciting with supercoin. We have many great supporters, also enough fudders. I still see sometimes people doubt if the code is real. Imagine this, how can I put fake things inside that can work so flawlessly? and with dynamic log messages that everyone can use the console and see? There are so many dumb people in this domain, and so few people who really understand the technologies.

Now the code is public, please review the code (well for those who really know the code, otherwise it will be tough for you... very tough). If you have issues with the code, please use debugger, you will understand it better. I may come back from time to time to check the comments and questions, but as I am busy, I won't reply unless it is really needed.

For the future developers, please note that the p2p anonymous code with multisig is done in about one month time, therefore while I ensure the main scenarios working fine, there are some codes I haven't got time to complete, this is mainly in the domain of error handling and reverting back the transaction, this should be easy to add (though it could be tedious) based on the existing code. Another potential issues is the out of sequence messages. I handled many such cases during my tests, all occurred scenarios are handled. But due to the potential high number of combinations, in rare case there may still be some potential cases due to out of sequence messages that the transaction may fail.

Anyway, have fun with the code, and if you understand it well, you can copy-paste to another coin. But doing so only if you understand the code, since it is complex code. I'd be really sad if you copy-paste the code but don't know how to handle issues when they occur 

I don't have handles on twitter/facebook. supercointeam has them. Hope he will see this and provide you the related info.

This is exactly what I worried and that's why I did not release the code publicly.

Reading the messages, I am disappointed. Several still ask if the code is real. Did you ever try the client? Do you think I would waste so much time writing whitepaper and for coding/testing? I am under no obligations to release the code. I tried to help the community but so far I don't even see a qualified dev coming up. In fact I don't see any dev said willing to take over. I got only one PM from a guy saying that he has a team including devs etc, but I get no details about these devs at all, and I get no impression that they will maintain supercoin (no plan, nothing).

As I stated before, I will release the code only if there's a qualified dev willing to take over. What is "qualified"? well you need to know the coin code. We can chat 5 mins in a chatroom, it's very simple.

Also I don't check the thread every day, I am very busy at work, so if I don't reply you immediately, please be patient.

Well believe me, if I had time to continue developing, I would do it. No one has more affection to the coin, as I am the one who spent most time on this coin, not spent the time to talk, but countless hours to design and code and test the coin. But unfortunately I have my work and my responsibilities. So I can not continue developing the coin.

What I want:
1. make supercoin back to open source based coin
2. hope some qualified people from community can take over the code

As some people expressed the concerns about other coins copy-paste the code, I share the same concerns, that's why I did not publish yet the code.  I am in a dilemma now. If no qualified people to take-over, the publication of code will do no good to supercoin, but I also want the supercoin be open source, so community can maintain and develop the code.

So this is my decision:
a. I won't publish the code until community have someone qualified to take over the code.
b. If there's a qualified person (need to have a track record), I will send him the code 1 week before I make it publicly in git.

BTW, the reason we don't want "auditors" is that very few people in alt coin domain has the ability of "auditing" our code. It will be a joke asking an amateur to review an expert's code. A good example is many of you already know how Poloniex "reviewed" our simple code (not even containing any anon features).

To all people who like supercoin dev or hate us: we did our job for the supercoin, we provided the best technology and the the unique p2p trustless system for anonymous transfer. As we have repeatedly said, the success of a coin, depends on the community, not on the devs. The devs provided the best they can for this coin. Rest is the community who will define the direction of the coin.

I will publish the source code of supercoin p2p trustless system for anonymous transfer by the end of this month. Of course the source code will be copied by many copycatters, who form the most "devs" in the alt coin domain. But at least the source code will help those who are capable of continuing developing and enhancing the code. All details are published in the whitepaper, there is nothing hidden.

Myself and supercointeam are too busy at our own work to continue developing coins. It's been a wonderful few months with the community here. And in the future if I find more time, I'll do some more serious work on the coin code. It is fun and a great experience for me.

Explorers are not done by dev team, we informed as soon as possible the dev for explorer and helped to get it fixed.

Again fork is a common problem. Exchanges are responsible to watch it and suspend trading as needed. The dev team will help as much as we can to resolve the issues.

As supercointeam said, as soon as we found out there are possible forks, we released a new version with new checkpoints. If you use the new version, you can only sync to the correct block chain.

And because the sync time is usually very long (the program will take long time to find out the right chain from the forked ones), we posted the correct block chain files a few days ago. So as long as you download it, and sync from there, it should be pretty fast to sync.

Use block explorer to check if you are on the correct blockchain.

Answers to a few questions:

Q1: Is the github 1.6 version wrong? why I am blocked at block 428419?
A1: The github 1.6 code is correct. If you are blocked at 428419, it means you are on a forked chain. There's a checkpoint at block 428420. This is the purpose of checkpoint. We compiled directly from github and tested a few times, there is no problem at all. Both released 3.1 windows client and the github 1.6 code are correct.

If it takes too long for you to sync, download the blockchain file and sync from there.

Q2: Why fork happen?
A2: Fork happens due to network hash / pos generation unevenly, and also faster block time (which makes transactions a lot faster) may cause forking problems. This fork problem is very common in the alt coins. Most coins have fork issues at one point. Nothing is strange there. When fork occurs, dev team usually release a new version with more checkpoints that block the forked chain. Once everyone use the correct chain, fork will die.

Q3: Why after sync my balance is different?
A3: After fully sync'ed, use repairwallet command in console.

Thanks all for your patience and support.

This is the last part of the whitepaper. Sorry for the little delay as I was focusing on code testing in the last few days.

===

The last section of the whitepaper is to show you a concrete examplein SuperCoin’s real network. This is a real test with SuperSend  p2p decentralized trustless system, in SuperCoin main network. All the txids and addresses are real, and you can find them in the SuperCoin’s blockchain explorer.

First, in order to use SuperSend you need to enable the Coin Control features. This can be done from menu Setting->Options the click on Display tab. Select “Display Coin Control Features” checkbox.
 

Now you will see in the “Send Coin” tab, the Coin Control features. You will see now the checkbox “SuperSend (anonymous send)” checkbox, at the bottom of the Coin Control.

You don’t have to use Coin Control to send coins. When you want to send coins using SuperSend, just select the checkbox. It is very simple: it is based on each send.

SuperSend will charge 1% service fee (with 0.5 SUPER minimum). This service fee is to be divided by the 2 service nodes (mixer and guarantor) equally. Also it prevents scams with many small amount transfers. The fee will be added automatically to the required sent amount from Sender’s balance.

Any clients can become service node, if they satisfy some minimum requirements. At this time the requirements are set to the following:
-   Having at least 2 addresses in the client (you can create new address in “receive addresses” tab, with “new address” button.
-   Having a spendable balance of 500 coins

If your client satisfies the above conditions, it will automatically announce itself as service node. If you don’t want your client to become a service node, the put the following line in the config file:

Even you don’t want to become a service node yourself (note: service nodes will receive fee at each service), you can still use SuperSend provided you have 2 or more service nodes connected.

On the lower right corner of the QT client, there is a newly added indicator for availability of the SuperSend. The SuperSend is enabled when you have connections to at least 2 of the service nodes. At this time the “S” icon displays green color. Put your mouse on top of the green “S” circle you will see how many service nodes you connected to.
 

If the “S” icon displays red, it indicates that you don’t have enough connections to service nodes, so in consequence the SuperSend feature is not available (but you can still use regular send. The regular send is available all the time).
 

If the “S” indicator displays yellow, this means a SuperSend job is currently in processing. You will have to wait it finishes before making another SuperSend. Note that the yellow status can be generated because you send something using SuperSend, or it could be that someone else send coins and your node is selected as a service node (Mixer or Guarantor). In case you perform service to others, you don’t need to do anything. The system will automatically perform the tasks. But do not exit the client when the status is in yellow. The yellow indicator will last for maximum 60-80 seconds. So it is just a transition state.
 

You send coins by selecting SuperSend, and enter the destination.


You will then need to confirm it. Remember, you must have enough fund in the account to use SuperSend. Due to its escrow requirements of SuperSend, the Sender needs to have at least double of the send amount plus the service fee. For example, in order to send 100 coins, the Sender must have at least 2x100 + 1 (1% service fee) = 201 coins in his account. Otherwise he has to use the normal send. The escrow is required so that all parties must follow the rules to complete the transaction.


Some people may ask why Sender needs to put in an escrow, since he will provide the send amount and service fee to the escrow anyway. The answer to that question is in that without the additional escrow, there is no reason or obligation for the Sender to sign off the distribution transaction when everything is completed, in which case there will be no guarantee that Mixer will receive his sent amount plus the service fee.

Once the coins are sent using SuperSend, you can use “getlastanontxinfo” command on the console to check its status. The following 4 pictures showed the progression of this test send example, it goes through different stages of the processing, as show in the “Status of last/current transaction”.

This picture shows that all public key info collected (before creating multisig address).
 

The following picture shows that multisig 2-of-3 address is created by the system, and deposits to multisig address completed.
 

The following diagram shows that the deposits are verified and then distribution multisig transaction is created.


The last picture shows the trustless anonymous transaction is completed and all escrow refunded. This is a view from sender’s log.


From Mixer and Guarantor side, you see slightly different logs (customized to them).

In this example, 1.2345678 coins are sent using SuperSend. The Sender will see an amount of 2.96923578 coins sent to the escrow (which is a multisig address dynamically created), 2.96923578 = 1.23456789x2 + 0.5 (service fee). The multisig address is CTfgXTYHQ1Bq725qkYBFgvPRSyPXUMvwze, the transaction there can be seen at blockchain explorer:
http://chainz.cryptoid.info/super/address.dws?CTfgXTYHQ1Bq725qkYBFgvPRSyPXUMvwze.htm

Similarly, Mixer and Garantor will deposit to the escrow. Then each party will verify the deposits. Once confirmed, the multisig 2-of-3 distribution transaction will be created:

Mixer will send the coins to the destination after verifying all the deposits. He will then sign the above multisig distribution transaction. After he signed it, the transaction cannot be posted at the network as it has only one of the two required signature.

Now the Sender will verify that Mixer indeed send the amount to the destination. After he is satisfied with it, he will sign the multisig distribution transaction. Note that he has interests to sign it if everything is fine, as he has a fund in the escrow that he wants back. After he signs the 2-of-3 multisig transaction, now there are 2 signatures with it, and the status of the multisig transaction will become complete.


Anyone can post it to the network and make it official. So Sender will post it after he signs it. The multisig transaction will be executed and all parties get refund, and Mixer/Guarator will also get their service fee.

Now the anonymous p2p decentralized trustless transaction completes. The source of the transaction is not traceable as in/out transactions are done at two different addresses that are not linked.

The multisig escrow system ensures that no party can cheat in the transaction; they have to follow the rules to complete the transaction. This is a complete decentralized, peer-to-peer anonymous system. It demonstrates the power of multisig technologies.

====

This completes the whitepaper, any questions/comments please post on the thread.

I added some Q&As in the Dev's Corner (2nd post after OP). As I heard there are some fuds on the Supercoin recently, some people who have no knowledge at all on multisig are attacking Supercoin's multisig technology.

By looking at all questions, I found some are good questions (like some from fluffypony), so while ignoring all fuds, I try to answer these questions in Q&A, and we welcome all reasonable questions and I am willing to discuss all details with other qualified devs.

The multisig tech we are using is 100% sound. Other projects such as Open Bazaar (creating a p2p decentralized trustless marketplace) uses the same tech. Unfortunately I see some attacks on Supercoin are completely out of rack. These people with zero knowledge on multisig better find some basic tutorials to understand it before posting nonsense in some threads.

Our purpose is to advance the technologies for cryptocoin. The cryptocoin domain is very new, there will be inevitably mistakes here and there. Our goal is not to say our coin is the best, but to do our best with best technologies and advance our understanding onthe cryptocoin.

With this, here are the Q&As (I added it to Dev's Corner too).


Q1: Since in normal case, Guarantor does not participate in transaction, why we still need it?
A: Guarantor is needed in case of dispute. For example, Mixer claims he sent the coins to destination, while Sender claims he does not see it. At this time, Guarantor is the one to decide whether to distribute the escrow fund as if the transaction completed, or the transaction cancelled.

Q2: Is Supersend with trustless system going to be slower than SuperSend Mixer (phase-1)?
A: In our testing it is pretty fast, the anonymous p2p trustless transaction usually takes 20-40 seconds to complete. But since there are several transactions during the process, it will be a little slower than the SuperSend with centralized mixers.

Q3: Is there a fee to use trustless anonymous system?
A: Yes. The service fee is 1% or 0.5 SUPER, whichever is bigger. The service fee will be shared equally by Mixer and Guarantor.

Q4: If you only use 1 mixer and 1 guarantor, what if I have so many nodes that I can send you a modified multisig transactions that actually sends the coin to another address instead?  
A: First of all, another node will have no idea on what is the escrow multisig address. It is not a public address. It is created on the fly with randomly selected public keys from each of the participating nodes. Other nodes will not receive any info on the public keys. Also, the system does broadcast any messages. Messages are point-2-point and not broadcasted.
Second, all communicated private messages are signed with each party's private key, and verified on arriving by the public key of that party. So another node can not forge a message from a participating party, not to say he has any way to get the message and know the id of transactions etc at all. So other nodes can can not forge messages.

Q5: If sender is only sending it to the mixer and then to the receiver, I can just analyze within X blocks for the same amount of coins and I will have a pretty high confidence level that the transaction belongs to the sender/receiver, especially if the amount is pretty unique?
A: You can't analysis these for sure. The first step we send as one amount, the amount can easily be splitted into multiple amounts as we did in our phase-1 mixer scenario (amount splitted into random 2-4 parts). Moreover, there are many similar amount sent around. All escrow amounts are similar amounts, all you see is that 3-4 similar amounts sent around and you can't trace them as in/out addresses are not linked at all. It is also easy to split the sending amount (and all fund transfer in the transaction) into "canonical" values (meaning standard like 100, 50, 25, 10, 5, 2, 1 etc). These enhancements are very easy to do and we probably will do it in the next few releases.

Q6: The Guarantor is being trusted to do arbitration between the Sender and the Mixer. Therefore, given the nature of 2-of-3 multisig transactions, the Guarantor and the Mixer can sign the transaction, and then refuse to sign the cancellation transaction, leaving the Sender out of luck and out of funds?
A: Yes this is true. However, the system assumes most people are good people. In any system, if majority are bad, then you can't do much, except to have a centralized trust system. This is similar to cryptocoin, if >50% are bad, then they will take over.
This is the same as in trustless distributed marketplace OpenBazaar (https://openbazaar.org/) did. In this system, there are Buyer, Seller and Arbitrator. If both Buyer and Arbitrator are bad (and coordinated), then you can't do much. They published a nice paper to describe this system (https://gist.github.com/dionyziz/e3b296861175e0ebea4b)

Q7: SuperSend Tustless uses TxIDs? With malleability what if the TxID changed?
A: Malleability mainly caused by multiple possible signature format that is in the TxID. This issue mostly fixed in Bitcoin 0.9.0 by restrict to one "standard" format and not replaying any mutated transactions. This basically fixed the problem.
Moreover, we don't need to transfer TxID per se. Our purpose in the algorithm is to verify whether all deposits made correctly, and whether Mixer actually sent the amount to the distinations. There are ways to do this without using TxIDs. strasboug in this thread proposed some solutions:
https://bitcointalk.org/index.php?topic=734578.0
Since escrow is on the multisig address, and multisig address is broadcasted to all the related parties. Each party can verify the deposits by looking at the input on that address. For Mixer's sent tx it is also easy to verify based on the transaction after a given timestamp, and with Mixer's send wallet address. The solution is does not depend on TxIDs.
Last point I want to make on this is, even if in some very rare case (0.1%?, 0.01%? 0.001%?) the TxID changed, the worst is that the send transaction fails, all fund will be refunded to each party, there will be nothing lost.

Q8: Not all possible malleability vectors are "fixed" in 0.9.0, so transactions are still quite malleable and the transaction ID can still change. What do you do?
A: As said above, TxIDs are not mandatory in the solution. There are other ways to do it. In the first release we use TxIDs, we will possibly switch to non-TxID solutions.
BTW, if you are telling me that Bitcoin is still very vulnerable, I agree. However, we here do not try to beat Bitcoin. If people can still steal Bitcoin with malleability, then they can steal any cryptocoins, SUPER included. I won't feel bad on that at all. This is not related to trustless system, even with rare malleability not yet fixed by Bitcoin, all parties participating trustless transaction will not lose anything.

nomad13666, I like the many nice pictures you posted in the thread, thanks!

This is a quick update showing you that dev team is testing on SuperCoin real network.

Below is a screenshot showing successful transaction log for the sender and guarantor. The SuperCoin multisig address created in this transaction is CNixhRT4Jwg92SBLfBAhL4Q9b3sv8Wja4p, note that multisig addresses in SuperCoin starts with "C", not "S" (multisig address never starts with the same letter as normal address, like BTC normal address starts with "1" while multisig address starts with "3" etc). The transactions of it (escrow part) can be seen in the block explorer:
http://chainz.cryptoid.info/super/address.dws?CNixhRT4Jwg92SBLfBAhL4Q9b3sv8Wja4p.htm

This is one of the real network tests we did. Remember we will start beta tests in SuperCoin main network on August 20.

SuperCoin is X11 with great features like Super-PoS blocks etc. MammothCoin is a different coin, which uses X13 hash algo, and does not have Super-PoS feature.

When SuperCoin developed the phase-1 anonymous system (trusted mixer based), Mammothcoin dev team contacted us and ask for licensing the tech, and agree to help on our phase-2 work. So we licensed them the supersend tech.

They helped us to implement and test the p2p decentralized trustless system, so we decided to launch the system on both coins the same day.

We co-operated with them on the anonymous, so far it works fine. The cooperation is limited to the anonymous area. Other things we do separately.

I want to give a quick update on our status.

We have started alpha testing with Mammothcoin main network 2 days ago, we had 2 sessions, most trustless anonymous tx worked fine, we also have identified some bugs and are in the process of fixing them. Alpha test will last a few more days. Then we will switch to Supercoin's main network for beta testing. Dev team sync'd the code with SuperCoin codebase, and is in the process of testing with SuperCoin. In beta tests, we will invite community members to participate. Stay tuned.

The multisig addresses for SuperCoin starts with "C" as opposed to the normal SuperCoin address which starts with "S" (the multisig address of MammothCoin starts with "b"), you can easily identify them in the blockchain explorer. I will post some screenshots later for the SuperCoin real network testing.

Please post any questions you may have, we'll try our best to answer them.

This is the 3rd part of the whitepaper, if you haven't read the previous 2 parts, please read them first. They can be found at Dev's Corner, the 2nd post of this thread.

Below is a detailed workflow chart, for p2p decentralized trustless anonymous system that SuperCoin uses. It is color-coded, so it is easier to see the coordinated actions among the 3 parties involved.



The diagram is pretty much self-explanatory, so we will not put many text to it. This shows only the main workflow, there are possibly at each point error conditions to handle, which are crucial to the success of the anonymous transactions. These sometimes tedious handling is the standard handling in any transactions. We will not provide details there.

===

There will be one last part to the whitepaper, where we will provide an detail example of the SuperCoin. The last part will be published in a few days.

Someone PM'd me asking why I publish the details of the algorithm, and whether I am afraid that someone will copycat the idea. I told him that I welcome other people to implement the algorithm. It took me 3-4 weeks to do it. By the time they finish it, I'd possibly publish the code already

Have fun, and please post any questions you have.

......

I added a console command "getlastanontxinfo" to get the info for the current or last p2p trustless anonymous transaction, so user can see the status and the log of the current or last (if finished) anonymous tx. From my tests, each trustless transaction takes about 30-40 seconds to complete. Considering the many steps involved, this is a pretty good speed.

Be patient man, you posted questions for a few mins, and you expect dev waiting there watching for questions all the time?

Let me answer your questions here:

1. First of all, another node will have no idea on what is the escrow multisig address. It is not a public address. It is created on the fly with randomly selected public keys from each of the participating nodes. Other nodes will not receive any info on the public keys. The system does broadcast any messages. Messages are point-2-point and not broadcasted.

Second, all communicated private messages are signed with each party's private key, and verified on arriving by the public key of that party. So another node can not forge a message from a participating party, not to say he has no way to get the message and know the id of transactions etc at all. So what you described the scenario is not valid.

2. You can't analysis these for sure. The first step we send as one amount, the amount can easily be splitted into multiple amounts as we did in our phase-1 mixer scenario (amount splitted into random 2-4 parts). Moreover, there are many similar amount sent around. All escrow amounts are similar amounts, all you see is that 3-4 similar amounts sent around and you can't trace them as in/out addresses are not linked at all. It is also easy to split the sending amount (and all fund transfer in the transaction) into "canonical" values (meaning standard like 100, 50, 25, 10, 5, 2, 1 etc). These enhancements are very easy to do.

Here is the 2nd part of the whitepaper, which gives a high level in-depth view of the trustless algorithm we use. Please refer to the part 1 if you need to understand some terms. Part 1 is here:
https://bitcointalk.org/index.php?topic=618552.msg8272890#msg8272890

==
The following diagram shows a high level description of the trustless system algorithm. It shows the “normal” case where everything goes as expected.




The next diagram shows the case where, after step 6, the Sender is not satisfied with the Mixer’s txid. This could happen if the Sender cannot verify Mixer’s transaction, or Mixer did not send enough funds to the destination. In which case Sender asks Guarantor to do the arbitration. The new scenario are marked in brown lines and explained in the diagram.



There are other possible scenarios, that we will describe in the next parts, where we will show details of the algorithm and steps. But from the above two cases you see why multisig is tightly linked with trustless system and how it creates a bonding among all parties where they have to follow the anonymous transfer rules.

OK thanks for your feedback. I haven't finished the whitepaper yet, otherwise I would have posted it. I've been busy on the coding and testing lately. But I will post more frequently. I will post a pretty in-depth summary of the algorithm soon.