Arhag, you said that the article toast posted would not be able to satisfy the property that no one knows what is the secret stored in the obfuscated program. How is SMPC different in this regard? How would the system work in the context of a decentralized bitcoin exchange?
Well, first I have to say that my knowledge in this field is limited, so what I say could be inaccurate.
From what I understood, the code obfuscation method requires there to be at least one person who at some point in time knew the obfuscated secret because someone had to make the program in the first place before obfuscating it.
In the case of
secure multi-party computation (SMPC), you have N secrets (d_1, d_2, ..., d_N) each of which is only known to a respective participant (p_1, p_2, ..., p_N). There is also some general public function F(d_1, d_2, ..., d_N) that is a function of the N secrets. SMPC allows the N participants to work together to compute F(d_1, d_2, ..., d_N) without needing to reveal their secret with any of the other participants nor revealing any additional information about their secret that isn't naturally leaked by the result of the function.
This could be useful in the context of a decentralized bitcoin gateway in the sense that you could in theory construct a function F that takes the N secrets, combines them together to make the seed that generates a private key, and uses that private key to sign some hash embedded publicly in the function. This is a private key that no one individual knows. However, if the N participants colluded together by sharing their individual secrets, they could derive the private key. Furthermore, even if none of the participants reveal their individual secrets, they can still always collude together to sign any arbitrary hash they want. So the security of the funds protected by the private key depends on these participants not colluding together to do things they are trusted to not do.
Anyway, I don't think the above example is the practical way of even implementing the decentralized bitcoin gateway. I believe threshold signatures (like the example given in my original post) would be much faster. The problem with threshold signatures compatible with ECDSA (and thus compatible with bitcoin) is that there is a limitation on their use. If you require at least t' participants of the total n participants to have to work together to be able to sign transactions, then any t = (t' + 1)/2 participants of the total n participants can collude together to reconstruct the private key to allow them to sign any transaction. Still, that may be good enough security. If we weren't limited to only ECDSA and could use Schnorr signatures instead, then we could use threshold signatures without this annoying limitation. I should mention there was some talk about potentially adding those signatures to Bitcoin, and Gavin is a
fan, but who knows if it will ever actually happen.