1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4F7E0F67
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jun 2018 14:30:57 +0000 (UTC)
Received: by mail-vk0-f65.google.com with SMTP id d74-v6so2052175vke.10
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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
X-Google-Sender-Auth: _bnMJUTRBLtXXSg2sjeFrg1egHs
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"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<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.
|
