3

First off, I understand that the standard way to do escrow with bitcoin is a P2SH with a 2 of 3 multisig redeem script. I'd like to try and do escrow in the following way:

names of 3 parties involved:

  • money source
  • escrow agent
  • money destination

there are 2 transactions involved:

  • escrow transaction: the money source sends funds to a custom locking script
  • spending transaction: the escrow agent moves funds from the escrow transaction to the money destination

With these properties, the escrow agent has complete control over spending the funds, BUT the escrow agent can only move them to the money destination and nowhere else. (i.e. escrow agent can't steal the funds)

I realize that in order for this to work the custom locking script of the escrow transaction somehow has to reference the money destination's address and provide some mechanism such that when the escrow transaction's locking script is unlocked it checks that the transaction it is being used in is in fact going to the money destination.

It seems that one cannot directly reference the output address of the spending transaction when the spending transaction is being verified. The only way it seems to have the output address be part of the verification is indirectly via CHECKSIG (since the data being signed include the output address of the spending transaction) But in order for this to work we would need to sign the spending transaction and include that signature in the escrow transaction, but that creates a circular dependency: the escrow transaction includes a signature of the spending transaction which includes the hash of the escrow transaction (since the escrow transaction is an input to the spending transaction). And so this would be impossible. I wish there was a hashtype that allowed you to only sign the output side of the transaction and not the inputs at all.

I'm pretty new to bitcoin, so maybe I'm missing something. But it seems that designing an escrow with the properties I described at the beginning of this question would be impossible, and the only way to do escrow is a standard P2SH 2 of 3 multisig.

The reason I don't want to do a standard multisig is that in order for it to work in a trustless way. the money source and money destination have to exchange their addresses directly (i.e. the escrow agent can't give the other 2 parties the appropriate addresses, because he could give out the wrong addresses). This way when the escrow agent signs the txn and gives it to the other party to sign they can verify that the escrow agent signed it to go to the right place.

I'd like the escrow agent to be the point of contact for the other 2 parties so that they don't need to do an address exchange prior to working with the escrow agent but can still not have to trust the escrow agent

1
  • This reminds me of Bitcoin Covenants proposition by Emin Gun Sirer. Covenants aren't possible yet, but I think they have been implemented as a side chain. Jan 7, 2017 at 11:11

1 Answer 1

1

Partial answer (not a new solution - I merely adapted the micropayment channel protocol): if you allow for public key exchange, one solution seems to me to be:

  • t1: source funds an address A controlled by source and escrow
  • t2: source partially signs transaction T spending A to destination. Then she sends this partially signed transaction to escrow.

it is now up to escrow to sign and broadcast T so that destination receives the fund. Escrow cannot spend the funds differently (i.e. steal) as it would require source to cosign.

(Problem: Escrow could decide to not sign and "block the funds" (that s why Refund transactions are included in payment channels). Solved by having Escrow partially sign and send to source a transaction R sending hte funds from A back to source at t0. It s now up to source to sends herself the funds from A back. Is this an issue? Not really if you have transaction R be "timelocked")

It seems harder to find a solution without public key exchange... but it is a bit strange to forbid public key exchange.

1
  • 1
    Thanks! I realize now that even the impossible solution I proposed would still require a public key exchange, so I guess there is no way for the escrow agent to be the point of contact for the other parties and still not be a source of trust. Jul 11, 2016 at 12:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.