From: Gregory Maxwell <greg@xiph•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
Date: Wed, 20 Jun 2018 14:30:55 +0000 [thread overview]
Message-ID: <CAAS2fgQihGNvOsRVyr6xN_K0PPse1URKKWH06N7HpcR=OowYYw@mail.gmail.com> (raw)
In-Reply-To: <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com>
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.
next prev parent reply other threads:[~2018-06-20 14:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 18:17 Pieter Wuille
2018-05-23 6:15 ` ZmnSCPxj
2018-05-23 13:50 ` Andrew Poelstra
2018-05-23 17:52 ` Andrew Poelstra
2018-05-25 9:46 ` Johnson Lau
2018-05-23 22:06 ` Natanael
2018-05-23 23:45 ` Gregory Maxwell
2018-05-24 9:32 ` Natanael
2018-05-24 1:58 ` Pieter Wuille
2018-05-24 2:08 ` Gregory Maxwell
2018-05-24 9:44 ` Natanael
2018-05-24 12:39 ` Andrew Poelstra
2018-05-25 10:14 ` Johnson Lau
2018-06-01 0:25 ` Pieter Wuille
2018-06-06 12:48 ` Tim Ruffing
2018-06-06 17:04 ` Pieter Wuille
2018-06-06 21:25 ` Tim Ruffing
2018-06-20 12:12 ` ZmnSCPxj
2018-06-20 14:30 ` Gregory Maxwell [this message]
2018-06-21 7:09 ` ZmnSCPxj
2018-06-27 7:29 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQihGNvOsRVyr6xN_K0PPse1URKKWH06N7HpcR=OowYYw@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox