summaryrefslogtreecommitdiff
path: root/fe/24d52b16f907a9eabb6ee12f129c71a27b0992
blob: 28821ae488ff07d7275c3d7415660da3b43dea70 (plain)
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
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 507CDC4E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 May 2019 20:38:20 +0000 (UTC)
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 B027E709
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 May 2019 20:38:19 +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 1hPCHX-0001bJ-Ff for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 May 2019 06:38:17 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
	Sat, 11 May 2019 06:38:04 +1000
Date: Sat, 11 May 2019 06:38:04 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20190510203804.554q333lw3l7qql4@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 11 May 2019 08:03:33 +0000
Subject: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
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: Fri, 10 May 2019 20:38:20 -0000

Hi everybody!

Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and
SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT,
despite the name change)

I don't think we are (or should be) as confident that ANYPREVOUT is
ready for implementation and deployment as we are that taproot is.
In particular, we were still coming up with surprising ways that these
style of signatures could maybe cause problems over the past few months,
despite "NOINPUT" having been around for years, and having been thinking
seriously about it for most of the last year. In comparison we've had
a roughed out security proof for taproot [0] for over a year now.

So far, the best approach (in my opinion) that we've come up with to
limit the possible negative impacts of these types of signatures is to
require an additional regular signature to accompany every ANYPREVOUT
signature. As such, it's included in the BIP draft.

In theory this ensures that no ANYPREVOUT tx can cause any more problems
than some existing tx could; but in practice this assumes that the private
key for that signature is maintained in a similar way to the private keys
currently securing transactions are. After passing this around privately,
I'm not convinced the theory will survive meeting adversarial reality,
in which case I don't think this draft will be suitable for adoption.

But maybe I'm too pessimistic, or maybe we can come up with either
a proof that ANYPREVOUT is already safe without any other measures,
or maybe we can come up with some better measures to ensure it's safe.
So in any case I'm still hopeful that publishing the best we've got is
helpful, even if that still isn't good enough.

The BIP draft can be found here:
 https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki

A sample implementation based on the taproot branch is here:
 https://github.com/ajtowns/bitcoin/commits/anyprevout

Some interesting features:

 * This demonstrates how to upgrade tapscript's existing CHECKSIG,
   CHECKSIGADD and CHECKSIGVERIFY opcodes for new SIGHASH methods or
   potentially a new signature scheme, a new elliptic curve or other
   public key scheme
 * This demonstrates a cheap way of using the taproot internal key
   as the public key for CHECKSIG operations in script
 * There are two variants, ANYPREVOUT and ANYPREVOUTANYSCRIPT, which
   seems helpful for eltoo
 * The BIP attempts to describe the security implications of ANYPREVOUT-style
   signatures

Cheers,
aj

[0] https://github.com/apoelstra/taproot/blob/master/main.tex