1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1548C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 26 Jul 2021 21:08:37 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id d18so17903422lfb.6
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<20210725053803.fnmd6etv3f7x3u3p@ganymede>
<CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
In-Reply-To: <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Mon, 26 Jul 2021 22:08:09 +0100
Message-ID: <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
<div dir=3D"ltr"><div dir=3D"ltr">Hi Billy!</div><div dir=3D"ltr"><br></div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><span style=3D"">See above, but to break down that=
situation a bit further, these are the two situations I can think of:</spa=
n><br></div><div><div><ol><li style=3D"padding-bottom:0.6001em">The opcode =
limits user/group A to send the output to user/group B</li><li style=3D"pad=
ding-bottom:0.6001em">The opcode limits user A to send from one address the=
y own to another address they own.=C2=A0</li></ol></div></div></div></block=
quote><div><span style=3D"">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.</span></div><div><span style=3D""><br=
></span></div><div><span style=3D"">But how is that any better than a 2-of-=
2 multisig? Isn't the end result exactly=C2=A0the same?</span><br></div=
><div><span style=3D""><br></span></div><div><span style=3D"">James</span><=
/div></div></div>
--000000000000085c3305c80d285b--
|
