SuperCoin's SuperSend technology, the true p2p decentralized trustless system

[strasboug]

I read the recent whitepaper from SuperCoin's thread, it looks to me that this is the true p2p decentralized trustless system. I don't see problems there. I welcome anyone to point out defects of this system, so we can understand better the trustless system and how to implement it.

I always believe that multisig tech is the only tech that will make the trustless system possible. And thanks to Supercoin dev, the trustless system is implemented and I am looking forward to testing it.

Below is the original post by supercoindev for references:

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.

[marseille]

Yes I think the supercoin's trustless system is a good one

[fluffypony]

Completely open to collusion. All you need is a significantly large number of nodes accepting requests to be guarantors, and since there's no barrier to entry this is trivial.

[strasboug]

Completely open to collusion. All you need is a significantly large number of nodes accepting requests to be guarantors, and since there's no barrier to entry this is trivial.

The barriers are minimum coin holding requirements. So a cheater can't have many nodes there. Also, the whole idea is that most nodes are honest. If most nodes are bad, then you can't do anything whatsoever, and in which case the trusted centralized system is the only solution.

Moreover, guarantor doesn't do much, guarantor only gets involved if there's a disagreement between sender and mixer. If there's no disagreement (as should be in most cases), guarantor does not even participate the decision on distribution.

[fluffypony]

Completely open to collusion. All you need is a significantly large number of nodes accepting requests to be guarantors, and since there's no barrier to entry this is trivial.

The barriers are minimum coin holding requirements. So a cheater can't have many nodes there. Also, the whole idea is that most nodes are honest. If most nodes are bad, then you can't do anything whatsoever, and in which case the trusted centralized system is the only solution.

Moreover, guarantor doesn't do much, guarantor only gets involved if there's a disagreement between sender and mixer. If there's no disagreement (as should be in most cases), guarantor does not even participate the decision on distribution.

Per this comment from yesterday - "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." Creating two addresses is trivial, and even if you use address signing to verify a balance it's trivial to move funds out and into another address to advertise that node, and then bounce it back again. Sybil attacks aren't prevented by these minimum requirements, and higher the requirements just created a high barrier to entry for a "service node", and thus a reason for those running service nodes to knock others off the network.

[strasboug]

Completely open to collusion. All you need is a significantly large number of nodes accepting requests to be guarantors, and since there's no barrier to entry this is trivial.

The barriers are minimum coin holding requirements. So a cheater can't have many nodes there. Also, the whole idea is that most nodes are honest. If most nodes are bad, then you can't do anything whatsoever, and in which case the trusted centralized system is the only solution.

Moreover, guarantor doesn't do much, guarantor only gets involved if there's a disagreement between sender and mixer. If there's no disagreement (as should be in most cases), guarantor does not even participate the decision on distribution.

Per this comment from yesterday - "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." Creating two addresses is trivial, and even if you use address signing to verify a balance it's trivial to move funds out and into another address to advertise that node, and then bounce it back again. Sybil attacks aren't prevented by these minimum requirements, and higher the requirements just created a high barrier to entry for a "service node", and thus a reason for those running service nodes to knock others off the network.

Creating addresses are trival, but if the minuimum coin requirements is 10K coins, then a cheater can not make many fakes nodes. Transfer funds back and forth is not an option, as the validity of the service nodes can be checked periodically (and most likely when the receiving node process the message). Also it is likely just before the service request the fund balance can be checked.

What you said are non-issues and can be fully prevented by the algorithms. And supercoin did not state the concrete requirements for it, we can see when they publish them.

[timerland]

Completely open to collusion. All you need is a significantly large number of nodes accepting requests to be guarantors, and since there's no barrier to entry this is trivial.

The barriers are minimum coin holding requirements. So a cheater can't have many nodes there. Also, the whole idea is that most nodes are honest. If most nodes are bad, then you can't do anything whatsoever, and in which case the trusted centralized system is the only solution.

Moreover, guarantor doesn't do much, guarantor only gets involved if there's a disagreement between sender and mixer. If there's no disagreement (as should be in most cases), guarantor does not even participate the decision on distribution.

Per this comment from yesterday - "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." Creating two addresses is trivial, and even if you use address signing to verify a balance it's trivial to move funds out and into another address to advertise that node, and then bounce it back again. Sybil attacks aren't prevented by these minimum requirements, and higher the requirements just created a high barrier to entry for a "service node", and thus a reason for those running service nodes to knock others off the network.

