MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com>
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
	<CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com>
	<CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
	<D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk>
	<CAPg+sBgEUV5KNFi1L4MhR-3KAX9gbQKdzWneaEzF+QsKSXYu8A@mail.gmail.com>
	<f5c0012e55242d85ec2cc740cc8d081ef5da9145.camel@timruffing.de>
	<CAPg+sBhYkQdjDcKvxUiGZCs220N0dqRMYoweCbOB2dgzD9UpzA@mail.gmail.com>
	<01976660b06809ea27af7db4bbceb08220ea2568.camel@timruffing.de>
	<7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 20 Jun 2018 14:30:55 +0000
Message-ID: <CAAS2fgQihGNvOsRVyr6xN_K0PPse1URKKWH06N7HpcR=OowYYw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
Precedence: list

On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.