Quote from: fluffypony on August 11, 2014, 10:19:59 PM

Quote from: timerland on August 11, 2014, 09:43:08 PM

Quote from: strasboug on August 11, 2014, 09:28:57 PM

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.