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
108
109
110
111
112
113
114
115
116
117
118
119
120
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 41879723
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 12:39:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.wpsoftware.net (wpsoftware.net [96.53.77.134])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 15F7B6EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 12:39:57 +0000 (UTC)
Received: from boulet.lan (boulot.lan [192.168.0.193])
by mail.wpsoftware.net (Postfix) with ESMTPSA id 10C3340252;
Thu, 24 May 2018 12:39:55 +0000 (UTC)
Date: Thu, 24 May 2018 12:39:55 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Natanael <natanael.l@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180524123955.GW14992@boulet.lan>
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>
<CAAt2M1_Kc5O062r2KOh2VWMUOv6itegvXwg87Ox+1Y2=mXMw8w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="qxpYSgLynlcP4boX"
Content-Disposition: inline
In-Reply-To: <CAAt2M1_Kc5O062r2KOh2VWMUOv6itegvXwg87Ox+1Y2=mXMw8w@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Thu, 24 May 2018 12:39:58 -0000
--qxpYSgLynlcP4boX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, May 24, 2018 at 11:44:16AM +0200, Natanael via bitcoin-dev wrote:
>=20
> As stated above by Wuille this seems to not be a concern for typical P2SH
> uses, but my argument here is simply that in many cases, not all
> stakeholders in a transaction will hold one of the private keys required =
to
> sign. And such stakeholders would want a guarantee that the original scri=
pt
> is followed as promised.
>
In this case, even mandatory graftroot would not allow the signing stakehol=
ders
to take the coins. The reason is that if there are _any_ non-signing script
conditions that must be followed, then to use Taproot the top-level public =
key
needs to be unusable, e.g. by being a NUMS point. In that case the public k=
ey
would also be unusable for Graftroot.
Another way to see this is -- in any context where Graftroot seems dangerou=
s,
there needs to be a reason why the ability to just create transactions is n=
ot
dangerous. In your example it seems that the signing parties can just take
the coins with or without Graftroot, so the problem is not in Graftroot but
in the way that the example is set up.
=20
> I'm not concerned by the ability to move funds to an address with the new
> rules that you'd otherwise graftroot in, only that you can provide a
> transparent guarantee that you ALSO follow the original script as promise=
d.
> What happens *after* you have followed the original script is unrelated,
> IMHO.
>
To do this in Taproot you need to disable the top-level key, which will also
disable Graftroot.=20
--=20
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom
--qxpYSgLynlcP4boX
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJbBrKaAAoJEMWI1jzkG5fBmngH/3LGRcQq/vyoxliyoOJFKynT
4814NsJLzyQpL65G4ixlmhbi26FsKhRT4Y0IpaZJRMFFbgcetaBsW1EV05prnQNi
Vjz3eG/0oCgl+PmJnOUiPwi2ZBe/EMzKL/XexHwGSbwVvpodRDR/rnEYSptWaguj
je+JmfA0vafPoWWkNKNN/9KOKTx/Ak5kfP5vZjMiUdx/QaGsL+E7DXwMTBCr0doY
gJcHmW7hzS3AUREbvjGwrLl/SBcSo9dmTY89PwXSdXBElU95/vsrZU6OuGQBBrL0
u82o6YA0gWdf5n9taFmKmWqDJygQ94sJGaNnIMIZD71daLEFs5RZDen7o2Wq22s=
=OrGE
-----END PGP SIGNATURE-----
--qxpYSgLynlcP4boX--
|
