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
|
Return-Path: <esotericnonsense@esotericnonsense.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 418E5FA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Feb 2018 19:52:45 +0000 (UTC)
X-Greylist: delayed 00:08:22 by SQLgrey-1.7.6
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
[66.111.4.26])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B6C8C5C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Feb 2018 19:52:44 +0000 (UTC)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
by mailout.nyi.internal (Postfix) with ESMTP id A0CBE20E5E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Feb 2018 14:44:21 -0500 (EST)
Received: from web4 ([10.202.2.214])
by compute6.internal (MEProxy); Thu, 22 Feb 2018 14:44:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=GSPCey
80ldS4HdRrJlipHdODOJ+ixzSDPGCB9Z2dZ1U=; b=E5ZQlaymSr2En0WQa/3ZjM
dNB0IaFz8P1KbJgJ3FvevodXn901By1Nxx/ab56J680Withbr5Bk2l6rX7BVE8rp
7lvTMY9y9Zm6vM24igc8TM69l3SgVxUrBOQCYzju3UN7vlxSGHaWlypJ4e/XGS18
JjAmVBcVyQWCHB/oodi+bOSaypV6uhBEILXuHECsME51OR81XSMY6a5rAeM90KwV
+ZfjzuxUe+ALr7Ff1QdOWAY6UanGL8pAZRee/JS7dmFE05KpuPNslmxTDZQ/s23e
S2vH3hfwfFN8wryRaZIa2Sqp+mELCT1rlLhv6YLAU5TJyR7uWEOLu7OZtfPsEr0A
==
X-ME-Sender: <xms:lR2PWs6Ax4zQqVfvQzyG9hDW-e607asC_sr9MO6GfFgblXICrO728A>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id 808A9BA43B; Thu, 22 Feb 2018 14:44:21 -0500 (EST)
Message-Id: <1519328661.898070.1280084352.71F1C1C3@webmail.messagingengine.com>
From: Daniel Edgecumbe <esotericnonsense@esotericnonsense.com>
To: bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405
Date: Thu, 22 Feb 2018 11:44:21 -0800
References: <CAAS2fgSnfd++94+40vnSRxQfi9fk8N6+2-DbjVpssHxFvYveFQ@mail.gmail.com>
<CAMnpzfphzviN9CqZaFa3P-U2OnHn56LYEtWtMktT1D37bPqvcQ@mail.gmail.com>
<CAAS2fgSVHfh2++JLCTOWVmMiwfqSkGgj4O+HR4wTYTXaZr6n9Q@mail.gmail.com>
<CAD5xwhiqcHjy2bFcCzNue+M92z3_QHZra801c6Kx7OBf=68sRw@mail.gmail.com>
<CAMnpzfo3pL0EB1HyzHO1sEiauGarRUHaWOG-pzMe40wBsGiN3g@mail.gmail.com>
In-Reply-To: <CAMnpzfo3pL0EB1HyzHO1sEiauGarRUHaWOG-pzMe40wBsGiN3g@mail.gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 24 Feb 2018 17:08:57 +0000
Subject: Re: [bitcoin-dev] Graftroot: Private and efficient surrogate
scripts under the taproot assumption
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, 22 Feb 2018 19:52:45 -0000
> However, the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate. With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.
I don't think that binding grafts to a particular transaction requires this aggregation.
It seems to me that you could just sign H(txid, script) rather than H(script).
I'm not aware of whether this would break aggregation.
---
Daniel Edgecumbe / esotericnonsense
esotericnonsense@esotericnonsense.com
https://esotericnonsense.com
https://danedgecumbe.com
|
