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
|
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 19CA7157B;
Tue, 1 Oct 2019 14:27:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com
[209.85.208.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 41BD98B0;
Tue, 1 Oct 2019 14:27:44 +0000 (UTC)
Received: by mail-ed1-f43.google.com with SMTP id r9so12104339edl.10;
Tue, 01 Oct 2019 07:27:44 -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=4bcIOqXq+ghsT6pL6ZqCbizZzP1HfcLNnkhCGqw7pfo=;
b=NBtw7TvICRlBa5T7cTFLpc/T29rwkK4TOJ/nTo7aMabYE4/SGo9FumCWZ4tuGb3Uhn
yFPckx28nqKQPOYqwGbAfhz1sYqQiwrHvpKE3gpQrZPWFLq5aYaxGKqwLSxAYAhhfWQv
J3VK8VGhysRCV2K7eN1mnb+kvnrg4esoP/zjl2Jt3fb3bKXxHuqW7K2+mfYYuhADzzhK
j4742dkKq/jjYJPSK74f+axuihz4bPnnnBwUL4szf9En4A7Pf07dL0GnfnFcwLiilf9z
55XomKjT+0RE4W3t8p+/0UMSiTYOgnuLmJIfddFMSHKyJD9EZ2NWyGbcyA7/MQglyE+N
wLPA==
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=4bcIOqXq+ghsT6pL6ZqCbizZzP1HfcLNnkhCGqw7pfo=;
b=rFLrncC2EpseEbE9e8oJR5UGfgFt6mJcWIWoP1yu3oR+J0kPyzmrJJI+uM6CM0Y6Yo
ENMFQLyaS/8HQILziDZ3eFSEyD/6DpN7bdfRkvXlGvEY650SZW7NGzKLAABax7WIw0CR
C7qBbu7JfMwr5FKyCWrZwt6pfqhu6U/UMS09z0xO5c11uyoHKHbUZMndev2aAYv1XkXi
4N6HIWPn4aCvlxl4AKiaKsu4ur27ZFTM6so0DIKTBzm8s+xiNvVFmFNyp4gbXtcgXPid
biZGSYGBK4VH/weI/aFZUHZdAyANSM/GpNbG/7g0MVvlkD6dgpGwoodZJgdpAjWtMIt/
oquA==
X-Gm-Message-State: APjAAAWkyMthx/klPN7vq02cC6FqDJVhLIyJsOUW2ViTkn6gMpN7LgoK
Bwup9hd7h3RDnahf2V7ecDJLtHA/t4I=
X-Google-Smtp-Source: APXvYqynx5pZc1pdHRTMM9qDylTFdcbETn+SPKjR7KDWtyDk7Tp/IDXfpbFi4h1AO4Eoj5oQyhirJQ==
X-Received: by 2002:a17:906:3108:: with SMTP id
8mr24176551ejx.11.1569940062713;
Tue, 01 Oct 2019 07:27:42 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa])
by smtp.gmail.com with ESMTPSA id
k14sm1860366ejp.89.2019.10.01.07.27.41
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Tue, 01 Oct 2019 07:27:42 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
References: <87wodp7w9f.fsf@gmail.com>
<-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
Date: Tue, 01 Oct 2019 16:20:25 +0200
Message-ID: <87tv8s7djq.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:45 -0000
ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
> I rather strongly oppose output tagging.
>
> The entire point of for example Taproot was to reduce the variability
> of how outputs look like, so that unspent Taproot outputs look exactly
> like other 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.
That is a bit reductive if you ask me. Taproot brings a number of
improvements such as the reduction of on-chain footprint in the
collaborative spend case, the hiding of complex logic in that case, and
yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be
to make everything look identical to the outside observer, but saying
that separating outputs into two coarse-grained domains is equivalent to
throwing the baby out with the bath-water :-)
That being said, I should clarify that I would prefer not having to make
special accomodations on top of the raw sighash_noinput proposal, for
some perceived, but abstract danger that someone might shoot themselves
in the foot. I think we're all old enough not to need too much
handholding :-)
Output tagging is my second choice, since it minimizes the need for
people to get creative to work around other proposals, and minimizes the
on-chain footprint, and finally chaperone signatures are my least
preferred option due to its heavy-handed nature and the increased cost.
> 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.
That is very much how I was planning to implement it anyway, using a
trigger transaction to separate timeout start and the actual
update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo
there shouldn't be an issue here :-)
> The point regarding use of a commonly-known privkey to work around
> chaperone 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.
Exactly, why introduce the extra burden of chaperone signatures or
output tagging if we're just going to sidestep it?
> 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 outputs getting spent to further bip-schnor/Taproot
> SegWit v1 addresses, to increase 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).
While I do agree that we should keep outputs as unidentifiable as
possible, I am starting to question whether that is possible for
off-chain payment networks since we are gossiping about the existence of
channels and binding them to outpoints to prove their existence anyway.
Not the strongest argument I know, but there's little point in talking
ideal cases when we need to weaken that later again.
>> 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 that
>> these proposals a useful, also beyond eltoo, not everybody could be
>> there. I'd therefore like to elicit some feedback from the wider community.
>
> I strongly agree that `NOINPUT` is useful, and I was not able to attend CoreDev (at least, not with any human fleshbot already known to you --- I checked).
Great, good to know that I'm not shouting into the void, and that I'm
not just that crazy guy trying to get his hairbrained scheme to work :-)
>> 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 private key to use for all chaperone signatures, since all the
> important security is in the `NOINPUT` signature anyway.
>
>>
>> 3. The same for output tagging / explicit opt-in. What are the advantages and
>> disadvantages?
>
> Strongly oppose, see above about my argument.
>
>>
>> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
>> 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.
Definitely agreed :+1:
|
