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