From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6E21F5D for ; Fri, 26 Jan 2018 21:34:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F9B2E2 for ; Fri, 26 Jan 2018 21:34:41 +0000 (UTC) Received: by mail-ua0-f180.google.com with SMTP id x4so1178225uaj.11 for ; Fri, 26 Jan 2018 13:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=WyuH8AM3WN0NRDrlf9DrWiCtauu5g9BAOklzNy0xpCA=; b=G/cbYm8BbObRECgdg8z9HRa0pz8vCRqdV6ma2IzOlSZXPaKoWAOASAhtBUyxS/RLgZ RJ8Hz0ZiiAQFShL68qrfLYcu4Zau4dlsBHtyy2YOxHurG6Qd4HzyRfUjBqmTkDcezOd5 vcL77utd1UJ8pbIYr/qJ7Ic4g18zLWR+Sbh2jU6oWMopCzO5sHaX9PQ4cDCPcuTdQXI4 4hC5RtpuTa4Okn6Vl78Lsvp6qmW3hU5aKErfK95s9LK7w7WNSfb29e9WpU6GTig7FBN3 VSNFAeKXMAgYZxc7vFVOOFDasdUfkocTTBExUgvdUNZns/oKlQSqo15nrJbLU0T5E1ZW URQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=WyuH8AM3WN0NRDrlf9DrWiCtauu5g9BAOklzNy0xpCA=; b=tDUu9y6OSdT6PxrMEXYQtqGjonEh5+yb6XygLSgZj0dJAC4F5hl9b+3X+bRNPjrqHH kUbbukKMvusTRfh2hAVfU83rr4nECwHuhWEId9c+uNlYmZe8xqV4GZ0HpEBUJT3BziCx SV3TAlhPTB7glWynm4ry21SpYIpMI1qk6uqxjT8BkRWMNGCYcKhXVPSGV7LPR6anWbeQ BpaBbcgcqcLQicz1emm0tw114jUZMycNySyWzZ8VauOxe0k6tRXJ317gh/8nbhtt+pQ+ 3p4VZsISuOrvSYr8LOsY8cDRkGQdfE749Qo45BoTcCFuMK8IHZpMUOg0omZXoA+mcbiJ 7naQ== X-Gm-Message-State: AKwxytcezp1bTpzkgwwu8S2zFPCQMVGMZtY4dtu26WBkhn+I0H98C+HF m15BXWl1j5UIOYpsDhN0+/EOtwH9Jh1/M+QJMrs= X-Google-Smtp-Source: AH8x224NLSHnNYPpZVXtPPrjFAaaRpUt9S/uniKz3R1Mxl/WSetAe2+F7MO2NAcpvcI8aOJqk1NgVm/6ADbhxKdhnN4= X-Received: by 10.176.83.76 with SMTP id y12mr12627781uay.109.1517002480128; Fri, 26 Jan 2018 13:34:40 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.78.155 with HTTP; Fri, 26 Jan 2018 13:34:39 -0800 (PST) In-Reply-To: References: From: Gregory Maxwell Date: Fri, 26 Jan 2018 21:34:39 +0000 X-Google-Sender-Auth: Ka_Vk-Nwls3rAfHOReOcBmSNAkQ Message-ID: To: Bitcoin Dev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 21:34:41 -0000 On Tue, Jan 23, 2018 at 12:30 AM, Gregory Maxwell 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;]