path: root/61/6d3b3eadbc7be63437bf55cbeb3d3ca0d9d140

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0EB7DC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 21 Jul 2021 05:56:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E02AE6067E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 21 Jul 2021 05:56:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8mCfnM4OBUiN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 21 Jul 2021 05:56:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [IPv6:2a00:1450:4864:20::630])
 by smtp3.osuosl.org (Postfix) with ESMTPS id BBAD66067D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 21 Jul 2021 05:56:28 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id hc15so1464258ejc.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jul 2021 22:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=k6lniGoOQT0Go6MDlCYM+gVtrUaeljJRQNXML3PLL68=;
 b=SFrlev0VEUB92jW7z40rwfiZo7Ajc/+Pf6j6EffU5FQxHT2aULS17Bg4BAsl8OyaQH
 0DFhVHx/3gcMQ2TOC9I+LHnCB/Oq5ijmHq8FF2ujGxZkWDCpxZESEA7MN6VNiMjulMaU
 pamfXEJL0BhA/eBq9sXW7VqBk8ZbXpey7bO3OJQ0SHPL+NxiUBALmYixAO8wIYbFng0E
 PdOID8te08DrcwnOWqcpkokvrfT4XvpQU7x3uMIw0HtVGALxTP1A5CGrFYbdksA7yarq
 D1zuNtGZO2rZcURCfY5+KHLB5GXcjSZeHWDMyX5nwz1zw4rEUomykYOSSjMQp+6b2WAH
 hEoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=k6lniGoOQT0Go6MDlCYM+gVtrUaeljJRQNXML3PLL68=;
 b=az085EZF3o312zGE8uaZU+Y8fNhbeTOKnl54oWGRZc/X+FmQqMhLFYztt8ZbIW5sdu
 9cROcqr81ARdb2RfMAyn7zMPzQqhuG4KwQp02b9LX7lfS2Mz9SV7zAsz9gPnZgRazag+
 En4I1K7uk6Czl5MYdJRE+8uwVmsVZy/a6SBi1THtEzhn4wdVGz+8nUWSzvhZGb9eqfqb
 vZFouB1jkEQ+V92DCINeZwdUQe0K72jQ9k2qvSqXdIUBSz/5hX0bIi0VJJr83cqKWSRt
 IYUFalKqhopFqjRfTslOL9Vd1vX89A8XjdKshpwQRjDA+jXYogLhJiBrI4+X1OnfINvk
 ACPA==
X-Gm-Message-State: AOAM5315iDjsctec41GCertmfaztMoTDHy/5FDt9Ha/cnuSoVWGpfj0C
 lIbxK3UUsY1LCHFBC2fl5kr7h1Hm8ZXqyGDRN4uZvvG8tt0RVg==
X-Google-Smtp-Source: ABdhPJwkJKoeV+fBTW+UfAqMUK5Yu0sKSlDPt3fNOf3hsMTs7q1QuoETiCKDGciWNpcoSvf2Zjd0fH72QN8ipdeZ6iw=
X-Received: by 2002:a17:906:32d5:: with SMTP id
 k21mr36417118ejk.241.1626846986378; 
 Tue, 20 Jul 2021 22:56:26 -0700 (PDT)
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"
X-Mailman-Approved-At: Wed, 21 Jul 2021 06:46:06 +0000
Subject: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an
	alternative to OP_CTV)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2021 05:56:30 -0000

--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--