And we have surpassed 10,000 posts, hooray !
Let's celebrate with a quick recap of important updates the dev gave last few days:August 9thHere's our update from dev team.
I have good news to report. I have finished the basic implementation of the p2p decentralized trustless anonymous system, and it works fine. With all the multisig addresses and transactions, it is a pretty complex system. Now it works end-to-end. In the next few days, we will provide a detailed schedule for testing and releasing the system (a rough schedule is below).
As far as I know, this is the first real p2p decentralized trustless anonymous system in coinjoin category. I am not sure for the crypto-note technology, it seems it is a good one, although it is a different technology and mainly for CPU. But for coinjoin category claims, I don't see any truly trustless system, and this is the first one.
Following is a quick screenshot from my desktop showing test log and some code.
The following is a rough schedule for the next few weeks, we will provide more details soon:
- A detailed white paper will be published in a few days, I should finish it before August 14. The white paper will contain details on the technology and algorithms we are using.
- Now to August 14 is dev team testing on trustless system, and also we will add bells and whistles to the code (especially for some error handlings).
- Alpha testing on real network of MammothCoin: August 15 - August 19. We decided not to use testnet as we have high confidence on our code, also our testing so far has been on the real network. We choose MammothCoin for initial testing as it has less traffic, so it is easier to fix initial bugs etc.
- Best testing on real network of SuperCoin: August 20 - August 24. With more robust code we move to SuperCoin. Both alpha and beta testings we will invite limited members of the community to participate the testing. These testing phases including all bug fixes.
- August 25, we will release p2p decentralized trustless anonymous system for both SuperCoin and MammothCoin.
Also, we don't release immediate the source code as they are too many copycats, but we plan to release the full source code 2 months after the system is released. So people with skills (and curiosity) will be able to inspect and review the code.
Stay tuned, we will provide more info in the next few days.
While I am writing the whitepaper, I think instead of publishing it all at once when I finish, I will post it in parts, every 2-3 days, so community will get more details about the algorithm we use and logistics behind it. It is also an education process so people will understand what is a trustless system and why we need it. So expect 3 parts to be posted in this thread. I will prepare a pdf file with all parts together (the formal whitepaper).
All questions are welcomed, though I may not have time to answer all the questions. Because I still need to do testing on the code and fix bugs, and add bells and whistles etc.
Below is the first part on the SuperSend Trustless system. I will try to publish the next part in 2-3 days, maybe Monday/Tuesday time frame. Next parts will describe the overview and details of the algorithm.
==
SuperSend Trustless is an advanced p2p completely decentralized anonymous system. It belongs to Coinjoin category of the anonymous wallet. In this system all nodes (clients) are equal; there are no centralized or special nodes that hold more info than others. The coin transfer happens with the help of middle nodes that are randomly chosen. Mini-escrow is used with multisig address and transactions to ensure all the parties behave according to the transfer rules. This is a complete trustless system. The system is designed in a forceful way for all parties to behave correctly. If any party tries to cheat, he will lose more than his gain in the cheat.
Among all the online coin clients, if some minimum requirements are met (e.g. with minimum amount of coins in the balance, and with minimum 2 addresses in the wallet, etc), the node will advertise itself as a service node. Other nodes receiving the advertisement will add it to their service node list. There’s a limit in the service node list for each client (currently limited at 30). Any client can turn off the advertisement, if it does not want to be a service node. To turn off the service node advertisement, user just need to put a line in the config file. A service node will receive certain fee for each service it performs. Node not want to be service node can still receive other node’s advertisement and use the anonymous service, as long as it pays the service fee.
SuperSend Trustless makes heavy use of multisig technology. The sender of the coin will choose randomly 2 middle service nodes from his service node list to help the anonymous transfer. Among the two nodes chosen, one provides mix service, and another provides guarantee service. Why need 2 nodes? Because if there are any disputes between sender and mixer, it is up to guarantor to make a final judgment and then distribute the fund in the escrow accordingly.
Mixer is the node to mix the coins with his own, and send to destination. It is possible to have multiple mixer nodes, so to further obfuscate the transfer. At the current implementation, we use a single mixer node.
Guarantor is the one who will make the final judgment if any dispute between sender and mixer. If everything goes on well, Guarantor’s job is just to create multisig address and multisig transactions. It will not be involved in the signing processes of the multisig transactions in normal cases. But if there are disputes, the Guarantor will decide, based on the facts of the existing transactions, the outcome of escrow distribution. Of course, Guarantor cannot decide alone, he has to coordinate with another party (see below for the signing of multisig transactions).
We use a 2-of-3 multisig address for escrow. What is a 2-of-3 multisig address? It is an address that is created based on 3 public keys, each from Sender, Mixer and Guarantor, respectively. Remember, Sender, Mixer and Guarantor each hold the corresponding private key of the public key. Anyone is free to deposit coins to the 2-of-3 address. But in order to spend any fund from the address (i.e. send to another address), the transaction needs to be signed using at least 2 out of 3 private keys. Since the private keys are in different nodes, different nodes must willing to sign the same transaction before it becomes valid. In another words, the coins in that address cannot be spent by anyone alone, at least two of them should agree before the money can be spent.
==
August 11thHere 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://bitcointalksearch.org/topic/m.8272890==
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.
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.
