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 4F7E0F67 for ; Wed, 20 Jun 2018 14:30:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f65.google.com (mail-vk0-f65.google.com [209.85.213.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19BE81A0 for ; Wed, 20 Jun 2018 14:30:57 +0000 (UTC) Received: by mail-vk0-f65.google.com with SMTP id d74-v6so2052175vke.10 for ; Wed, 20 Jun 2018 07:30:56 -0700 (PDT) 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=daCXIBGk2nNOuwqcyHXnjmowMnWqQe0GhhQwsqAk6o8=; b=HmMGAXxZXP2K9bIa7QxmGcpD5BYRv6m1POG+7Jk9w3cqaUJykIybhVX95riDyKVu7r v1D6JV+zaRn2zj92BIAYut2g3VENBK/dhPGHyt26ky5fG2B6oNtov4YkaFCt4GJy9qe7 28ImfFX2QK4+TmtXWF/Uzc6gbX3YG4kD0r7GW2nMdOJAf/MBnmhTExAp305lc1GrXBiW Afrmqy6jQM2wXERfOhIFI0U55I7qJtqAi+/I4zVc0AubEJI0hjd1K6BunO7cz3KXZ1op U0fSdH76/jxa83sp1WgBF667jHVmQaFesRrBKTVJUfhg7hdL4AIYP9jOxwMB8oBzlbVa xIEA== 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=daCXIBGk2nNOuwqcyHXnjmowMnWqQe0GhhQwsqAk6o8=; b=Nl8uT0IlUrOukiHLgYG4SJ3tvdPgAiAPPAZDXNnd3oDbdU2MKjt+2+h6bLc/CHeB5t Ah8MNF/+hlUr5lGL6/l2l6czWX21FYzOmIyHlamjZNPhzruCHN61uu+JcBKZIpBjG1a0 /juVUEZREDpuLjwEE8VAS/eoQ2hMMYAtWq1uVYyLYBagkUlYa5VrfHj/OXpcCye+Sqq9 cdH25zp5szSq3/r7Gcpd6Xo5LXWUsDFS7m66SUHY3QRPcX+oCeMqPX1Nc3XUHPML42v2 zb6PLGO904/RYqIiC6Smv4EOwdb7OG3BIJhA40zW32lVtP1+cpGF86ba6MEZX/Cs6m5b slWQ== X-Gm-Message-State: APt69E1K13YW8gHFS2YTNmvQAogXGY8DR7LTjnnS6AXXi6NYwFcCH7w2 7uZpVrglmXqeqzgQ8WwBu18NMCJEdeQwchiQDIE= X-Google-Smtp-Source: ADUXVKJKWCMM++8efi85pcrVYs9fl2sb4HJF8PhXN5tyk2ZvE0luwMWIquFV8g/FwP2gL/WnnI8qY5PgTtnQDFHZP+4= X-Received: by 2002:a1f:96d5:: with SMTP id y204-v6mr5954633vkd.55.1529505056136; Wed, 20 Jun 2018 07:30:56 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:5193:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 07:30:55 -0700 (PDT) In-Reply-To: <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com> References: <01976660b06809ea27af7db4bbceb08220ea2568.camel@timruffing.de> <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com> From: Gregory Maxwell Date: Wed, 20 Jun 2018 14:30:55 +0000 X-Google-Sender-Auth: _bnMJUTRBLtXXSg2sjeFrg1egHs Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion 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] 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, 20 Jun 2018 14:30:58 -0000 On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev wrote: > This has the advantage that the Graftroot signature commits to a single outpoint and cannot be used to spend all outpoints that happen to pay to the same `P` public key. If it isn't possible to make a graftroot signature independent of the outpoint then the functionality is _greatly_ reduced to the point of largely mooting it-- because you could no longer prepare the grafts before the coins to be spent existed, and meaning you must stay online and sign new grafts as coins show up. In my view graft's two main gains are being able to delegate before coins exist and making the conditional transfer atomic (e.g. compared to just pre-signing a transaction). Making outpoint binding optional, so that you could choose to either sign for particular outputs or in a blanket way would be a lot more useful. Though I had assumed outpoint binding could best be achieved by checking the outpoint in the graft-script-- this is general for whatever kinds of arbitrary graft conditions you might want to specify (e.g. locktimes, value checks, or conditions on subsequent outputs)... but perhaps binding a particular outpoint is enough of a special case that it's worth avoiding the overhead of expressing a match condition in the script, since that would probably end up blowing 36 bytes for the match condition in the witness when instead it could just be covered by the signature, and people should probably prefer to do output binding grafts whenever its reasonably possible.