Topic: SuperCoin's SuperSend technology, the true p2p decentralized trustless system (Read 2482 times)

So no further comments. I don't see any problem of supercoin's algo, now that they released the client, works fine as far as my tests go.

OK I don't really think this is an issue. Let me see what are the issues you have. From what I understand, this is the main one:
- transfer txid around can be a problem sometimes, as with malleability it changes sometimes

Do you have other issues? I saw you mentioned guarantor, what exactly the issues you have?

I am not the dev of Supercoin, he can jump in and answer your question. But let me try to answer it with my understanding of the algo they use.

For malleability issue, 0.9 fix prevents mutated txid from being relayed etc, it also try to accept only the standard sig format. By malformed, I meant "non-standard", not the "malformed" in the sense of basic format, of course it was not caught before, otherwise we won't have the issue of malleability. With these fixes in 0.9, it should not be an issue. But even it is an issue and if Supercoin used a non-sync'd version with 0.9, there are ways to solve the problem, for example to scan the tx from a time on to find the related tx.

My understanding is that they (each party in the trustless transaction) need to verify two things before proceeding to the next step:
1. Everyone deposited to escrow (multisig address), and with proper amounts.
2. Mixer has sent the amount to the destination.

For (1), people does not really need txids. Because after all parties deposited, and notified other parties, each party can just check the multisig address, which is notified to all parties earlier (so that they can make deposit). It is easy to check what amounts have been deposited and by which address. So for this verification, you don't need txids.

For (2), after Mixer notified the other two parties, it is possible to scan the blockchain for all tx after certain timestamp, and match txin's address with that of Mixer. This will not be difficult as there are limited blocks after the timestamp. From what I see the demo and test in Mammothcoin, it usually pretty fast (5 sec) before the block containing tx is sync'd to each other's wallet.

What I mean is that you don't have to rely on the txids to do the verifications. The overall algorithm for exchange info and data is pretty standard in the trustless marketplace of buyer-seller-mediator scenario which I believe is perfect solid.

No, malleability doesn't lead to a malformed signature. A malformed signature would be invalidated by virtue of it being malformed. With a traditional Bitcoin malleability attack you change the signature format on a tx and rebroadcast it, but the signature remains perfectly valid. The bulk of the anti-malleability changes in 0.9.0 are around things like listreceivedbyaddress or getbalance or listtransactions RPC API calls to make them less error-prone. There is a slight tightening of IsStandard() to make rebroadcast of modified transactions harder, but all that implies is that an attacker needs to have a bunch of nodes and some mining power in order legitimise his transactions.

It's also a given (see the Satoshi quote) that txid's can change during a reorg. They are not - ever - meant to be relied on, as they are not canonical.

this is true. Another point is that the malleability issue is caused by malformed signature in transaction, while a simple check to disallow it will fix the issue. this problem already fixed in BTC 0.9. I don't think this is an issue for multisig based trustless system.

Yes OpenBazaar used exact the same tech for their distributed marketplace. There's a youtube talking about it.

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.

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.

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.

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

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.

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.

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:


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.

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).

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.

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.

will be interesting to look at detailed algo

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.

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.

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.

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.

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.