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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4F46C1A80;
Tue, 1 Oct 2019 15:59:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8983CA3;
Tue, 1 Oct 2019 15:59:36 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1iFKYm-0007l9-U0; Wed, 02 Oct 2019 01:59:34 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 02 Oct 2019 01:59:29 +1000
Date: Wed, 2 Oct 2019 01:59:29 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20191001155929.e2yznsetqesx2jxo@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87wodp7w9f.fsf@gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B,
KHOP_HELO_FCRDNS,UNPARSEABLE_RELAY autolearn=no 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: Tue, 01 Oct 2019 15:59:39 -0000
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"
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).
Cheers,
aj
|
