From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1548C000E for ; Mon, 26 Jul 2021 21:08:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B7417607A6 for ; Mon, 26 Jul 2021 21:08:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 lgQIeG9WjLsF for ; Mon, 26 Jul 2021 21:08:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8E5F8600B4 for ; Mon, 26 Jul 2021 21:08:37 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id d18so17903422lfb.6 for ; Mon, 26 Jul 2021 14:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7VBkbtciLB983hkv1uBj1sxNxrXmrJX9enXJMY46g3M=; b=Gnihh3v9tj2fPnzgtrhgqFYkVqIsSkphmF7E2xkRrTD7+lHl8HvXrCJtdfxo+gEhQ2 XB2gMw8sAfExF3/okIEFFZvDPhlvCJKmLATqirE/C92nAlvM44ah6j+PV7PCRy6fM5do ACdSZZfcoWakaGKOYSgbBlZGVjDtiTvcElr3d9I+nCNNggDNLMysuAzeS9C66KCvQsBa eoayulr7ofT27Sntk3ZKJQx2bZvM+SPL3R8NyaM4SRoFOoKICnI8zPXO1KhilH6p/ATU 8bqWD8stNvctRF2bwvWSS+X8SUJ/ix9ndUHylVKGxr4GsQQvzyaAwcgZjjLtxzo/SY12 h/Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7VBkbtciLB983hkv1uBj1sxNxrXmrJX9enXJMY46g3M=; b=o5BTJM/0e4uGJSTfoJsxC53EViUb5CByHu6A3a/+LDtkAW1S1yEx1QMquPNJabpsLL 60ygIB/KWyQJuEg5lngPWD3Rz05eDgSJ2DISZA1KkzmcMDTPRCUgYlEK6n99wXYrIvSn LjicT59/l68BJchzHnD/MPgWZD3LdaJGAm3CA1wjyTvcYBtaeQ8aOdFsI066MJ1y97/w dp0ixHh7xPxlJXjZeB2I6v1GKVS+KEsRqQFA/p0tMZKACo+edLpXfKsa40BJtSHJJC7U 1tThQdmy17qd4lsuPdWoLb2CNRW+5iHrNr4ace1nx6wrbM0obdlrh9lxe58YFKQYS3SG pCsA== X-Gm-Message-State: AOAM5321lKAD3LsNrug+dspsnuW7/fkJxb1hvhZaVK42/SC3QIywKigo kjxFjVp/ayo5V28n9Zh9pw1UnBFE0igIDqQL0rc= X-Google-Smtp-Source: ABdhPJwzYtkgnKBhKT3wfM2kjjCERr4NZRq/ML5q8EJ1bH+Q7eJqlyYDLcBl5uWrYVaz2fff3N68ZPwFfAZv8Yzwh+8= X-Received: by 2002:a19:504d:: with SMTP id z13mr14005120lfj.462.1627333715318; Mon, 26 Jul 2021 14:08:35 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: James MacWhyte Date: Mon, 26 Jul 2021 22:08:09 +0100 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000085c3305c80d285b" Subject: Re: [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: Mon, 26 Jul 2021 21:08:39 -0000 --000000000000085c3305c80d285b Content-Type: text/plain; charset="UTF-8" Hi Billy! See above, but to break down that situation a bit further, these are the > two situations I can think of: > > 1. The opcode limits user/group A to send the output to user/group B > 2. The opcode limits user A to send from one address they own to > another address they own. > > I'm trying to think of a good use case for this type of opcode. In these examples, an attacker who compromises the key for user A can't steal the money because it can only be sent to user B. So if the attacker wants to steal the funds, they would need to compromise the keys of both user A and user B. But how is that any better than a 2-of-2 multisig? Isn't the end result exactly the same? James --000000000000085c3305c80d285b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Billy!

See above, but to break down that= situation a bit further, these are the two situations I can think of:
  1. The opcode = limits user/group A to send the output to user/group B
  2. The opcode limits user A to send from one address the= y own to another address they own.=C2=A0
I'm trying to think of a good use case for = this type of opcode. In these examples, an attacker who compromises the key= for user A can't steal the money because it can only be sent to user B= . So if the attacker wants to steal the funds, they would need to compromis= e the keys of both user A and user B.
But how is that any better than a 2-of-= 2 multisig? Isn't the end result exactly=C2=A0the same?

James<= /div>
--000000000000085c3305c80d285b--