<p>While Bitcoin does not currently have any covenants, <a href="https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki" rel="nofollow noreferrer">BIP119</a>: Checktemplateverify proposes a new op-code that would allow you to do exactly that.</p>
<p>The proposal is currently in &quot;draft&quot; status.</p>

CC BY-SA 4.0
2020-11-25T22:57:19.943Z
2020-11-25T22:57:19.943Z
Murch
<p><strong>TL;DR</strong>: Can be done with</p>
<pre><code>                                                      ____  pk_B
       ____                                          |    |-------&gt;
Alice |    |2-of-{pk_A, pk_B}      2-of-{pk_A, pk_B} |    |  0.5
-----&gt;|tx_1|------------------&gt;    -----------------&gt;|tx_2|
  1   |____|         1                               |    | pk_C
                                                     |____|-------&gt;
                                                             0.5
</code></pre>
<hr />
<p>There is currently <strong>no such script</strong>. You can do it though with a little protocol and <strong>two transactions</strong>:</p>
<ol start="0">
<li>Alice knows Bob's and Carol's keys (pk_B, pk_C). Bob knows Alice's and Carol's keys. Alice and Bob have already agreed to do this kind of payment out-of-band.</li>
<li>Alice creates <strong>tx_1</strong> that spends her 1 BTC and has a single <strong>(1, 2-of-{pk_A, pk_B})</strong> output [where the output is (coins, script) and n-of-{m public keys} is an n-of-m-multisig]. She does not broadcast tx_1 yet.</li>
<li>Alice creates <strong>tx_2</strong> with a 2-of-{pk_A, pk_B} input that spends tx_1 and two outputs: <strong>(0.5, pk_B), (0.5, pk_C)</strong>. She signs tx_2 with her sk_A and sends the signature, sig_A, to Bob.</li>
<li>Bob recreates tx_2, verifies sig_A with pk_A and replies &quot;OK&quot; to Alice.</li>
<li>Alice broadcasts tx_1.</li>
<li>Bob signs tx_2 with his sk_B, adds the two signatures to tx_2 and broadcasts it.</li>
</ol>
<p>The only way for Bob to get any coins is if he uses Alice's signature, which is valid only for tx_2, which splits Alice's coin equally among Bob and Carol. So Bob is incentivized to play along.</p>
<p>The <strong>drawbacks</strong> compared to a single script are that</p>
<ol>
<li>Alice and Bob must establish a communication channel,</li>
<li>Bob must save Alice's signature and use it later,</li>
<li>If Bob doesn't publish tx_2, the money is stuck,</li>
<li>Two transactions are needed instead of one.</li>
</ol>
<p>You can <strong>avoid</strong> the first two issues by having Alice put sig_A in an additional <strong>OP_RETURN</strong> in tx_1. OP_RETURN is big enough to fit sig_A and tx_1 will still be standard. Making sig_A public is secure because only Bob can create the other signature needed to spend tx_1. The third issue can be avoided by adding a timelock to the output of tx_1, after which Alice can spend the coin as she pleases. I don't see any way to avoid the last issue.</p>

CC BY-SA 4.0
2020-11-26T11:14:08.140Z
2020-11-26T11:14:08.140Z
orfeas
<p>No, that is not possible, and doing so can be problematic.</p>
<p>Such scripts would need the ability to inspect the spending transaction and this is currently not allowed or possible; the script interpreter does not have access to other parts of the transaction.</p>
<p>Furthermore, if implemented naively, this could allow for widespread censorship and centralized control of Bitcoin. In essence, such scripts could be written to require that transactions do not send money to some blacklisted addresses, and at the same time require that all receivers in that transaction also have this same requirement. This could lead to services blacklisting some addresses, and then forcing their users to also blacklist those addresses when they withdraw from the exchange. And the recursive nature of that means that all subsequent transactions also have the same blacklist.</p>

CC BY-SA 4.0
2020-11-26T08:40:07.187Z
Sounds a bit like copyleft or share-alike licenses.
ComFreek
CC BY-SA 4.0
2020-11-25T22:42:52.610Z
2020-11-25T22:42:52.610Z
Ava Chow
<p>Is there a way to use Bitcoin script to force payment for the receiver?</p>
<p>I do not mind if it's a non-standard transaction, just curious if Bitcoin script itself allows expression of something like that.</p>
<p>For example, is it possible to write a locking script such that:</p>
<ol>
<li>Alice sends 1 BTC to Bob</li>
<li>But Bob can ONLY spend if Bob sends 0.5 BTC to Carol in the next transaction</li>
</ol>

