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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DBBBA157B;
Tue, 1 Oct 2019 14:27:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com
[209.85.208.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 415EE189;
Tue, 1 Oct 2019 14:27:46 +0000 (UTC)
Received: by mail-ed1-f44.google.com with SMTP id l21so12103842edr.5;
Tue, 01 Oct 2019 07:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version; bh=hzVotQYitl00VcN8MS99CdnasZQLSUMuEueHu2I/q5Y=;
b=BStIt7nhoAaRD0AfmdlZT9Wnd+OgVEwSHbdPUFlwu+sBXeoZqKWeTNbrWZPxqSg2x7
BdLvNDwWJs39bMkotVm4Tz5e0YvZBzO6RElVgtWlaKOVmfox9WJZPIxnZGQ6JUUCYYle
u0lQkfj82sZc5cRkFQGscKfFBRBGuMN4YRtwi5nQpmCdIx8DwbOMqg6d2FkNZiIaHDVU
9Anvol+A40QzarbTl5jz5wx5RD2ravjaSDOR8byEQVRdWewTBmXzI3MgVSj6SL/vk2Ls
SERr/2l4M8o1vzt9n05bRjLc6cFODE5tHBHtWa5PJkgk6H3VhidjAi9rPAutOX4QwUCo
5jKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version;
bh=hzVotQYitl00VcN8MS99CdnasZQLSUMuEueHu2I/q5Y=;
b=oprKkhLHihtkLJiQsp5lKypf+muVJ3dan9/JGpzgioAZdNbx9gtwU1YXy1NvdzljUi
pxu4k2WMIBU3cZUDrvKEWZC1WOVxb9H8tNEiR7eRMbhLM8W+ukozsMbLxH0qc6vsFiOa
RK2zfDK2whLoXwfRrR80ZQbKHO+cgIDT8yYwphzGvcHNjOFs4gRSUxoy2DKCe1lN/D3+
AsfVOT66YK6Iwp8bFrNpS+n+58hmXVyY/86BqICYNhuegFrf6frse2oPpyegXFa9H4rX
mqLTI+xAzhD+/fHvVrOlINFnKvtLH6QSrDC6CBWmmzgkpgScYsqBAD2b9AoNAdbKAsMj
Y0Aw==
X-Gm-Message-State: APjAAAUUjPrHiYZPSDy6ykRsq/OKDmrRnsrIXyIbW2QTVxaKCVI7liGI
nosJ9M05UdP7zCOB1Lr5xM18lcIsd7o=
X-Google-Smtp-Source: APXvYqw68nwO0oNUfLIkmkLvhRIFJPPFBOmUQQFnT86Nbuasff7EUu2+5Aa2ksUX2dRFSqGjQHbYig==
X-Received: by 2002:a17:906:5fc4:: with SMTP id
k4mr24759719ejv.300.1569940064834;
Tue, 01 Oct 2019 07:27:44 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa])
by smtp.gmail.com with ESMTPSA id
u30sm3138638edd.18.2019.10.01.07.27.44
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Tue, 01 Oct 2019 07:27:44 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <gPtVJarazpIb7PaNu3ngXLKG2U4cIBfT9lb-04tltIrxufUUP4hMr08vU8Af19My-b5UeVwwo3BYhkDrVwEu1EjS_MMW5aXOx1sVub8MCIE=@protonmail.com>
References: <87wodp7w9f.fsf@gmail.com>
<-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
<gPtVJarazpIb7PaNu3ngXLKG2U4cIBfT9lb-04tltIrxufUUP4hMr08vU8Af19My-b5UeVwwo3BYhkDrVwEu1EjS_MMW5aXOx1sVub8MCIE=@protonmail.com>
Date: Tue, 01 Oct 2019 16:26:39 +0200
Message-ID: <87r23w7d9c.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: "lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
anyprevout
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 01 Oct 2019 14:27:47 -0000
ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
> To elucidate further ---
>
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
>
> This new opcode ignores any `SIGHASH` flags, if present, on a
> signature, but instead hashes the current transaction without the
> input references, then checks that hash to the signature.
>
> This is equivalent to `SIGHASH_NOINPUT`.
>
> Yet as an opcode, it would be possible to embed in a Taproot script.
>
> For example, a Decker-Russell-Osuntokun would have an internal Taproot
> point be a 2-of-2, then have a script `OP_1
> OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden
> script, but cooperative closes would use the 2-of-2 directly.
>
> Of note, is that any special SCRIPT would already be supportable by Taproot.
> This includes SCRIPTs that may potentially lose funds for the user.
> Yet such SCRIPTs are already targetable by a Taproot address.
>
> If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not
> so concerned about Taproot abuse?
That would certainly be another possibility, which I have not explored
in detail so far. Due to the similarity between the various signature
checking op-codes it felt that it should be a sighash flag, and it
neatly slotted into the already existing flags. If we go for a separate
opcode we might end up reinventing the wheel, and to be honest I feared
that proposing a new opcode would get us into bikeshedding territory
(which I apparently failed to avoid with the sighash flag anyway...).
The advantage would be that with the sighash flag the spender is in
charge of specifying the flags, whereas with an opcode the output
dictates the signature verification modalities. The downside is the
increased design space.
What do others think? Would this be an acceptable opt-in mechanism that
addresses the main concerns?
Cheers,
Christian
|
