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
|
Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95FE3157B;
Tue, 1 Oct 2019 14:27:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com
[209.85.210.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0FF56189;
Tue, 1 Oct 2019 14:27:57 +0000 (UTC)
Received: by mail-pf1-f196.google.com with SMTP id q10so8149789pfl.0;
Tue, 01 Oct 2019 07:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=ly0SIGZuTJwLSQFEmaopXmbEw0r0Q6KVyRq9bZNDZNQ=;
b=vBuhRSa5rrPPUor/DSkZKXFVRn0Dk3E07c7eBIhh9kDv2q9NPiB58OPPO8HajAVVoQ
feoAS2F/E93KdPxLJEf5roXdDHg58qOhRwbfovxX6aTAEe63KWgi0wSWJz5KtqgFBTVk
y9nNOgE4D7Kx2lvjRUhZmjZxsFnKzBkN7XDTmTdkLXJ9Lsc32nqL1w1OBpVy3+5buGE4
tvSDHnqXigIUzuNkrMVUxM3vFjeKJ0UGeB8DKa8vhb9yFflr8eN5nb8JUbvTfHn1Bnwa
00PM2ui2GP6LnY8bckIjDjglzKXpcx8DaBwSbgcmfP1LqOX4DCJbas7GfvqSXfWdOMp5
o42A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=ly0SIGZuTJwLSQFEmaopXmbEw0r0Q6KVyRq9bZNDZNQ=;
b=B3oW609EeGJECVWCRv5BTfWpRqrdvGNg1TgTN/S0QlZoxv9mD/v6ZVdunB0wwp7ZaK
tFaqPr6hnbWpiocSN9G+9dLrQqY7/5z8BFbBHwFS2CMUmwCjE/3awDNFkJBhYvyl7yWF
5VzkFbV4N6IsCFRHXxxDJnpEZLxnNQ6By0El9ibbBgnLUsxjkTfxrTtJfM2kgdvCY2d+
V7+eG4m2w0CoElONCKsUu1UhWlAQoecuT7DObkwCKfbeSMgDJp4s+QNhSYLzQRbUAhH+
iu16nyxzmxZFwrnCpx1M7RpQQl/p05kpFHMtnncs6ahzfJftf24OEtcnuPzrSVestts5
GhGw==
X-Gm-Message-State: APjAAAV88rBu2Jcyyud3e5SvcCn4KN0GxOYqmszOgG+CFZor/TT8N3Fw
n7Harf5moY8Rc6yOD8LospFknNQSJEWh3ZOkNms=
X-Google-Smtp-Source: APXvYqy6dQuc5TFJ3Op5DuWXZFXNkCN5jrLyCOmn89wBubaPZEYIO2Fvi5sF9ub75xyeBe0LCwkUFSQHz4Uj89aLZyo=
X-Received: by 2002:aa7:9dc8:: with SMTP id g8mr19430683pfq.156.1569940077366;
Tue, 01 Oct 2019 07:27:57 -0700 (PDT)
MIME-Version: 1.0
References: <87wodp7w9f.fsf@gmail.com>
<CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
In-Reply-To: <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Tue, 1 Oct 2019 10:27:21 -0400
Message-ID: <CAEM=y+Vm=UW4-UGV4zVJQY8mdT=9Ljr9kVcfQovtzjRcx33L=w@mail.gmail.com>
To: Richard Myers <rich@gotenna.com>
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, DOS_RCVD_IP_TWICE_B, 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: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-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:58 -0000
>I don't find too compelling the potential problem of a 'bad wallet designe=
r', whether lazy or dogmatic, misusing noinput. I think there are simpler w=
ays to cut corners and there will always be plenty of good wallet options p=
eople can choose.
I want to second this. The most expensive part of wallet design is
engineering time. Writing code that uses a new sighash or a custom
script with a OP_CODE is a very large barrier to use. How many wallets
support multisig or RBF? How much BTC has been stolen over the entire
history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE
vs ECDSA nonce reuse?
On Tue, Oct 1, 2019 at 9:35 AM Richard Myers <rich@gotenna.com> wrote:
>
> Thanks Christian for pulling together this concise summary.
>
>> 1. General agreement on the usefulness of noinput / anyprevoutanyscript=
/
>> anyprevout.
>
>
> I certainly support the unification and adoption of the sighash_noinput a=
nd anyprevoutput* proposals to enable eltoo, but also to make possible bett=
er off-chain protocol designs generally.
>
> Among the various advantages previously discussed, the particular use cas=
e benefits from eltoo I want to take advantage of is less interactive payme=
nt channel negotiation.
>
> In talking with people about eltoo this summer, I found most people gener=
ally support adding this as an option to Lightning. The only general concer=
n I heard, if any, was the vague idea that rebindable transactions could b=
e somehow misused or abused.
>
> I believe when these concerns are made more concrete they can be classifi=
ed and addressed.
>
> I don't find too compelling the potential problem of a 'bad wallet design=
er', whether lazy or dogmatic, misusing noinput. I think there are simpler =
ways to cut corners and there will always be plenty of good wallet options =
people can choose.
>
> Because scripts signed with no_input signatures are only really exchanged=
and used for off-chain negotiations, very few should ever appear on chain.=
Those that do should represent non-cooperative situations that involve sig=
ning parties who know not to reuse or share scripts with these public keys =
again. No third party has any reason to spend value to a multisignature scr=
ipt they don't control, whether or not a no_input signature exists for it.
>
>> 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.
>
>
> As I mentioned before, I don't think the lazy wallet designer advantage i=
s enough to justify the downsides of chaperone signatures. One additional d=
ownside is the additional code complexity required to flag whether or not a=
chaperone output is included. By comparison, the code changes for creating=
a no_input digest that skips the prevout and prevscript parts of a tx is m=
uch less intrusive and easier to maintain.
>
>> 3. The same for output tagging / explicit opt-in. What are the advantag=
es and
>> disadvantages?
>
>
> I see the point ZmnSCPxj makes about tagged outputs negatively impacting =
the anonymity set of taproot transactions. The suggested work around would =
impose a cost to unilateral closes of an additional translation transaction=
and not using the work around would cause a hit to anonymity for off-chain=
script users. I feel both costs are too high relative to the benefit gaine=
d of preventing sloppy reuse of public keys.
>
>> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce =
the
>> confusion and make for simpler discussions in the end.
>
>
> I believe they should be merged. I also think both chaperone signatures a=
nd output tagging should become part of the discussion of security alternat=
ives, but not part of the initial specification.
>
> I understand the desire to be conservative with protocol changes that cou=
ld be misused. However, with just taproot and taproot public key types the =
anyprevout functionality is already very opt-in and not something that migh=
t accidentally get used. Belt-and-suspender protections like chaperone sign=
atures and tagged outputs have their own impacts on code complexity, on-cha=
in transaction sizes and transaction anonymity that also must be considered=
.
>
> I believe efforts like descriptors will help people follow best practices=
when working with complex scripts without pushing extra complexity for saf=
ety into the consensus layer of bitcoin. Anywhere we can make core code sim=
pler, and handle foot-guns in higher level non-consensus code, the better.
>
> _______________________________________________
>>
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
|
