<p>As mentioned by stickies-v, covenants are currently not part of the Bitcoin protocol. However, that doesn't mean a construction like you want is impossible to achieve another way. Simply send your bitcoin to a single-key output (like P2WPKH or P2TR without a valid script path commitment), then pre-sign a transaction sending your coins to the target address, timelocked 5 years into the future, and publish it somewhere someone could be expected to grab it from and broadcast it 5 years later.</p>
<p>The publishing step might be tricky to do right as you need to consider long-term storage issues, but even if covenants were available in Bitcoin, you would have the exact same problem of having to publish the spending script and Merkle path for anyone to be able to spend the output.</p>

CC BY-SA 4.0
2022-08-17T15:29:47.560Z
I could just publish the timelocked transaction in public right? In a tweet or in some forum post, then put it on archive.today and the wayback machine. If for whatever reason I lost my keys I just have to wait 5 years and then I can broadcast the transaction to get my coins back through the exchange, or am I missing something?
Fabian
CC BY-SA 4.0
2022-08-17T16:24:05.537Z
Yes, if you're still around at that time and thus don't have to rely on anyone else to broadcast the transaction, it becomes a lot easier. I understood your words "spendable by anyone" as implying you yourself wouldn't need to take any action at that time.
Vojtěch Strnad
CC BY-SA 4.0
2022-08-30T10:26:07.527Z
Perhaps make it clear in your answer that your covenant scheme requires the private key to be deleted so an alternative transaction can't be constructed
Michael Folkson
CC BY-SA 4.0
2022-08-30T16:08:11.157Z
@MichaelFolkson: OP wants the coin to be spendable by the private key owner at any time (condition A), so it should not be deleted. The pre-signed transaction is simply a backup.
Vojtěch Strnad
CC BY-SA 4.0
2022-08-16T11:47:18.963Z
2022-08-16T11:47:18.963Z
Vojtěch Strnad
<p>Bitcoin Script has always had support for multiple spending conditions, see e.g. this overview of <a href="https://en.bitcoin.it/wiki/Script#Flow_control" rel="nofollow noreferrer">flow control operators</a>. What taproot changes (amongst others) is that you can now construct a transaction such that when you spend the output, you only have to show the spending condition that you're actually using. The other conditions are not revealed (and thus don't take up any blockspace). <a href="https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f" rel="nofollow noreferrer">&quot;What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?&quot;</a> goes into more detail on how this works.</p>
<blockquote>
<p>Spendable by anyone but only to a specific address</p>
</blockquote>
<p>Script does not currently support this type of introspection. <a href="https://bitcoinops.org/en/topics/covenants/" rel="nofollow noreferrer">Covenants</a> have been an area of active debate recently and could add such functionality if and when consensus is reached. See e.g. <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html" rel="nofollow noreferrer">&quot;On a new community process to specify covenants&quot;</a> as a starting point for more research.</p>

CC BY-SA 4.0
2022-08-16T09:42:31.190Z
2022-08-30T10:17:26.810Z
2022-08-30T10:17:26.810Z
stickies-v
<p>It is my understanding that taproot enables multiple spending conditions for an address, if this is correct, can I do something like this in Bitcoin?:</p>
<p>I send bitcoin to a taproot address where I want the spending conditions to be:</p>
<p>A) Spendable if you have the private key (me), OR:
B) Spendable by anyone but only to a specific address, and only after 5 years. (For example to a deposit address of an exchange I use)</p>

<taproot><covenants>
Spendable by me or deposit to exchange after 5 years?
Fabian
# Spendable by me or deposit to exchange after 5 years?

(Asked by: username_0 on 2022-08-16)

It is my understanding that taproot enables multiple spending conditions for an address, if this is correct, can I do something like this in Bitcoin?:

I send bitcoin to a taproot address where I want the spending conditions to be:

A) Spendable if you have the private key (me), OR:
B) Spendable by anyone but only to a specific address, and only after 5 years. (For example to a deposit address of an exchange I use)

**Tags:** taproot, covenants


---

## 2 answers

### Answer by username_3 on 2022-08-16. Score: 10 | Accepted answer

Bitcoin Script has always had support for multiple spending conditions, see e.g. this overview of [flow control operators](https://en.bitcoin.it/wiki/Script#Flow_control). What taproot changes (amongst others) is that you can now construct a transaction such that when you spend the output, you only have to show the spending condition that you're actually using. The other conditions are not revealed (and thus don't take up any blockspace). ["What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?"](https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f) goes into more detail on how this works.

> Spendable by anyone but only to a specific address

Script does not currently support this type of introspection. [Covenants](https://bitcoinops.org/en/topics/covenants/) have been an area of active debate recently and could add such functionality if and when consensus is reached. See e.g. ["On a new community process to specify covenants"](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html) as a starting point for more research.


---

### Answer by username_1 on 2022-08-16. Score: 4

As mentioned by username_3, covenants are currently not part of the Bitcoin protocol. However, that doesn't mean a construction like you want is impossible to achieve another way. Simply send your bitcoin to a single-key output (like P2WPKH or P2TR without a valid script path commitment), then pre-sign a transaction sending your coins to the target address, timelocked 5 years into the future, and publish it somewhere someone could be expected to grab it from and broadcast it 5 years later.

The publishing step might be tricky to do right as you need to consider long-term storage issues, but even if covenants were available in Bitcoin, you would have the exact same problem of having to publish the spending script and Merkle path for anyone to be able to spend the output.

> **Comments:**
> **username_0**: I could just publish the timelocked transaction in public right? In a tweet or in some forum post, then put it on archive.today and the wayback machine. If for whatever reason I lost my keys I just have to wait 5 years and then I can broadcast the transaction to get my coins back through the exchange, or am I missing something?  
> **username_1**: Yes, if you're still around at that time and thus don't have to rely on anyone else to broadcast the transaction, it becomes a lot easier. I understood your words "spendable by anyone" as implying you yourself wouldn't need to take any action at that time.  
> **username_2**: Perhaps make it clear in your answer that your covenant scheme requires the private key to be deleted so an alternative transaction can't be constructed  
> **username_1**: @username_2: OP wants the coin to be spendable by the private key owner at any time (condition A), so it should not be deleted. The pre-signed transaction is simply a backup.  

---

