From: Gregory Maxwell <greg@xiph•org>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Date: Fri, 26 Jan 2018 21:34:39 +0000 [thread overview]
Message-ID: <CAAS2fgSApdSYUWZx+_G7tMPPQm5bC4xjYzZ_mQZv=w-FD-4jWw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
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;]
next prev parent reply other threads:[~2018-01-26 21:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 0:30 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
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 [this message]
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='CAAS2fgSApdSYUWZx+_G7tMPPQm5bC4xjYzZ_mQZv=w-FD-4jWw@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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