public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: Gregory Maxwell <greg@xiph.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Date: Wed, 24 Jan 2018 08:22:29 +1000	[thread overview]
Message-ID: <20180123222229.GA3801@erisian.com.au> (raw)
In-Reply-To: <CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>

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



  reply	other threads:[~2018-01-23 22:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23  0:30 [bitcoin-dev] Taproot: Privacy preserving switchable scripting Gregory Maxwell
2018-01-23  1:55 ` Chris Belcher
2018-01-23  2:51 ` Matt Corallo
2018-01-23 14:39   ` Mark Friedenbach
2018-01-23 21:23     ` Matt Corallo
2018-01-23 21:38       ` Gregory Maxwell
2018-01-23  6:44 ` Anthony Towns
2018-01-23 13:15   ` Gregory Maxwell
2018-01-23 22:22     ` Anthony Towns [this message]
2018-01-23 22:45       ` Gregory Maxwell
2018-01-24  1:52         ` Andrew Poelstra
2018-01-24  9:28           ` Tim Ruffing
2018-01-24 12:51         ` Natanael
2018-01-24 15:38           ` Tim Ruffing
2018-01-24 18:51             ` Natanael
2018-01-24 23:22               ` Tim Ruffing
2018-01-25  0:09                 ` Natanael
2018-01-26 13:14                   ` [bitcoin-dev] Recovery of old UTXOs in a post-quantum world Tim Ruffing
2018-01-27 17:07   ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting Russell O'Connor
2018-01-27 17:23     ` Matt Corallo
2018-01-23 15:43 ` Greg Sanders
2018-01-26 21:34 ` Gregory Maxwell
2018-07-13  1:51   ` [bitcoin-dev] Generalised taproot Anthony Towns
2018-10-24  2:22     ` Pieter Wuille
2018-02-05  9:27 ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180123222229.GA3801@erisian.com.au \
    --to=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox