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 278D91027 for ; Wed, 23 May 2018 22:06:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 571E46C1 for ; Wed, 23 May 2018 22:06:44 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id j4-v6so12923179wme.1 for ; Wed, 23 May 2018 15:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JU5pgHjY5ojMvEpGb4kP0BVKwdNz6dZJ+fFtp9KUh34=; b=ZMtUmtGjXhBUYripBw9+B3YN5XTukD0MHIkTx2pKOQYeAqYg1ByZr8XFK4eUY6sl4k UhWKHytZgC9iI3EiYdTG9zl2YFjan+rLKWViUGrvOrmJnIZ2b+1T0ZMF3CjxAYROdUUQ QuXN3daH2VQFsc2Dd4qA7jXMpqMopFfD53GVys7SCaRilXRM6orJt5I26jk1PdaIoKCC 1/vuSZ2irRiBUgHakuRAHlIdNR0t03gzwEs0CJDaL6Tn8+zhT5qm8/H8zxacOSeAWFaY spCIUD1pKyrrvZbUFkxD2WTCE0qCQcbxbzcikTGRo03sGWG45OxPYVoEA+VPST6xZACB 1nWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JU5pgHjY5ojMvEpGb4kP0BVKwdNz6dZJ+fFtp9KUh34=; b=kY+N44Te/oPoL+lPHrThmsH9kZCyD62ND35ZSfbXled91fYyMoX6Iigb4zuPKp+OGj quS8XKk08sfJ5o8kaP7mQhlqMw/7E2A6BYAsaFAhrB0xmEoW1i+RlhUFeKRY5sdUp3Df LDRenHMBnMynC3ZKi4nOnhxH9iJB5GxiZX22a43wdQzio4pvcRpyY6qshEjZRvW0Fvku 6lrnrYRVHuC6QE32WtNOqHEpr19CLQQkAQRwfXFCqHvU+zNiVcKKID3RQk2HZdnYDnR8 mVLn03x7bzRJ/vzCcVubc2uv8uLl+/vcxjBz+CX6UxWDOZOezEUpLODSkW96D2DBXFax lIJg== X-Gm-Message-State: ALKqPweWuJVbGc0WnKMckcRRYZFb18hAlvhbx6I0LU3exwSqzQvK8VUV S3UlvwtnQCJLHtxxMlHXNbJZsrWdH4PzJ9uuKUw= X-Google-Smtp-Source: AB8JxZpltzFKIyUpgc1xuCGr5Xh7zG6WoHZ+u7ex6zn1suxZpMXB2YUcWBcwNlycnvHMkhHKuNjQMqRnntFNlZa/wWY= X-Received: by 2002:a50:ed92:: with SMTP id h18-v6mr9223305edr.102.1527113202821; Wed, 23 May 2018 15:06:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Natanael Date: Thu, 24 May 2018 00:06:31 +0200 Message-ID: To: Pieter Wuille , Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000fc6efd056ce6bfe4" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Wed, 23 May 2018 22:06:45 -0000 --000000000000fc6efd056ce6bfe4 Content-Type: text/plain; charset="UTF-8" Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > 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. > I'm definitely in favor of the suggestion of requiring a flag to allow the usage of these in a transaction, so that you get to choose in advance if the script will be static or "editable". Consider for example a P2SH address for some fund, where you create a transaction in advance. Even if the parties involved in signing the transaction would agree (collude), the original intent of this particular P2SH address may be to hold the fund accountable by enforcing some given rules by script. To be able to circumvent the rules could break the purpose of the fund. The name of the scheme escapes me, but this could include a variety of proof-requiring committed transactions, like say a transaction that will pay out if you can provide a proof satisfying some conditions such as embedding the solution to a given problem. This fund would only be supposed to pay out of the published conditions are met (which may include an expiry date). To then use taproot / graftroot to withdraw the funds despite this possibility not showing in the published script could be problematic. I'm simultaneously in favor of being able to have scripts where the usage of taproot / graftroot isn't visible in advance, but it must simultaneously be possible to prove a transaction ISN'T using it. > --000000000000fc6efd056ce6bfe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> skrev:
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.

I'm defini= tely in favor of the suggestion of requiring a flag to allow the usage of t= hese in a transaction, so that you get to choose in advance if the script w= ill be static or "editable".=C2=A0

Consider for example a P2SH address for some f= und, where you create a transaction in advance. Even if the parties involve= d in signing the transaction would agree (collude), the original intent of = this particular P2SH address may be to hold the fund accountable by enforci= ng some given rules by script. To be able to circumvent the rules could bre= ak the purpose of the fund.=C2=A0

The name of the scheme escapes me, but this could include a variety of pr= oof-requiring committed transactions, like say a transaction that will pay = out if you can provide a proof satisfying some conditions such as embedding= the solution to a given problem. This fund would only be supposed to pay o= ut of the published conditions are met (which may include an expiry date).= =C2=A0

<= /div>
To then use taproot / graf= troot to withdraw the funds despite this possibility not showing in the pub= lished script could be problematic.=C2=A0

I'm simultaneously in favor of being able to have scripts wher= e the usage of taproot / graftroot isn't visible in advance, but it mus= t simultaneously be possible to prove a transaction ISN'T using it.=C2= =A0
--000000000000fc6efd056ce6bfe4--