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
|
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 D376BEE5;
Thu, 3 Oct 2019 11:09:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com
[209.85.208.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5B701FB;
Thu, 3 Oct 2019 11:09:05 +0000 (UTC)
Received: by mail-ed1-f53.google.com with SMTP id l21so2062114edr.5;
Thu, 03 Oct 2019 04:09:05 -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=avxgsSfZ8iSLPWbFsvMJegpREJQ+Wtxqw/w+MA6rlMY=;
b=PT2SOCVJTI4tXkxCMqfeNitMh2LAwhdYW9jm5dsSY5SOEhJjKHq0Nf2Ox+UQtwz5ns
vuPXazQGr8UF9rEcq1Mm6t6kiMEXE1hh/Y7TxbOrdKo8lWhIYs4pD3y3Bltk2cRQw3zT
w/W1l5wF6hN1EnDvoW8H0PfMPd6Lj9VuWqxBUzz3ELmt48dHyYH0W4fi3jVBQm1lHTFZ
jFVGRMy2qbUYKs2Kb4jzmRVC64/KC60/66OZoLuDx0hQaxbMZPixVN8e9Wf2DxcYOjXc
U6AFaaIU4UdLdS4IOhh5U988t7qeolRZ80yuOGPt7pp0teeJoCYyCHLT0nMLKfPBbKHL
xP/w==
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=avxgsSfZ8iSLPWbFsvMJegpREJQ+Wtxqw/w+MA6rlMY=;
b=H84cW1YxASRrS5A3EuHtfoLeUBUTELm2xuMnqwGaCwnq/40dyxDbnlgbDKFX8NvTpR
Pc8m9EufPjYC2IUW8MT6td7GLJHP88OMxXdqgCQ8325+ZRATgd1K3hOK6w6Ku+sNs3KH
JU+SDjMl4obH9E3I31/1iGXdJYM53UKpx2vhfaZ/HeszvIdWsNFo9l4ED5nuO+QgvFlC
urVvMAfXJaJaY1duSGjndYYlvYiA+eNnkC4wyaTGYGUhzpJCXBhZpXArnHDeyPV51RMo
9UH22LBSp7DrNgJwsDMblyCs0JV+kFEUxgrlU6QsCfoT+w1IaWwgIEMgVl4HcqCdCEmY
5z6A==
X-Gm-Message-State: APjAAAVq3SOGujhCKaNXw1SgQXduaWsPGjfxfHVz2QRlvQKp6kPx8Zwq
yn54CvYTtwNhaElUA4xN9w9lkhDGUBc=
X-Google-Smtp-Source: APXvYqyvckhl/f2t9Ya+C+09+AiP2WQmfPY9zoZYOS7eGvuWwpwWm2iXKMPj5Voljr7lVVN5U/HT7g==
X-Received: by 2002:a05:6402:346:: with SMTP id
r6mr8677126edw.124.1570100944155;
Thu, 03 Oct 2019 04:09:04 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532])
by smtp.gmail.com with ESMTPSA id i5sm406424edq.30.2019.10.03.04.09.03
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 03 Oct 2019 04:09:03 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20191001155929.e2yznsetqesx2jxo@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
Date: Thu, 03 Oct 2019 13:08:29 +0200
Message-ID: <877e5m6q8i.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
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: Thu, 03 Oct 2019 11:09:07 -0000
Anthony Towns <aj@erisian.com.au> writes:
> On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev wrote:
>> With the recently renewed interest in eltoo, a proof-of-concept implementation
>> [1], and the discussions regarding clean abstractions for off-chain protocols
>> [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
>> (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
>
> Hey Christian, thanks for the write up!
>
>> ## Open questions
>> The questions that remain to be addressed are the following:
>> 1. General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout[?]
>> 2. Is there strong support or opposition to the chaperone signatures[?]
>> 3. The same for output tagging / explicit opt-in[?]
>> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
>> confusion and make for simpler discussions in the end.
>
> I think there's an important open question you missed from this list:
> (1.5) do we really understand what the dangers of noinput/anyprevout-style
> constructions actually are?
>
> My impression on the first 3.5 q's is: (1) yes, (1.5) not really,
> (2) weak opposition for requiring chaperone sigs, (3) mixed (weak)
> support/opposition for output tagging.
>
> My thinking at the moment (subject to change!) is:
>
> * anyprevout signatures make the address you're signing for less safe,
> which may cause you to lose funds when additional coins are sent to
> the same address; this can be avoided if handled with care (or if you
> don't care about losing funds in the event of address reuse)
>
> * being able to guarantee that an address can never be signed for with
> an anyprevout signature is therefore valuable; so having it be opt-in
> at the tapscript level, rather than a sighash flag available for
> key-path spends is valuable (I call this "opt-in", but it's hidden
> until use via taproot rather than "explicit" as output tagging
> would be)
>
> * receiving funds spent via an anyprevout signature does not involve any
> qualitatively new double-spending/malleability risks.
>
> (eltoo is unavoidably malleable if there are multiple update
> transactions (and chaperone signatures aren't used or are used with
> well known keys), but while it is better to avoid this where possible,
> it's something that's already easily dealt with simply by waiting
> for confirmations, and whether a transaction is malleable is always
> under the control of the sender not the receiver)
>
> * as such, output tagging is also unnecessary, and there is also no
> need for users to mark anyprevout spends as "tainted" in order to
> wait for more confirmations than normal before considering those funds
> "safe"
Excellent points, I had missed the hidden nature of the opt-in via
pubkey prefix while reading your proposal. I'm starting to like that
option more and more. In that case we'd only ever be revealing that we
opted into anyprevout when we're revealing the entire script anyway, at
which point all fungibility concerns go out the window anyway.
Would this scheme be extendable to opt into all sighash flags the
outpoint would like to allow (e.g., adding opt-in for sighash_none and
sighash_anyonecanpay as well)? That way the pubkey prefix could act as a
mask for the sighash flags and fail verification if they don't match.
> I think it might be good to have a public testnet (based on Richard Myers
> et al's signet2 work?) where we have some fake exchanges/merchants/etc
> and scheduled reorgs, and demo every weird noinput/anyprevout case anyone
> can think of, and just work out if we need any extra code/tagging/whatever
> to keep those fake exchanges/merchants from losing money (and write up
> the weird cases we've found in a wiki or a paper so people can easily
> tell if we missed something obvious).
That'd be great, however even that will not ensure that every possible
corner case is handled and from experience it seems that people are
unwilling to invest a lot of time testing on a network unless their
money is on the line. That's not to say that we shouldn't try, we
absolutely should, I'm just not sure it alone is enough to dispell all
remaining doubts :-)
Cheers,
Christian
|
