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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E041DE15
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 17:23:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2AE2319
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 17:23:17 +0000 (UTC)
Received: from [30.217.169.144] (66-87-119-144.pools.spcsdns.net
[66.87.119.144])
by mail.bluematt.me (Postfix) with ESMTPSA id E38761A0D47;
Sat, 27 Jan 2018 17:23:15 +0000 (UTC)
Date: Sat, 27 Jan 2018 17:23:12 +0000
In-Reply-To: <CAMZUoKmfcmfgErhvAZUQgi8R7bzYCMotT7MMpqQrePej09NBmw@mail.gmail.com>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
<20180123064419.GA1296@erisian.com.au>
<CAMZUoKmfcmfgErhvAZUQgi8R7bzYCMotT7MMpqQrePej09NBmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <B8A34614-FCF3-427B-B05F-2A5F7F7AADFB@mattcorallo.com>
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] Taproot: Privacy preserving switchable scripting
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: Sat, 27 Jan 2018 17:23:19 -0000
Gah, please no=2E I see no material reason why cross-input signature aggreg=
ation shouldn't have the signatures in the first n-1 inputs replaced with s=
omething like a single-byte push where a signature is required to indicate =
aggregation, and the combined signature in the last input at whatever posit=
ion the signature is required=2E
On January 27, 2018 5:07:25 PM UTC, Russell O'Connor via bitcoin-dev <bitc=
oin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
-snip-
>Cross-input signature aggregation probably requires a new field to be
>added
>to the P2P transaction structure to hold the aggregated signature,
>since
>there isn't really a good place to put it in the existing structure
>(there
>are games you can play to make it fit, but I think it is worthwhile)=2E=
=20
>The
>obvious way add block commitments to a new tx field is via the witness
>reserved value mechanism present in BIP 141=2E At this point I think
>there
>will be some leeway to adjust the discount on the weight of this new
>aggregated signature tx field so that even a single input taproot using
>the
>aggregated signature system (here an aggregation of 1 signature) ends
>up no
>more expensive than a single input segwit P2WPKH=2E
|
