SuperCoin Dev's CornerIn this section we post SuperCoin's technical details, whitepapers, and technical questions/answers. Hopefully most tech info can be found here, so people do not need to repeatedly ask the same questions or search the thread for answers.
For now there are 2 parts:
- Whitepaper on P2P Decentralized Trustless Wallet
- Questions and Answers
Whitepaper on P2P Decentralized Trustless WalletSuperSend 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.
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.
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.
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.htmSimilarly, 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:
010000005134f553030cafb8d931619765b36ee7767165f0ce5dbd616faf92eb438f86286b00a4530c0100000000ffffffff00ea3421c2e665d732f6f19f2898c91a6eb42e0c23f74fd5bfe013fc58ab283c0100000000ffffffff0f2ae1d71455ff3ab175fa6d4cb3112eff6c404e8f86a3a31f453b7b3cbda1fd0100000000ffffffff0315cd5b07000000001976a9146674fb672742529a2b95e494e3dfd080b63fd8d288acc2b03410000000001976a914269771575d9dfdecb6a969e547cf10d68849c8b988acade3d808000000001976a914a744aee8f373a1d9517352a7853a61fa3f8f9f5288ac00000000
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.
010000005134f553030cafb8d931619765b36ee7767165f0ce5dbd616faf92eb438f86286b00a4530c01000000b500483045022100dcd329a3090ea4db4aa676bde531c95b2f6510947293c8304bb7667878dc2f5c022067065c76a8d98f96b27c75f3d08b4384ff550c2ceb59db8f283fcd2828c3361f014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff00ea3421c2e665d732f6f19f2898c91a6eb42e0c23f74fd5bfe013fc58ab283c01000000b50048304502210096a47d60fe43c10d29566dc98a8ecae9433312149257a9d8754ef3c7b2bc7ff3022063c1b806f5eeeff42ae87ba6108c3a9aec7a05abbd03fcb5e66e66c27c270978014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff0f2ae1d71455ff3ab175fa6d4cb3112eff6c404e8f86a3a31f453b7b3cbda1fd01000000b400473044022031660221c65a911b9cbce27c97d04cc0c18e2f9f7448666905115961f2eac773022074e034bd3a7ab46d6fb4bb1cd0f0c97ab0295ef7d05d46ce168ba243f2840de4014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff0315cd5b07000000001976a9146674fb672742529a2b95e494e3dfd080b63fd8d288acc2b03410000000001976a914269771575d9dfdecb6a969e547cf10d68849c8b988acade3d808000000001976a914a744aee8f373a1d9517352a7853a61fa3f8f9f5288ac00000000
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.
010000005134f553030cafb8d931619765b36ee7767165f0ce5dbd616faf92eb438f86286b00a4530c01000000fdfe0000483045022100ddb8e23ffcda6bb86a8d3c104e6365a5d15acc192e4ae1c502be524f2436dfe602205704c9515e7000313d4d86a3bc5b693c066a6d641a0c2662854477c2e9c3161701483045022100dcd329a3090ea4db4aa676bde531c95b2f6510947293c8304bb7667878dc2f5c022067065c76a8d98f96b27c75f3d08b4384ff550c2ceb59db8f283fcd2828c3361f014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff00ea3421c2e665d732f6f19f2898c91a6eb42e0c23f74fd5bfe013fc58ab283c01000000fdfd00004730440220062f5dfccd8a977cde3a9dce370e3fe0bb9cc62e06ab46951ddc7f14a0b21cdc0220312fb04328b66e3561bcf1389f34db6e4172bcd4e90041283fc79fa6284bca480148304502210096a47d60fe43c10d29566dc98a8ecae9433312149257a9d8754ef3c7b2bc7ff3022063c1b806f5eeeff42ae87ba6108c3a9aec7a05abbd03fcb5e66e66c27c270978014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff0f2ae1d71455ff3ab175fa6d4cb3112eff6c404e8f86a3a31f453b7b3cbda1fd01000000fdfd0000483045022100c40af67a2043b4791288844dbfd6cea5d5a273fd4f2ce9de26160db2c595abb80220760f1b6c0cad3d447d71d1f2e86ed67899f508a1e607428884382e27867710f301473044022031660221c65a911b9cbce27c97d04cc0c18e2f9f7448666905115961f2eac773022074e034bd3a7ab46d6fb4bb1cd0f0c97ab0295ef7d05d46ce168ba243f2840de4014c6952210306a712464d0ea33dafc25d3057b593600fc63c03a1f7aa9fc74cd75701044e9d2102987a1c09aedf53fd9dbe464fb2d4a7ff12267227fb19ecea048a07b47bfd4ef0210331dd0f241ace32569d962a53d429d994200de9c8100db1a280280d61b7db588a53aeffffffff0315cd5b07000000001976a9146674fb672742529a2b95e494e3dfd080b63fd8d288acc2b03410000000001976a914269771575d9dfdecb6a969e547cf10d68849c8b988acade3d808000000001976a914a744aee8f373a1d9517352a7853a61fa3f8f9f5288ac00000000
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.
Questions and AnswersQ1: 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.0Since 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.
