The answer is to use

**Sender Generated Conditional Keys**.

If the sender can generate a public key for the receiver such that:

1. Only the receiver can generate the private part for it

**but only if he gets a separate piece of information from the sender**.

2. The sender cannot generate the private part – hence once the transaction is out there the sender cannot recover the coins – only pass them on to the receiver.

Then we have a situation where there are coins sitting there that are committed and can only go to the receiver but the receiver cannot pick them up until he somehow satisfies the sender.

Two step transactions can be implemented by trusting a third party with your coins but sometimes you don’t want to trust a third party.

-----------------------------------------------------------

This is how Sender Generated Conditional Keys work:

Let Alice publish a certificate with a public key. (This cert has a key that is NOT a transaction key. It cannot be used in a normal fashion by other clients to send to.) Let "a" be the cert private key. The cert public key is "A" (A=aQ where Q is the basis point in the cryptographic curve). A is available in the Cert created by Alice.

Also, let Bob have a wallet and it has coins under a public key "Y" so the bitcoin block chain has a transaction transferring coins to Y and Bob has the private key, "y", which corresponds to Y but no one knows that Bob owns Y.

Bob wants to conditionally send some coins to Alice. He looks up the certificate for Alice and extracts A. Bob’s client generates a public key "X" from A, y, and "m" (m is randomness derived from parts of the transaction that transfers the coins). X has the property that Alice can derive the private key "x" only if Bob gives Alice an extra piece of information. Alice can spend the coins in X by convincing Bob to give her the extra information then generating x and using it to sign a transaction spending the coins at some future time.

Bob generates X by first generating a secret, s, as follows:

s=Hash(m,y,A)

X = sA

(Note sA is a cryptographic multiply in ECC). Only Bob can generate s. Also, Bob cannot generate the private part of X but he can transfer coins to X. Bob convinces Alice he has committed the coins by generating a public key from s:

S = sQ

And sending it to Alice. Alice cannot generate s. But using the public S she knows the coins are committed since:

X = aS (where a is her private key)

Once she satisfies Bob he gives her s and she generates x, the private part of X, as follows:

x = sa (modulo a large prime determined by the ECC)

She can check that X = xQ and is satisfied.

“m” is chosen so that no two transactions produce the same s. Hence X will always be unique to that transaction. m would be a few bytes from the transaction that are unique to the transaction but are not dependent on X, the receiving key in the transaction. (This is important so we don’t have a circular definition for X).