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
121
122
123
124
125
126
127
128
129
130
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5646FE08
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 21:00:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com
[209.85.192.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 388C9171
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 21:00:06 +0000 (UTC)
Received: by mail-pf0-f174.google.com with SMTP id e76so15614364pfk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 13:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:mime-version:subject:date:references
:to:in-reply-to:message-id;
bh=sayvxnOgJtaao51vot7Q+0GrOUzCBEc3KZG57xy5eb4=;
b=kGJRtHEhGIjPkEONj1DzMDyC35sObml3M+/U5tAwgkYhSmI2gVeCcZSyuc/eUs7YIK
K/v1xGODm/s06wRGNJcAjZUKLDpv5qYI8AsKED3HPHsna06uoWqt3DIH5JVFmNGOPxe3
QMUxhAMDXQ2PiKeYdCRy4yUAyl9/iRI70saubrrFOU5+vHsZBFBFIy0JiQJjNALnVvH2
lHTW+CDFK1OQKQaUPVYMA3nmUEldJXGy9q1CRCTDqXCXVHazWguU1M9B86+GPRovZc4P
Lo2SVjpUrhCkpD7bUZSIdddWiTakFBT+2DH+GLogOjvUfatlpk47Xf1sd/SkyYtZWCzM
vw5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version
:subject:date:references:to:in-reply-to:message-id;
bh=sayvxnOgJtaao51vot7Q+0GrOUzCBEc3KZG57xy5eb4=;
b=MryP/Y3CM2+Bh9vqYPgnIxdswwbR9SoeLbwLmHEiVKSwiAT8UoIN1G1Uq8df3mtyTU
CVabhdey9wvK/cLalbj73Oj2l2oL0PKWXjrW2xZjdCbLaKz/c92/mj7c98PtUz2aj8aZ
ARZEWxN9oX8FXt/5XBcSUf60lw1qEhi3h4mWI9v/28ThuxABwBVA/Y7dqa/TZqWUEV+I
lqBbVtWDnOcg4hnAleyBu3xn1N1xT+67Zhdwu1vmzdUvEaJtC3Hw5U017+wijZMHfv1E
cOR6xZzhaIu+3cDWKJ5mNxxXslTO16v7G0anJnES9+W0pQsJ5uKULEaldG/T4zQ7j1AM
HWGA==
X-Gm-Message-State: AKwxytfyKLoHJLm+zKvbcRMvpPdGgZ/qsTvIv8a06keibiDEWMTXnldj
XzFWqTExFgLEgef/rcktLi11yCxjC4g=
X-Google-Smtp-Source: ACJfBotkh1JyaGnkKzjIZTfwgVj7yVV4kPgm+sS5XtvL35IJw8XqiuzKzZcbZEoeX2Oj/wh+PUH9KA==
X-Received: by 2002:a17:902:8a97:: with SMTP id
p23-v6mr402196plo.74.1516309205662;
Thu, 18 Jan 2018 13:00:05 -0800 (PST)
Received: from ?IPv6:2601:646:8080:4dbb:9a2:1c1e:aaf8:7e8c?
([2601:646:8080:4dbb:9a2:1c1e:aaf8:7e8c])
by smtp.gmail.com with ESMTPSA id
u195sm12770517pgb.64.2018.01.18.13.00.04
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 18 Jan 2018 13:00:05 -0800 (PST)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 18 Jan 2018 13:00:03 -0800
References: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>
Message-Id: <D41C805A-726C-40E6-8760-44D411E9E47F@friedenbach.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Thu, 18 Jan 2018 21:38:51 +0000
Subject: Re: [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 21:00:07 -0000
The downsides could be mitigated somewhat by only making the dual =
interpretation apply to outputs older than a cutoff time after the =
activation of the new feature. For example, five years after the initial =
activation of the sigagg soft-fork, the sigagg rules will apply to =
pre-activation UTXOs as well. That would allow old UTXOs to be spent =
more cheaply, perhaps making some dust usable again, but anyone who =
purposefully sent funds to old-style outputs after the cutoff are not =
opened up to the dual interpretation.
> On Jan 18, 2018, at 11:30 AM, Gregory Maxwell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> Am I missing any other arguments?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
