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
|
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 9280FF13
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 19:30:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com
[209.85.217.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29471E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 19:30:11 +0000 (UTC)
Received: by mail-ua0-f173.google.com with SMTP id d1so8495363uak.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 11:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=qm+5th/jQ+hWLMvMmU+fYlg+cawJr6Gl/C4WcEtu7l4=;
b=O4EF9/S5hYtzEiOaQTDyQHGk/3f8Doo4jU64H4b8rmvOL+UM3w45AX1Zy0yrMqcCoM
v745EMTcbYVX2WZW1citbIGHGIaRKJlYLbhSxX8ggFh2chzosiQlpH8MKl/RuaEm5SsW
EiGuXRlEUOr/Aw5ZbUjy7q5LPefGFFrIw/A7qlrUmc9ho/ojt49z9nYPKDo6NHRbcyFe
0uYdBwWwd2d/gO13PaWAO3wqicFdv8XgXanI3uUrA5ymUvC33MU3ztk01zo6nBxwyko0
Z7u288OD46Y4/Y0vMSl6hwEO+XH6e3+AQBiKST4N6UUfhZuDY00et71Xr8czEHe6DSHM
pDmQ==
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:from:date:message-id:subject
:to; bh=qm+5th/jQ+hWLMvMmU+fYlg+cawJr6Gl/C4WcEtu7l4=;
b=hseOfvpetMwIPPhzvmuttGgus8+s6x3HpS/a9fQ/sqbHP4zQut/aA7xz7G/gii/RHU
LCnBf4XgH3Lz9QY0VcVpE6al6UVTNGH4ueh9x3sZRzCf/DRFW62/aAGL+n+4rvBAW2IN
6JLLhqtzU89x7QcXd54IJYbmT4RHk+neW/Svt6LIaK05t0VAFH2ZIU81ZEpUtwUAzIum
9JEBjeVbIUYePaRSmOwIhuDSXZqWlzLfgoLDMa/98rinyaZQ9ndcdPuUUbzOPV8IsplQ
v3lGKY+9vUUnjfWhWjaa+JLVku7yJNZicXbpv4gWwZuXXntn+m34JImldDorYgTAnX4L
4pXg==
X-Gm-Message-State: AKwxytfnn0A6U+BXj8OEGlKnHZ/jD9STWEwZ7bAZB92QWZNTwarglhzd
chdiIU3Euf2UNFVzBSiWTW/o3KKepxZ1Ym8nbXw=
X-Google-Smtp-Source: ACJfBouIt8ujLcV2LS/H+KZ2+3p10c2iGvobvlxFjKkMULF2+7nHr5uNWny6xfIDhjkKqWs4hiVTdFF7h4UIhkZju1E=
X-Received: by 10.176.9.210 with SMTP id e18mr5423218uah.21.1516303810078;
Thu, 18 Jan 2018 11:30:10 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.85.152 with HTTP; Thu, 18 Jan 2018 11:30:09 -0800 (PST)
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 18 Jan 2018 19:30:09 +0000
X-Google-Sender-Auth: wb6uHCr2n63bQ6Ajat0du8UyOqM
Message-ID: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>
To: Bitcoin Dev <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: [bitcoin-dev] ScriptPubkey consensus translation
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, 18 Jan 2018 19:30:11 -0000
A common question when discussing newer more efficient pubkey types--
like signature aggregation or even just segwit-- is "will this thing
make the spending of already existing outputs more efficient", which
unfortunately gets an answer of No because the redemption instructions
for existing outputs have already been set, and don't incorporate
these new features.
This is good news in that no one ends up being forced to expose their
own funds to new cryptosystems whos security they may not trust. When
sigagg is deployed, for example, any cryptographic risk in it is borne
by people who opted into using it.
Lets imagine though that segwit-with-sigagg has been long deployed,
widely used, and is more or less universally accepted as at least as
good as an old P2PKH.
In that case, it might be plausible to include in a hardfork a
consensus rule that lets someone spend scriptPubkey's matching
specific templates as though they were an alternative template. So
then an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent
as though it used the analogous p2w-sigagg script.
The main limitation is that there is some risk of breaking the
security assumptions of some complicated external protocol e.g. that
assumed that having a schnorr oracle for a key wouldn't let you spend
coins connected to that key. This seems like a pretty contrived
concern to me however, and it's one that can largely be addressed by
ample communication in advance. (E.g. discouraging the creation of
excessively fragile things like that, and finding out if any exist so
they can be worked around).
Am I missing any other arguments?
|
