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
|
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 40608A95
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 14:12:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com
[209.85.128.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CC8D6A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 14:12:37 +0000 (UTC)
Received: by mail-wr0-f174.google.com with SMTP id p18-v6so2181816wrm.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 07:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=WjyIH8IX7env16dLG+GZOLE93dZF6La8w1abKfxTaGE=;
b=XmAdEptaHW11ARJYVo22NF3qfxlAixlgvZkPtdjjR+DhS9+B3gkmU+r97NrMpPbmiu
qGzKvZ/tOuR165sZNP2Tf/v614TxijeJDYmHPg7YSRA+F7+lkdlj19vwa7n8uCg4AxPS
15UyBawv32U0b9PL8b2pnKlUHOkLTVRMmOf5UOn6cERYlKIbpteRFwEM2XTjuKS1XM7v
FggMnsu2NIUq9M47kcv1ZdnTU+mJ4yGGHnDVjhEJkkrs1f5N5STPOxMOo8/+CPvsoXhz
ixEzHRi1KRXci2SDCrRak8YaFE5xzKgqFKEuuXO95tUHYEGcdMKyuDbT7iNVggpeywSV
Efbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=WjyIH8IX7env16dLG+GZOLE93dZF6La8w1abKfxTaGE=;
b=rZwP0Ejeg69rDqmy0xfq7Z5yQCfWjHaho0wFO8YKIBVKNY4o4FT+TmD++1JeY75FuG
vLZAmm6yQlrFTpN2xPlNUrSIvJPpFw6oPidsGb3tB7fM6nAaj3WDJWy1fxMObjEldEcs
zlB4mfjiOT8EWTxxln35F9gYjjndqD2TsT8a775+YybkgbkmfaQ0B3uSEoLMrHgSSXVN
KsT3wc+5RXVpv1lcNUPRdE6LuB6v/OkQktUp5WCBVQaLuEqwhybHAtxnsUIT+nSDWXrE
sNU0O7tffP/Zvqr1C3OJ8KM3hHh2aApWzF7hyfMEm4tHshzP5Qr0tV62iwuAxxOak9cg
yruw==
X-Gm-Message-State: ALKqPwfkAAPxrzMs0Yz6xDvZVuS3tlvt6HRZMtzGfWQ3aFad/tLnUMTP
2YCNua3ZeXF5IsrGUUC1XdylIm7k
X-Google-Smtp-Source: AB8JxZqDfpsi0657JPEQWOByvQcrbIXOf4KYiU9If6eGkk0Y7AVn2bvxYUEcTjwn5/tvDxnK00Xv6g==
X-Received: by 2002:adf:80cd:: with SMTP id
71-v6mr1466702wrl.238.1525961556083;
Thu, 10 May 2018 07:12:36 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
m134-v6sm1468421wmg.4.2018.05.10.07.12.34
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 10 May 2018 07:12:35 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAO3Pvs-8cX2Gdgu0cb0LdkY6ErguKkzs8pLZapFTD5JdpGms2A@mail.gmail.com>
References: <871sewirni.fsf@gmail.com>
<CAO3Pvs-8cX2Gdgu0cb0LdkY6ErguKkzs8pLZapFTD5JdpGms2A@mail.gmail.com>
Date: Thu, 10 May 2018 16:12:21 +0200
Message-ID: <87y3gr38hm.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
Subject: Re: [bitcoin-dev] BIP sighash_noinput
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: Thu, 10 May 2018 14:12:38 -0000
Olaoluwa Osuntokun <laolu32@gmail.com> writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial version I
> implemented still committed to the script being sent, while this new
> version just relies on witness validity instead. This approach is even
> more flexible as the script attached to the output being spent can
> change, without rendering the spending transaction invalid as long as
> the witness still ratifies a branch in the output's predicate.
Yeah, we removed the script commitment out of necessity for eltoo, but
it seems to add a lot of flexibility that might be useful. One
additional use-case that came to mind is having a recovery transaction
for vault-like scenarios, i.e., a transaction that can short-circuit a
thawing process of frozen funds. You'd keep that transaction in a vault,
pre-signed and bind it to whatever action you'd like to interrupt.
> Given that this would introduce a _new_ sighash flag, perhaps we
> should also attempt to bundle additional more flexible sighash flags
> concurrently as well? This would require a larger overhaul w.r.t to
> how sighash flags are interpreted, so in this case, we may need to
> introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now),
> which would consume an available noop opcode. As a template for more
> fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3]
> (particularly the "New nHashType definitions" section). This was
> originally proposed in the context of his merklized script work as it
> more or less opened up a new opportunity to further modify script
> within the context of merklized script executions. The approach reads
> in the sighash flags as a bit vector, and allows developers to express
> things like: "don't sign the input value, nor the sequence, but sign
> the output of this input, and ONLY the script of this output". This
> approach is _extremely_ powerful, and one would be able to express the
> equivalent of no_input by setting the appropriate bits in the sighash.
I purposefully made the proposal as small and as well defined as
possible, with a number of possible applications to back it, since I
think this might be the best way to introduce a new feature and make it
as uncontroversial as possible. I'm not opposed to additional flags
being deployed in parallel, but they'll need their own justification and
analysis, and shouldn't be rushed just "because we're doing noinput".
Going for a separate op-code is definitely an option we considered, but
just for noinput it'd be duplicating quite a lot of existing
functionality. With additional sighash flags it might become necessary,
but I don't think it is necessary just for noinput.
> Looking forward in hearing y'alls thoughts on this approach, thanks.
>
> [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
> [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
> [3]: https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
>
> -- Laolu
|
