From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0EB7DC000E for ; 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 ; 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 ; 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 ; Wed, 21 Jul 2021 05:56:28 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id hc15so1464258ejc.4 for ; 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 Date: Tue, 20 Jul 2021 22:56:10 -0700 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . 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 *. 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
Hi All,

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'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).

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

This opcode has a few different applicatio= ns, but my primary motivation for creating this opcode is to create more fl= exible wallet vaults.

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.

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

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. I&#= 39;d love to hear what people think about it, what problems it might have t= hat 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--