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
134
135
136
137
138
139
|
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 1ABD0C8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Sep 2018 13:53:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com
[209.85.208.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F3ABD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Sep 2018 13:53:43 +0000 (UTC)
Received: by mail-ed1-f48.google.com with SMTP id f38-v6so843357edd.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 03 Sep 2018 06:53:43 -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:content-transfer-encoding;
bh=aMAJmXGind57xBDfHNBWrMwEZrfeg8zfcfaE7wctbA8=;
b=en/ZuNYqAfKE22sMF1fWoGl/9LtGPym+3Y4+fof6WmoXWuPlKLoxKyJKKu4B3Z0Kyk
7ibVKCF1dUGRatR/pkiOcuxKUUTKoL5hrtHv9iJOgPY5rcWCXs9TwJGYO73RG2qP6wfK
Q9wuWEJmfvt3u0TJGPCfqFztkYmAEiIsTrWpi+KX6Z0xxw10tUplhPZlhFqtBE4m+MF6
pKBx1v+cNtRVWTShkSIVZbDwMa0Lm/BZ8WM+Y1NtJD32t/rwyERgadzRLBXfPPf4kshm
cAtEcY5RFab7HqBSc3cneek13Y3Cd5aHedWWh31nh/HV00X1gIE73PHJCcirCzBpMrej
eOMA==
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:content-transfer-encoding;
bh=aMAJmXGind57xBDfHNBWrMwEZrfeg8zfcfaE7wctbA8=;
b=IfO2XhV5VFx2Uihwi3TirqA2ISDntrtuKLstjxjPvbWcqLzN0FfPB5eqoJHBKez4V5
Lz15cTFU/TaPIoiQfGKfKEswSsXN+KoHglx6/1atT67mMWglZBqPC2ljGgDc9RuZYXLI
eWrBTT6XjBiUcioSy6O47U0OPs/Zpy7a7Nqz3BB7BHl5Pr7yrJZbG/GUf8tNg3ntVwwb
BFlyHwqHXlUaBIYFHIcrgW7SWDg+xUmtMTeVvc6KunowcaTu4cLpQ1CDJ/1H604tvack
z1ZrfBC9xkzVVkchBXSiHsvE1+YT19szIMO0ILU0pBvnBs0dIl3GVnb82IP60I/SapP6
uR3g==
X-Gm-Message-State: APzg51DxLrDfR2iK1WvE+5cjWkA+cFJ7dCrOYttTYP+zGDnxZYIVQ0Yf
glyHSFYkIGdrp2W44jAieP0=
X-Google-Smtp-Source: ANB0Vdb3N6bqrIK6+oXN8CQLcRJOuaEche9ot7lktV7uitedLMxeqVXgrSDctRZl+FiLdXd5Fblk4A==
X-Received: by 2002:a50:9feb:: with SMTP id
c98-v6mr32640155edf.130.1535982821908;
Mon, 03 Sep 2018 06:53:41 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
c24-v6sm7818651ede.53.2018.09.03.06.53.40
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 03 Sep 2018 06:53:40 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <23B1C9E3-9C94-43A3-A543-0AF9A8C10C7E@xbt.hk>
References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
<B35E0135-2135-405A-9627-F67EFB9D2614@xbt.hk>
<87sh2vlgsc.fsf@gmail.com>
<23B1C9E3-9C94-43A3-A543-0AF9A8C10C7E@xbt.hk>
Date: Mon, 03 Sep 2018 15:53:33 +0200
Message-ID: <87in3mlmaq.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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
X-Mailman-Approved-At: Mon, 03 Sep 2018 23:25:52 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme
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: Mon, 03 Sep 2018 13:53:44 -0000
Johnson Lau <jl2012@xbt.hk> writes:
> Great, I=E2=80=99ll revise it.
>
> Follow-up questions:
>
> 1. Is there any useful case which one would like to use NOINPUT with
> scriptCode and/or scriptPubKey committed? (Note that with
> taproot/MAST, scriptCode and scriptPubKey are not
> interchangeable. scriptPubKey commits to all branches, and scriptCode
> is just one script branch). If yes, we could make this configurable.
There is the poor man's malleability fix that you get if you make only
the previous outpoint rewritable, but that use-case is better covered by
segwit already, and since both of our proposals would be for segwit
outputs only, I don't see a point in doing that.
> 2. Which of the following approaches is better?
> A) sign scriptPubKey in every cases except NOINPUT
> B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every=
cases, including NOINPUT
> C) all of the above
> D) none of the above
What do we effectively gain by committing to the scriptPubkey type? Is
the concern here that we might run into ambiguity about whether this is
a MAST, P2SH, or similar output, allowing an attacker to sideload
unwanted effects?
> Option B is very easy to implement as SignatureHash() could
> distinguish the type by the size of scriptSig in TxTo. Option A is
> more complicated as GenericTransactionSignatureChecker needs to know
> the scriptPubKey.
>
> If the only reason for doing this is to allow hardware wallet to
> distinguish the segwit type, option B is probably enough. This is also
> compatible with eltoo.
Agreed on compatibility :-)
> Option A is useful when a hardware wallet reuses the same public key
> in different scripts, but it couldn=E2=80=99t be applied to NOINPUT
>
> 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use
> NOINPUT|SINGLE to allow fee pumping, since it is an
> one-input-one-output tx. This is not possible with the existing LN as
> the tx is one-input-two-output. If we had DUALOUTPUT which signs the
> matched and last output, fee-pumping would be possible in the existing
> LN.
That's a very strange concept, but it strongly relies on the structure
of the commitment, having two outputs. As soon as we have HTLCs included
in the commitment we no longer have 2 outputs (2 for the endpoints, and
1 as a base for the two-phase HTLC resolution), so this would be a
rather brittle fix or would require major restructuring of LN imho.
Cheers,
Christian
|
