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
|
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 D9A1113EB;
Thu, 3 Oct 2019 10:33:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05A35189;
Thu, 3 Oct 2019 10:33:55 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id f20so1958103edv.8;
Thu, 03 Oct 2019 03:33:54 -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=eKLy9dB5IJIL8/yk18ysxIqjtAYFDscVmyxESEwdQoA=;
b=WXEqRgvCMok3thHZFAwkKuY/3jZYU6rc5vqnD+8VnjU0yL1svQKkbAQO7bIKB/P8VP
Se3Qx1gy7M816dLSWD7Uzrt1RzD1N771JWI/8rLYquaCBYjw0m27k01u7hzw2wAxqYyT
/+MbhLhER6Ft+Un3o1pdb+/RXH0RMVTV7ye3DZYTBmkp3rLW7vuHNfGZGi+3gAKFOLR/
FmKGqGe3nwSHOxW0EYeVI71R3dlDzwsq5NyntZOQNIMx2PU/ink1j1bA2Q2ib3frKFwK
V3uiVzaHAAp/GhwU4Sab9QKyvOEbrwbnXJ498iQ3H1Z34DUnMmxoVSTjo92P/0aGKurC
E09g==
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=eKLy9dB5IJIL8/yk18ysxIqjtAYFDscVmyxESEwdQoA=;
b=mRDZDVAOZj4CmXBaR3ZtfFj82yyf3qaZw4xydB/DByO42gYjafuqMpAlFRH2vXbC5i
PfR/9H6127akP8+RqV/o0HYadngB9FtJrXS3VeUcpSi1R42+wJef8QQ6B2croLmIeQcK
njY/O1NTqx2BuRoKLKCLrhVsUhOkXV6rR/lm3YBmrD9nxl7l8lnrx0DW48Ezf6se5HIs
A5Wc6V2UQ1YNecagcxe9BCCN5GzlMRlfUCCwcTcEjpNq8ns3JdIVS3sBaL3sFSieNx8P
+MIDpN+YCYEpo83pTDjleh5Dl/kiBeUdZmDlSq1dr63ImqHJ3mfymkkqPnvulBhg3pez
BJVQ==
X-Gm-Message-State: APjAAAUXnqQvTyoGw/dW+ViRA7WUQffEXEsDex6FdYwvV+E/UOOXjIzb
5krioH03NbieCCnB78sxums=
X-Google-Smtp-Source: APXvYqzQZUNSRLWTLXNtzHr7BSKkKbPRPOE6qP7tGAHrCQcceDmmHrfw3IioEfz4yKTvKV5p8hCX6Q==
X-Received: by 2002:aa7:d508:: with SMTP id y8mr8543426edq.171.1570098833525;
Thu, 03 Oct 2019 03:33:53 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532])
by smtp.gmail.com with ESMTPSA id i30sm391890ede.32.2019.10.03.03.33.52
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 03 Oct 2019 03:33:52 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Chris Stewart <chris@suredbits.com>, Richard Myers <rich@gotenna.com>
In-Reply-To: <CAFQwNuxRcwOh9AUWXMonDM=7AgiHMym-TtuaHS_-6RFKcnNgZQ@mail.gmail.com>
References: <87wodp7w9f.fsf@gmail.com>
<CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
<CAFQwNuxRcwOh9AUWXMonDM=7AgiHMym-TtuaHS_-6RFKcnNgZQ@mail.gmail.com>
Date: Thu, 03 Oct 2019 12:30:03 +0200
Message-ID: <87eezu6s0k.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: 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: Thu, 03 Oct 2019 10:33:56 -0000
Chris Stewart <chris@suredbits.com> writes:
>> I don't find too compelling the potential problem of a 'bad wallet
> designer', 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.
>
> In my original post, the business that I am talking about don't use "off
> the shelf" wallet options. It isn't a "let's switch from wallet A to wallet
> B" kind of situation. Usually this involves design from ground up with
> security considerations that businesses of scale need to consider (signing
> procedures and key handling being the most important!).
In this case I'd hope that the custom wallet designers/developers are
well-versed in the issues they might encounter when implementing their
wallet. This is especially true if they decide to opt into using some
lesser known sighash flags, such as noinput, that come with huge warning
signs (I forgot to mention that renaming noinput to noinput_dangerous is
also still on the table).
>>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
> signing 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 script they don't control, whether or not a no_input
> signature exists for it.
>
> Just because some one is your friend today, doesn't mean they aren't
> necessarily your adversary tomorrow. I don't think a signature being
> onchain really matters, as you have to give it to your counterparty
> regardless. How do you know your counterparty won't replay that
> SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on
> "good-will" for their counter parties for security.
>
>>As I mentioned before, I don't think the lazy wallet designer advantage is
> enough to justify the downsides of chaperone signatures. One additional
> downside 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 much less intrusive and easier to maintain.
>
>>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
>
> I actually think lazy wallet designer is a really compelling reason to fix
> footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy
> wallet design. Now we have non-malleable transactions in the form of segwit
> (yay!) that prevent this exploit. We can wish that the Mt Gox wallet
> designers were more aware of bitcoin protocol vulnerabilities, but at the
> end of the day the best thing to do was offering an alternative that
> circumvents the vulnerability all together.
It's worth pointing out that the transaction malleability issue and the
introduction of a new sighash flag are fundamentally different: a wallet
developer has to take active measures to guard against transaction
malleability since it was present even for the most minimal
implementation, whereas with sighash flags the developers have to
actively add support for it. Where transaction malleability you just had
to know that it might be an issue, with noinput you actively have to do
work yo expose yourself to it.
I'd argue that you have to have a very compelling reason to opt into
supporting noinput, and that's usually because you want to support a
more complex protocol such as an off-chain contract anyway, at which
point I'd hope you know about the tradeoffs of various sighash flags :-)
> Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have
> virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly
> every transaction. The feature -- ECDSA in this case -- was managed to be
> done wrong by wallet developers causing fund loss. Unfortunately we can't
> protect against this type of bug in the protocol.
>
> If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it
> doesn't matter if they are secure or insecure. I'm hopefully that offchain
> protocols will achieve wide adoption, and I would hate to see money lost
> because of this. Even though they aren't used, in my OP I do advocate for
> fixing these.
I do share the feeling that we better make a commonly used sighash flag
as useable and safe as possible, but it's rather unrealistic to have a
developer that is able to implement a complex off-chain system, but
fails to understand the importance of using the correct sighash flags in
their wallet. That being said, I think this concern would be addressed
by any form of explicit opt-in on the output side (whether hidden or
not), right?
Cheers,
Christian
|
