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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2945C1A07
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Sep 2019 16:00:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 965A78A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Sep 2019 16:00:43 +0000 (UTC)
Date: Mon, 30 Sep 2019 16:00:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1569859241;
bh=6QrWX1ziWDKGKwDBqfH/NWSO3oXXU5bae7kTsb+BNlY=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=RoqjCefwb+84ES8ejlJ2TnS8DkBSL7jZ5IdojFBx0Oss7odN0fP6h/POAI5SK0lRJ
MoDMSUzD+fKAPQO6WzIDsDwFvV4Fu/vkK2vuQ8Cc9MALd8pLsqthaBMcBo3s4OWuek
G56Dfn2f1OwuhsDNgJ+xlI99Wx7Y0Q688IW9rQls=
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
In-Reply-To: <87wodp7w9f.fsf@gmail.com>
References: <87wodp7w9f.fsf@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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: Mon, 30 Sep 2019 16:00:45 -0000
Good morning Christian,
> The concern with output tagging is that it hurts fungibility, marking out=
puts
> used in a contract as such and making them identifiable. But maybe it wou=
ld be
> a good idea to create two domains anyway: one for user-addressable
> destinations which users can use with their general purpose wallets, and =
one
> domain for contracts, which users cannot send to directly.
I rather strongly oppose output tagging.
The entire point of for example Taproot was to reduce the variability of ho=
w outputs look like, so that unspent Taproot outputs look exactly like othe=
r unspent Taproot outputs regardless of the SCRIPT (or lack of SCRIPT) used=
to protect the outputs.
That is the reason why we would prefer to not support P2SH-wrapped Taproot =
even though P2SH-wrapping was intended to cover all future uses of SegWit, =
including SegWit v1 that Taproot will eventually get.
Indeed, if it is output tagging that gets into Bitcoin base layer, I would =
strongly suggest the below for all Decker-Russell-Osuntokun implementations=
:
* A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output,=
confirmed onchain
* A "translator transaction" spending the above and paying out to a SegWit =
v16 output-tagged output, kept offchain.
* Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT=
` spending the translator transaction output.
* Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT`=
spending the update transaction output.
The point regarding use of a commonly-known privkey to work around chaperon=
e signatures is appropriate to the above, incidentally.
In short: this is a workaround, plain and simple, and one wonders the point=
of adding *either* chaperones *or* output tagging if we will, in practice,=
just work around them anyway.
Again, the *more* important point is that special blockchain constructions =
should only be used in the "bad" unilateral close case.
In the cooperative case, we want to use simple plain bip-schnorr-signed out=
puts getting spent to further bip-schnor/Taproot SegWit v1 addresses, to in=
crease the anonymity set of all uses of Decker-Russell-Osuntokun and other =
applications that might use `SIGHASH_NOINPUT` in some edge case (but which =
resolve down to simple bip-schnorr-signed n-of-n cases when the protocol is=
completed successfully by all participants).
We already have the issue in current Lightning where the blockchain-explore=
r-revealed address for current, existing Poon-Dryja channels is unsafe to s=
end any amount to.
Granted, we should work to make things safer; but I suggest that we should =
be willing to sacrifice some amount of safety against arguably-stupid decis=
ions in order to have better privacy for larger sets of users.
>
> This also came up during the CoreDev meeting [ams-coredev]:
>
> > these sort of NOINPUT signatures are only things that are within some
> > application or within some protocol that gets negotiated between partic=
ipants,
> > but they don't cross-independent domains where you see a wallet or a pr=
otocol
> > as a kind of domain. You can't tell the difference, is this an address =
I can
> > give to someone else or not? It's all scripts, no real addresses. There=
are
> > types of outputs that are completely insecure unconditionally; there ar=
e
> > things that are protected and I can give to anyone, you don't want to r=
euse
> > it, but there's no security issue from doing so. This is an additional =
class
> > that is secure perfectly but only when used in the right way.
I submit that a Taproot whose internal Taproot point is a NUMS point (thus =
nobody knows its scalar) is similarly "secure perfectly but only when used =
in the right way".
Yet the point of Taproot is to hide these outputs until they are spent, imp=
roving their privacy while unspent.
I submit also that a Taproot whose internal Taproot point is an n-of-n of a=
ll participants, with script branches enforcing particular modes, are simil=
arly "secure perfectly but only when used in the right way", and again the =
point of Taproot is to allow the n-of-n "everybody agrees" path to hide amo=
ng the 1-of-1 whale HODLers.
In short: I do not see how you can coherently argue for "we should separate=
`SIGHASH_NOINPUT` types to a new script type" while simultaneously arguing=
"we should merge all kinds of SCRIPT usage (and non-usage) together into a=
single script type".
If we will separate `SIGHASH_NOINPUT`-enabled outputs, we should not implem=
ent Taproot, as the existing separation of P2WSH and P2WPKH is congruent to=
the proposed separation of `SIGHASH_NOINPUT`-enablement.
>
> Open questions
>
> ---------------
>
> The questions that remain to be addressed are the following:
>
> 1. General agreement on the usefulness of noinput / anyprevoutanyscript =
/
> anyprevout. While at the CoreDev meeting I think everybody agreed tha=
t
> these proposals a useful, also beyond eltoo, not everybody could be
> there. I'd therefore like to elicit some feedback from the wider comm=
unity.
I strongly agree that `NOINPUT` is useful, and I was not able to attend Cor=
eDev (at least, not with any human fleshbot already known to you --- I chec=
ked).
>
> 2. Is there strong support or opposition to the chaperone signatures
> introduced in anyprevout / anyprevoutanyscript? I think it'd be best =
to
> formulate a concrete set of pros and contras, rather than talk about
> abstract dangers or advantages.
No opposition, we will just work around this by publishing a common known p=
rivate key to use for all chaperone signatures, since all the important sec=
urity is in the `NOINPUT` signature anyway.
>
> 3. The same for output tagging / explicit opt-in. What are the advantage=
s and
> disadvantages?
Strongly oppose, see above about my argument.
>
> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce t=
he
> confusion and make for simpler discussions in the end.
Ambivalent, mildly support.
>
> 5. Anything I forgot to mention :-)
Cats are very interesting creatures, and are irrelevant to `SIGHASH_NOINPUT=
` discussion, but are extremely cute nonetheless.
Regards,
ZmnSCPxj
|
