<p>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:</p>

<ul>
<li>t1: <code>source</code> funds an address A controlled by <code>source</code> and <code>escrow</code> </li>
<li>t2:
<code>source</code> partially signs transaction T spending A to <code>destination</code>. Then
she sends this partially signed transaction to <code>escrow</code>.</li>
</ul>

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

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

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

CC BY-SA 3.0
2016-07-11T12:45:01.557Z
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.
Adam Langsner
CC BY-SA 3.0
2016-07-10T20:16:34.580Z
2016-07-10T20:22:13.673Z
2016-07-10T20:22:13.673Z
hartmut
<p>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:</p>

<p>names of 3 parties involved:</p>

<ul>
<li><code>money source</code></li>
<li><code>escrow agent</code></li>
<li><code>money destination</code></li>
</ul>

<p>there are 2 transactions involved:</p>

<ul>
<li><code>escrow transaction</code>: the <code>money source</code> sends funds to a custom locking script</li>
<li><code>spending transaction</code>: the <code>escrow agent</code> moves funds from the <code>escrow transaction</code> to the <code>money destination</code></li>
</ul>

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

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

<p>It seems that one cannot directly reference the output address of the <code>spending transaction</code> when the <code>spending transaction</code> 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 <code>spending transaction</code>)
But in order for this to work we would need to sign the <code>spending transaction</code> and include that signature in the <code>escrow transaction</code>, but that creates a circular dependency: the <code>escrow transaction</code> includes a signature of the <code>spending transaction</code> which includes the hash of the <code>escrow transaction</code> (since the <code>escrow transaction</code> is an input to the <code>spending transaction</code>). 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.</p>

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

<p>The reason I don't want to do a standard multisig is that in order for it to work in a trustless way. the <code>money source</code> and <code>money destination</code> have to exchange their addresses directly (i.e. the <code>escrow agent</code> can't give the other 2 parties the appropriate addresses, because he could give out the wrong addresses). This way when the <code>escrow agent</code> 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.</p>

<p>I'd like the <code>escrow agent</code> 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 <code>escrow agent</code> but can still not have to trust the <code>escrow agent</code></p>

CC BY-SA 3.0
2017-01-07T11:11:54.633Z
This reminds me of [Bitcoin Covenants](http://fc16.ifca.ai/bitcoin/papers/MES16.pdf) proposition by Emin Gun Sirer. Covenants aren't possible yet, but I think they have been implemented as a side chain.
ManfredMacx
<multi-signature><escrow><message-signing><sighash-flags><checksig>
I'm trying to create a new kind of escrow with bitcoin, not sure if it's possible
Adam Langsner
# I'm trying to create a new kind of escrow with bitcoin, not sure if it's possible

(Asked by: username_0 on 2016-07-10)

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`

**Tags:** multi-signature, escrow, message-signing, sighash-flags, checksig

> **Comments:**
> **username_1**: This reminds me of [Bitcoin Covenants](http://fc16.ifca.ai/bitcoin/papers/MES16.pdf) proposition by Emin Gun Sirer. Covenants aren't possible yet, but I think they have been implemented as a side chain.  

---

## 1 answers

### Answer by username_2 on 2016-07-10. Score: 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.

> **Comments:**
> **username_0**: 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.  

---