Creating addresses are trival, but if the minuimum coin requirements is 10K coins, then a cheater can not make many fakes nodes. Transfer funds back and forth is not an option, as the validity of the service nodes can be checked periodically (and most likely when the receiving node process the message). Also it is likely just before the service request the fund balance can be checked.

What you said are non-issues and can be fully prevented by the algorithms. And supercoin did not state the concrete requirements for it, we can see when they publish them.

I agree. These are details that can be done to prevent fraud. I don't see any basic things that prevent us from secure the service node exchange step. Even if one of the two service nodes is a cheater node, it doesn't matter, everything will still work as planned. Among the 3 related nodes: sender, mixer and guarantor, as long as no 2 nodes are from the same cheating group, the transaction process will work perfectly.

[fluffypony]

Creating addresses are trival, but if the minuimum coin requirements is 10K coins, then a cheater can not make many fakes nodes. Transfer funds back and forth is not an option, as the validity of the service nodes can be checked periodically (and most likely when the receiving node process the message). Also it is likely just before the service request the fund balance can be checked.

What you said are non-issues and can be fully prevented by the algorithms. And supercoin did not state the concrete requirements for it, we can see when they publish them.

I agree. These are details that can be done to prevent fraud. I don't see any basic things that prevent us from secure the service node exchange step. Even if one of the two service nodes is a cheater node, it doesn't matter, everything will still work as planned. Among the 3 related nodes: sender, mixer and guarantor, as long as no 2 nodes are from the same cheating group, the transaction process will work perfectly.

Well I'm not going to repeat what I said about increasing the barrier to entry and the knock-on effect of that. If it went over your head I completely understand.

But again, as mentioned more than once, this is about cheating the system. A guarantor could collude with mixers - even offering it as a service - to screw the senders over. This isn't rocket science, guys.

[strasboug]

Creating addresses are trival, but if the minuimum coin requirements is 10K coins, then a cheater can not make many fakes nodes. Transfer funds back and forth is not an option, as the validity of the service nodes can be checked periodically (and most likely when the receiving node process the message). Also it is likely just before the service request the fund balance can be checked.

What you said are non-issues and can be fully prevented by the algorithms. And supercoin did not state the concrete requirements for it, we can see when they publish them.

I agree. These are details that can be done to prevent fraud. I don't see any basic things that prevent us from secure the service node exchange step. Even if one of the two service nodes is a cheater node, it doesn't matter, everything will still work as planned. Among the 3 related nodes: sender, mixer and guarantor, as long as no 2 nodes are from the same cheating group, the transaction process will work perfectly.

Well I'm not going to repeat what I said about increasing the barrier to entry and the knock-on effect of that. If it went over your head I completely understand.

But again, as mentioned more than once, this is about cheating the system. A guarantor could collude with mixers - even offering it as a service - to screw the senders over. This isn't rocket science, guys.

Again I don't think you get it, let me repeat what I said:
"the whole idea is that most nodes are honest. If most nodes are bad, then you can't do anything whatsoever, and in which case the trusted centralized system is the only solution"

This algorithm will prevent cheating if one of the 3 nodes is bad, or no-2 nodes are in coordinated cheating.

If two out of 3 nodes are from the same cheater or same cheating organization, then you can't do anything with p2p decentralized trustless system. Use a centralized trust system instead.

[timerland]

will be interesting to look at detailed algo

[fluffypony]

This algorithm will prevent cheating if one of the 3 nodes is bad, or no-2 nodes are in coordinated cheating.

If two out of 3 nodes are from the same cheater or same cheating organization, then you can't do anything with p2p decentralized trustless system. Use a centralized trust system instead.

Of course you can. Your consensus system can be designed around consensus, this is the very nature of Bitcoin - if 2 nodes cheat on the Bitcoin network, they get rejected as outliers.

You've literally described a system that requires you to trust that there's not collusion between 2 parties, that is not a trustless system, which is a twist of irony given that you called that other piece of junk out as not being trustless. There is no Byzantine fault tolerance with this system, which is the very problem Bitcoin solves. You're trying to solve this problem: http://en.wikipedia.org/wiki/Two_Generals'_Problem - but the described system does not do so.

[strasboug]

This algorithm will prevent cheating if one of the 3 nodes is bad, or no-2 nodes are in coordinated cheating.

