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
|
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 5FFCAE92
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jan 2018 22:22:42 +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 724BFCA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jan 2018 22:22:41 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
id 1ee6xg-000689-7J; Wed, 24 Jan 2018 08:22:39 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 24 Jan 2018 08:22:29 +1000
Date: Wed, 24 Jan 2018 08:22:29 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20180123222229.GA3801@erisian.com.au>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
<20180123064419.GA1296@erisian.com.au>
<CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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,T_RP_MATCHES_RCVD,
UNPARSEABLE_RELAY 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>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
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, 23 Jan 2018 22:22:42 -0000
On Tue, Jan 23, 2018 at 01:15:38PM +0000, Gregory Maxwell wrote:
> On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns <aj@erisian.com.au> wrote:
> > Is this really intended as paying directly to a pubkey, instead of a
> > pubkey hash?
> > If so, isn't that a step backwards with regard to resistance to quantum
> > attacks against ECC?
> Considering the considerable level of address reuse -- I recall prior
> stats that a majority of circulating funds are on addresses that had
> previously been used, on top of the general race limitations-- I am
> now dubious to the idea that hashing provides any kind of meaningful
> quantum resistance and somewhat regret introducing that meme to the
> space in the first place. If we considered quantum resistance a
> meaningful concern we should address that specifically. --- so I
> don't think that should be a factor that drives a decision here.
Hmm, at least people can choose not to reuse addresses currently --
if everyone were using taproot and that didn't involve hashing the key,
there would be no way for individuals to hedge against quantum attacks
in case they're ever feasible, at least that I can see (well, without
moving their funds out of bitcoin anyway)?
Even "X + H(X|script)g" with X being a random point would end up
attackable, since that would almost always end up corresponding with a
valid public key that a successful attack could then find a private key
for.
(It seems like using the point at infinity wouldn't work because
P = 0+H(0||S)g = H(0||S)g, so as soon as you tried to spend it via S,
someone watching the mempool would know H(0||S), which is the secret key
for P, and be able to spend it via the pubkey path -- no quantum crypto
needed. Or am I missing something?)
Also, if the people currently reusing addresses tend to cycle the funds
through fairly quickly anyway, they might be able to simply stop doing
that when quantum attacks start approaching feasibility. If funds are
being held in reused addresses over the long term, that would be more
of a problem though...
> When collision resistance is needed (as I think it clearly is for
> taproot) you don't get a space savings in the txout from hashing, so
> there is an argument to use the public key directly at least... but
> it's worth considering. Direct SPK use is also adventitious for being
> able to efficiently ZKP over the UTXO set, e.g. for private solvency
> proofs, but it isn't absolutely mandatory for that (one can hash
> inside the proof, but it's slower).
Yeah, that was one of the assumptions for
http://www.jbonneau.com/doc/DBBCB15-CCS-provisions.pdf iirc.
(Also, pretty sure you mean "advantageous", but at least I learnt a new
word today)
Cheers,
aj
|