<script><development>
A Bitcoin locking script to force a certain payment to the receiver?
Vlad
# A Bitcoin locking script to force a certain payment to the receiver?

(Asked by: username_0 on 2020-11-25)

Is there a way to use Bitcoin script to force payment for the receiver?

I do not mind if it's a non-standard transaction, just curious if Bitcoin script itself allows expression of something like that.

For example, is it possible to write a locking script such that:

1. Alice sends 1 BTC to Bob
2. But Bob can ONLY spend if Bob sends 0.5 BTC to Carol in the next transaction

**Tags:** script, development


---

## 3 answers

### Answer by username_3 on 2020-11-25. Score: 4 | Accepted answer

No, that is not possible, and doing so can be problematic.

Such scripts would need the ability to inspect the spending transaction and this is currently not allowed or possible; the script interpreter does not have access to other parts of the transaction.

Furthermore, if implemented naively, this could allow for widespread censorship and centralized control of Bitcoin. In essence, such scripts could be written to require that transactions do not send money to some blacklisted addresses, and at the same time require that all receivers in that transaction also have this same requirement. This could lead to services blacklisting some addresses, and then forcing their users to also blacklist those addresses when they withdraw from the exchange. And the recursive nature of that means that all subsequent transactions also have the same blacklist.

> **Comments:**
> **username_4**: Sounds a bit like copyleft or share-alike licenses.  

---

### Answer by username_1 on 2020-11-25. Score: 4

While Bitcoin does not currently have any covenants, [BIP119](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki): Checktemplateverify proposes a new op-code that would allow you to do exactly that.

The proposal is currently in "draft" status.


---

### Answer by username_2 on 2020-11-26. Score: 3

**TL;DR**: Can be done with

```
                                                      ____  pk_B
       ____                                          |    |------->
Alice |    |2-of-{pk_A, pk_B}      2-of-{pk_A, pk_B} |    |  0.5
----->|tx_1|------------------>    ----------------->|tx_2|
  1   |____|         1                               |    | pk_C
                                                     |____|------->
                                                             0.5

```

---

There is currently **no such script**. You can do it though with a little protocol and **two transactions**:

0. Alice knows Bob's and Carol's keys (pk\_B, pk\_C). Bob knows Alice's and Carol's keys. Alice and Bob have already agreed to do this kind of payment out-of-band.
1. Alice creates **tx\_1** that spends her 1 BTC and has a single **(1, 2-of-{pk\_A, pk\_B})** output [where the output is (coins, script) and n-of-{m public keys} is an n-of-m-multisig]. She does not broadcast tx\_1 yet.
2. Alice creates **tx\_2** with a 2-of-{pk\_A, pk\_B} input that spends tx\_1 and two outputs: **(0.5, pk\_B), (0.5, pk\_C)**. She signs tx\_2 with her sk\_A and sends the signature, sig\_A, to Bob.
3. Bob recreates tx\_2, verifies sig\_A with pk\_A and replies "OK" to Alice.
4. Alice broadcasts tx\_1.
5. Bob signs tx\_2 with his sk\_B, adds the two signatures to tx\_2 and broadcasts it.

The only way for Bob to get any coins is if he uses Alice's signature, which is valid only for tx\_2, which splits Alice's coin equally among Bob and Carol. So Bob is incentivized to play along.

The **drawbacks** compared to a single script are that

1. Alice and Bob must establish a communication channel,
2. Bob must save Alice's signature and use it later,
3. If Bob doesn't publish tx\_2, the money is stuck,
4. Two transactions are needed instead of one.

You can **avoid** the first two issues by having Alice put sig\_A in an additional **OP\_RETURN** in tx\_1. OP\_RETURN is big enough to fit sig\_A and tx\_1 will still be standard. Making sig\_A public is secure because only Bob can create the other signature needed to spend tx\_1. The third issue can be avoided by adding a timelock to the output of tx\_1, after which Alice can spend the coin as she pleases. I don't see any way to avoid the last issue.


---

