# Simultaneous 2 way exchange without trusted third party

Stakeholders:
Alice - has a message, M containing a secret, SA that Bob wants, where H(SA) is a hash which may be used by Bob to redeem some Bitcoin time-locked transaction sent previously by Alice.

Bob - has a message, M containing a secret, SB that Alice wants. Similar to Alice's situation, where H(SB) is a hash which may be used by Alice to redeem some Bitcoin time-locked transaction sent previously by Bob.

Problem Description:
Alice and Bob wants to exchange their messages simultaneously and both messages have a mutual dependent relationship where the invalidity of one secret should invalidate the other secret.

A ------- MA --------> B
B ------- MB --------> A

Valid(SA) i.f.f Valid(SB) when M are checked simultaneously by Alice and Bob. (i.e. if SA was found to be invalid, then SB should be invalidated and vice-versa)

I am wondering if there was a cryptographically secure protocol which enables this exchange without the need of a trusted third party acting as an escrow? If there isn't such a scheme, what other properties could be added to enable a simultaneous 2 way exchange without the need of a trusted 3rd party? (i.e. time-constraints?)

• What should determine if a secret is invalid? What will the secrets be used for? – Daan Bakker Jun 8 '16 at 13:00
• The secret when hashed by the recipient will reveal if the secret is valid. – renlord Jun 8 '16 at 13:23
• Could your please use symbols, e.g. H() for hash etc., and a toy example to clearly show what stuffs are exactly being exchanged in the communication between Alice and Bob? – Mok-Kong Shen Jun 8 '16 at 16:51
• Well, they can make due with a _semi-_trutsted third party, rather than a standard trusted third party. ​ (i.e., the third party may cheat on its own but is assumed to not collude $\hspace{1.85 in}$ with either either of the main parties.) ​ ​ ​ ​ – user991 Jun 8 '16 at 19:13
• I've added more context and highlighted that the hash is mainly used as some "later" released redeem condition for some Bitcoin hash-timelocked transaction. – renlord Jun 8 '16 at 22:21