MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 26 Jan 2018 21:34:39 +0000
Message-ID: <CAAS2fgSApdSYUWZx+_G7tMPPQm5bC4xjYzZ_mQZv=w-FD-4jWw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

On Tue, Jan 23, 2018 at 12:30 AM, Gregory Maxwell <greg@xiph.org> wrote:
> It turns out, however, that there is no need to make a trade-off.  The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.

Keeping in mind that a single public point can stand in for any
monotone function of public keys, a taproot branch is only needed for
accountability (being able to tell from public data which branches
were used) or when conditions other than public keys are required e.g.
CSV + a monotone function of keys.

I believe that with scriptless-scripts most of hash preimages can be
accomplished without an actual hash pre-image condition.

Are there other simple and very useful/general preconditions that
would be useful ANDed with a monotone function of public keys like is
the case for CSV?

I ask because recursive taproot by itself isn't very interesting,
since (other than accountability) there is no gain to not just merging
the alternative, but if there are additional conditions then it can be
useful. E.g.

[pubkey]
      \-[pubkey]&&CSV
             \-[fancy script]

So it might make sense to support a taproot construction that can
nest, where interior nested keys have a CSV/CLTV predicate. But are
there other simple predicates that cover a lot of cases?


[Aside: _please_ change the subject lines for further discussion about
quantum computers;]