If two out of 3 nodes are from the same cheater or same cheating organization, then you can't do anything with p2p decentralized trustless system. Use a centralized trust system instead.

Of course you can. Your consensus system can be designed around consensus, this is the very nature of Bitcoin - if 2 nodes cheat on the Bitcoin network, they get rejected as outliers.

You've literally described a system that requires you to trust that there's not collusion between 2 parties, that is not a trustless system, which is a twist of irony given that you called that other piece of junk out as not being trustless. There is no Byzantine fault tolerance with this system, which is the very problem Bitcoin solves. You're trying to solve this problem: http://en.wikipedia.org/wiki/Two_Generals'_Problem - but the described system does not do so.

We are talking two complete different things. The 2 nodes cheat in bitcoin will get rejected, is because 2 as compared to 100000 of the network. It is not the 2 in the sense of a transaction involving 3 parties. You completely messed up the concepts.

The trustless system here, is to ensure the randomly selected parties will collaborate, and avoid cheating. The mini-escrow scheme by multisig tx accomplished perfectly this. The system does not require any inherent trusts there.

BTW, this has nothing to do at all with the two-generals' problem. All communications here are point-2-point and signed with each party's private key. The message is verified with sender's public key on arriving. So there's no message-tampering issue at all.

[timerland]

This algorithm will prevent cheating if one of the 3 nodes is bad, or no-2 nodes are in coordinated cheating.

If two out of 3 nodes are from the same cheater or same cheating organization, then you can't do anything with p2p decentralized trustless system. Use a centralized trust system instead.

Of course you can. Your consensus system can be designed around consensus, this is the very nature of Bitcoin - if 2 nodes cheat on the Bitcoin network, they get rejected as outliers.

You've literally described a system that requires you to trust that there's not collusion between 2 parties, that is not a trustless system, which is a twist of irony given that you called that other piece of junk out as not being trustless. There is no Byzantine fault tolerance with this system, which is the very problem Bitcoin solves. You're trying to solve this problem: http://en.wikipedia.org/wiki/Two_Generals'_Problem - but the described system does not do so.

We are talking two complete different things. The 2 nodes cheat in bitcoin will get rejected, is because 2 as compared to 100000 of the network. It is not the 2 in the sense of a transaction involving 3 parties. You completely messed up the concepts.

The trustless system here, is to ensure the randomly selected parties will collaborate, and avoid cheating. The mini-escrow scheme by multisig tx accomplished perfectly this. The system does not require any inherent trusts there.

BTW, this has nothing to do at all with the two-generals' problem. All communications here are point-2-point and signed with each party's private key. The message is verified with sender's public key on arriving. So there's no message-tampering issue at all.

Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).

[fluffypony]

Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).

Actually no, the "guarantor" is only involved in the act of sending coins, which is a "communication" in the context of the Two General's problem.

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.

Even worse - the workflow is based on the txid and verifying the txid. Have we not learnt by now that the txid can change? How do you people not understand that this was the very thing that mtgox blamed for their destruction?

In fact, if there was ever a clearer indication that the idiot "developer" that designed this system should stick to something less complicated, Satoshi Nakamoto himself wrote a seminal post in December 2010 explaining why this is a bad idea, so it's not like this is a novel and unknown thing:

Transactions are dynamic.  Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.  Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them.  This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.

This is not a trustless system, this is a trivially broken, fundamentally flawed system. Praising it as anything but an idiotic idea merely reduces your own credibility.

[mtomcdev]

Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).

Actually no, the "guarantor" is only involved in the act of sending coins, which is a "communication" in the context of the Two General's problem.

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.

Even worse - the workflow is based on the txid and verifying the txid. Have we not learnt by now that the txid can change? How do you people not understand that this was the very thing that mtgox blamed for their destruction?

In fact, if there was ever a clearer indication that the idiot "developer" that designed this system should stick to something less complicated, Satoshi Nakamoto himself wrote a seminal post in December 2010 explaining why this is a bad idea, so it's not like this is a novel and unknown thing:

Transactions are dynamic.  Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.  Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them.  This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.

This is not a trustless system, this is a trivially broken, fundamentally flawed system. Praising it as anything but an idiotic idea merely reduces your own credibility.

Thanks for pointing out this. There are many of us, probably hundreds of developers as we speak are thinking to come up with an idea to implement a trustless system that does the job better than bitocoin. It's quite clear, is not easy to come up with a better system than bitcoin is.

[strasboug]

Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).

Actually no, the "guarantor" is only involved in the act of sending coins, which is a "communication" in the context of the Two General's problem.

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.

Even worse - the workflow is based on the txid and verifying the txid. Have we not learnt by now that the txid can change? How do you people not understand that this was the very thing that mtgox blamed for their destruction?

In fact, if there was ever a clearer indication that the idiot "developer" that designed this system should stick to something less complicated, Satoshi Nakamoto himself wrote a seminal post in December 2010 explaining why this is a bad idea, so it's not like this is a novel and unknown thing:

Transactions are dynamic.  Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.  Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them.  This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.

This is not a trustless system, this is a trivially broken, fundamentally flawed system. Praising it as anything but an idiotic idea merely reduces your own credibility.

Again, the guarantor is not a communicator in the two general's problem.
1. All communications are signed and verified. There's no fake messages there. Also all messages are point-to-point.
2. All related deposits etc are independently verified by all parties. Posting a fake one does not go anywhere.

I don't think you understand the system at all. What you described is a coordinated attack. If 2 out of 3 are cheaters, then you have no way to prevent the cheating. Like in coin system, is you have 51%, you do whatever you want.

You verify the past transaction by its confirmations. Of course if the whole network is bad, you can't do anything. This is the same that BTC transaction confirmed 6 times, but can still go bad.

Please don't mix the problems here. The blockchain re-org is a normal problem, even a transaction in btc confirmed 100 times can still go wrong. The trustless system is not trying to solve this issue. The trustless system is not for everything you want to mix here. It is a clearly defined one. If you don't understand what it is, then read it again.

[fanboy4]

This smells good, i can see from scheme, there is a talent there.

[fluffypony]

Again, the guarantor is not a communicator in the two general's problem.
1. All communications are signed and verified. There's no fake messages there. Also all messages are point-to-point.
2. All related deposits etc are independently verified by all parties. Posting a fake one does not go anywhere.

I don't think you understand the system at all. What you described is a coordinated attack. If 2 out of 3 are cheaters, then you have no way to prevent the cheating. Like in coin system, is you have 51%, you do whatever you want.

You verify the past transaction by its confirmations. Of course if the whole network is bad, you can't do anything. This is the same that BTC transaction confirmed 6 times, but can still go bad.

Please don't mix the problems here. The blockchain re-org is a normal problem, even a transaction in btc confirmed 100 times can still go wrong. The trustless system is not trying to solve this issue. The trustless system is not for everything you want to mix here. It is a clearly defined one. If you don't understand what it is, then read it again.

A coordinated attack requiring 50% of Bitcoin's network is very different from me running a few hundred guarantor nodes and offering my services to any transactions I pick up. The one is hard, the other is trivially easy.

Blockchain reorg and confirmations have NOTHING to do with malleability. The issue here is relying on the txid, when malleability has shown that the txid can change. This so-called "trustless system" relies on txid's to confirm transactions in an automated fashion. That is bad, stupid, and fundamentally broken.

I'm tired of trying to demonstrate why you're wrong. You pointed out that Cloakcoin's PoSA system is not trustless, and I backed you on that because you were right. But now I see it was just a gimmick, a way of pivoting off that into this post about how Supercoin's system is trustless. Both are broken and flawed, and both are clearly designed by people who haven't the slightest clue about cryptography. I wish both Cloakcoin and Supercoin all the best. Goodbye.

[marseille]

Yes this is right. The trustless system we talk here has nothing to do with two-generals problem. Communications have no problem, the problem is that how to prevent any node from doing bad things (i.e. steal coins).

Actually no, the "guarantor" is only involved in the act of sending coins, which is a "communication" in the context of the Two General's problem.

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.

Even worse - the workflow is based on the txid and verifying the txid. Have we not learnt by now that the txid can change? How do you people not understand that this was the very thing that mtgox blamed for their destruction?

... (snip)

The assumption is max 1 bad guy in the 3 party scenario. If the bad guy is guarantor, then he does not have a say as sender/mixer will sign and complete the multisig tx. If the mixer is the bad guy, then guarantor will make the judgment, I don't see any issues there.

[crypto-dude]

The supercoin's trustless approach is similar to that used by OpenBazaar (https://openbazaar.org/). This is a sound approach for trustless system and I'd consider it as "standard". BTW, I don't know if there exist any other system that is sound for making a trustless system.