MIME-Version: 1.0
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 20 Jul 2021 22:56:10 -0700
Message-ID: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ba22e905c79bd47d"
Subject: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an
	alternative to OP_CTV)
Precedence: list

--000000000000ba22e905c79bd47d
Content-Type: text/plain; charset="UTF-8"

Hi All,

I have been working on a proposal for an opcode I call
OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path
to restrict the destination address that an output's coins can be directed
to. When the destination address is something like a P2SH address, this
allows step-wise covenant scripts (where one script must lead to another).

This involves both specifying particular addresses the output is allowed to
send coins to, as well as constraining the amount of the fee that output is
allowed to contribute to. For example, if you had an output that contains
1000 satoshi, you could specify that a maximum of ~100 sats of that output
go to the miner fee and the other ~900 sats must go to one of a list of
specified addresses (~ meaning approximately, because the fee is specified
relative to recent median fee rates - details in the proposal).

This opcode has a few different applications, but my primary motivation for
creating this opcode is to create more flexible wallet vaults
<https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults>
.

To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be
created with OP_CTV must be created in specified chunks: the address is
explicitly tied to a particular utxo sent to it. To retrieve coins from the
vault, the output must be spent by one of a specific set of transactions
(potentially one per spend path). Outputs cannot be arbitrarily combined
into a transaction, and there is no flexibility whatsoever in deciding
options at the time of spending from the vault - all options must be
premeditated and encoded into the address itself when sending money to the
vault. This has some related foot-gun scenarios, where the wallet vault has
addresses that if sent to would generally result in burning those coins,
unless done in a very specific way by the owner of the vault.

By contrast, OP_CD allows a lot more flexibility because it only constrains
the address to be sent to from the vault, but doesn't put additional
constraints on the transaction. This means that outputs can be combined
into a single transaction like you would expect in a normal transaction. It
also means that external users (people who don't own the vault) can safely
send money directly into the vault without coins being burned.

*I have the proposal for this opcode up here:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>*.
I'd love to hear what people think about it, what problems it might have
that I've missed, or other issues or suggestions surrounding this. I'd also
appreciate any input that would help me improve the presentation of the
opcode.

Thanks!

--000000000000ba22e905c79bd47d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi All,</div><div><br></div>I have been working on a =
proposal for an opcode I call OP_CONSTRAINDESTINATION. The purpose of the o=
pcode is to allow a spend-path to restrict the destination address that an =
output&#39;s coins can be directed to. When the destination address is some=
thing like a P2SH address, this allows step-wise covenant scripts (where on=
e script must lead to another).<br><br>This involves both specifying partic=
ular addresses the output is allowed to send coins to, as well as constrain=
ing the amount of the fee that output is allowed to contribute to. For exam=
ple, if you had an output that contains 1000 satoshi, you could specify tha=
t a maximum of ~100 sats of that output go to the miner fee and the other ~=
900 sats must go to one of a list of specified addresses (~ meaning approxi=
mately, because the fee is specified relative to recent median fee rates - =
details in the proposal).<br><br>This opcode has a few different applicatio=
ns, but my primary motivation for creating this opcode is to create more fl=
exible <a href=3D"https://hackingdistributed.com/2016/02/26/how-to-implemen=
t-secure-bitcoin-vaults">wallet vaults</a>.<br><br>To compare this opcode t=
o OP_CHECKTEMPLATEVERIFY, wallet vaults that can be created with OP_CTV mus=
t be created in specified chunks: the address is explicitly tied to a parti=
cular utxo sent to it. To retrieve coins from the vault, the output must be=
 spent by one of a specific set of transactions (potentially one per spend =
path). Outputs cannot be arbitrarily combined into a transaction, and there=
 is no flexibility whatsoever in deciding options at the time of spending f=
rom the vault - all options must be premeditated and encoded into the addre=
ss itself when sending money to the vault. This has some related foot-gun s=
cenarios, where the wallet vault has addresses that if sent to would genera=
lly result in burning those coins, unless done in a very specific way by th=
e owner of the vault.<div><br>By contrast, OP_CD allows a lot more flexibil=
ity because it only constrains the address to be sent to from the vault, bu=
t doesn&#39;t put additional constraints on the transaction. This means tha=
t outputs can be combined into a single transaction like you would expect i=
n a normal transaction. It also means that external users (people who don&#=
39;t own the vault) can safely send money directly into the vault without c=
oins being burned.<br><br><b>I have the proposal for this opcode up here: <=
a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/=
main/cd/bip-constraindestination.md">https://github.com/fresheneesz/bip-eff=
icient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md</a></b>. I&#=
39;d love to hear what people think about it, what problems it might have t=
hat I&#39;ve missed, or other issues or suggestions surrounding this. I&#39=
;d also appreciate any input that would help me improve the presentation of=
 the opcode.<br><br>Thanks!<br></div></div>

--000000000000ba22e905c79bd47d--