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 66A63E35 for ; Thu, 24 May 2018 01:58:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot0-f181.google.com (mail-ot0-f181.google.com [74.125.82.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B3DB180 for ; Thu, 24 May 2018 01:58:12 +0000 (UTC) Received: by mail-ot0-f181.google.com with SMTP id i5-v6so63121otf.1 for ; Wed, 23 May 2018 18:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oUSwTy9Sy7fJJruWc/1++lXmpV1IyF2v056T9YyxCc8=; b=RnN9PI9Nhhr0PaHhhgLkfv4m8BS2oJ8qPUE3/mnGNk7JYUXOOdwk1OSAnIM9gWSVA1 cQjgn6NKQZc5r++c0qK5aV+ZEO0Gi33WztrzGufxKq0ZGmgaWtOTV83m/uYgmojH3rgA hJEbN8qz5tMBDsgokTkRXWRH9xpe7aqjlsrtBC+qDigQpU1xsk1M9nKMCNB2FOGsjy7m CyAEgQHAmBX3VGfXJJpCdEE4tlFZcsp+r83V4OXME2hHQtVwqLnuVBFiCZWuuA2ts4Do ccWoFyZ4ElsrSw7trsAxZs5JX/ccFepPhqczCGDm2jzhQ3wK1jTzzdpQbJBNmbWwChH1 Sejw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oUSwTy9Sy7fJJruWc/1++lXmpV1IyF2v056T9YyxCc8=; b=iPWt0eOC/wruFvuCjp7TBcCnGueyZQHx4dz2X3w6vVuSk3/E1b1wH88K37oAswho+I ex249Gic3kwUgAOkRma5Km39vrrqQx7feMNGFM46cl3T+R2+DAmvrbSsKD+eassCSd3u xRXCuVF4Q8YeZBmwa5zt+QvZrdHPFskfmaJYSugS6ylChhaOt8em69AAmNGSUJLQZssJ 6GixBq4sfYVrW6ahOGx8OcjtTQjBQ8VOT1Vv4wGkndOdPhv1+/6SJ3DRGikwlPlQ00wL ZAp54UtTda9cgAvg78vxBWgbt7E0VoJhRsZy85+FjAU4s1597hZ+oVUQWJWg167tjDII fb3g== X-Gm-Message-State: ALKqPwfdS9NvFOJeuGitwVbIgfxPxOZxnYZM/GUT7G8GR3fLt/qzxmQ4 OAnKJDvGPuBYAM8l7ONGnAJ0BDajHLgvQ7JFVV+CfA== X-Google-Smtp-Source: AB8JxZqDqvN8bXQrJWAj7zugGP7XRTmX7EZamSxd3EwUMhZlkLfzJH2dIfev+CxiQFpRXaOXSBICEpm+gGc0xcRPFWk= X-Received: by 2002:a9d:4377:: with SMTP id y52-v6mr3533750oti.170.1527127091979; Wed, 23 May 2018 18:58:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:6ac8:0:0:0:0:0 with HTTP; Wed, 23 May 2018 18:58:11 -0700 (PDT) In-Reply-To: References: From: Pieter Wuille Date: Wed, 23 May 2018 18:58:11 -0700 Message-ID: To: Bitcoin Dev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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] Should Graftroot be optional? 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: Thu, 24 May 2018 01:58:13 -0000 On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille wrote: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot spending path. I have no strong > reasons why this would be necessary, but I'd like to hear other > people's thoughts. Thanks everyone who commented so far, but let me clarify the context of this question first a bit more to avoid getting into the weeds too much. If it turns out to be necessary to explicitly commit to permitting Graftroot spending, there are a number of approaches: * Use a different witness version (or other marker directly in the scriptPubKey) to enable Graftroot. * Signal the permission to spend through Graftroot inside the Taproot script as suggested by ZmnSCPxj. * Make "Spend through Graftroot" a special script (possibly indirectly with a Merkle tree in Taproot). * Implement Graftroot as an opcode/feature inside the scripting language (which may be more generically useful as a delegation mechanism). * Postpone Graftroot. All of these are worse in either efficiency or privacy than always permitting Graftroot spends directly. Because of that, I think we should first focus on reasons why a lack of commitment to enabling Graftroot may result in it being incompatible with certain use cases, or other reasons why it could interfere with applications adopting such outputs. @Natanael: all of these concerns only apply to a new hypothetical Taproot/Graftroot output type, which combines pay-to-pubkey and pay-to-script in a single scriptPubKey that just contains a public key. It doesn't apply to existing P2SH like constructions. Also, the concern of making Graftroot optional does not apply to Taproot, as the Taproot spending path's script is committed to (using scriptPubKey = P + H(P,script)*G), allowing the script to be explicitly chosen to be a non-spendable script, which the author could prove is the case (without revealing it to the entire world). It is also always possible to create a "script only" Taproot output (without key that can unconditionally spend), by picking a pubkey that is provably unspendable (hashing onto a curve point, in particular), or through pubkey recovery. Cheers, -- Pieter