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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Return-Path: <cryptaxe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A835EE2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 19:56:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com
[209.85.128.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 916375B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 19:56:43 +0000 (UTC)
Received: by mail-wr0-f169.google.com with SMTP id f11so13348450wre.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jan 2018 11:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=qbE0oPRUWwu583WupSfda/kUh/CWMUCtEzjjL7x6rPc=;
b=XR7iO2ROnlk/1KRyIQGCtndd0aSCwDOn71KksrdwFhFBaM5lqNE84AN4xY81NDOfLR
0TOtWTgiTCn1rxnpkhELBe/MPGkOhiUFMMjo79FJh2R5U/vu5eETaVLHbOEz164KMhiJ
YA/rZ51W//zDXdc+lw95SgcifI2TsRBZQlg+fwAgVfyAGuUc7T7tMkv1L915D58mkX6c
vToCeuXdipXkR7nwIbMnIvducIAV+oPxNU3hRQZHyqUdR2wa9QUeC4NMTY7v4xhkC6ic
OJsTxklDWjKVEXHJZUIJxA7lp2Xkd0aUCB+412+UMdi3QJpvLGJbqoJNH6bsDNPx/CJk
VV3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=qbE0oPRUWwu583WupSfda/kUh/CWMUCtEzjjL7x6rPc=;
b=o6r7RAI4EQdhHKV7U5jyoRmrgxh0Gd/3/jVr+3dA1cbDkphTJpG6o/OP06pnF7Zzi7
3BOhJEMsML8NK0otQA23wTBEhStNGVe+XFLPt43YwEi77K0N7Zc8MWq3oyhJJGBSyaK0
gRlhs6yZmOtngba3trP8v1VaIeOgTJZa5Wg40MWRcMt5zYHviocXGCmU5vnRuiFEVGbO
g0TnM1BchDbWHQ0JG1IcXzIGjjZ3C1GclQog9IE0CQpiYydCj7DURUM2fIZ2LsT9ZZOK
nxQjOk3pxTpJiLWXXaQLhl2VsmhowUyVdBL7LuktITVQwaRhMO0Ufh3ClnrU2tDmmuKJ
BXdQ==
X-Gm-Message-State: AKwxytctGMTD9gBfCJ1oPeIBxVsC4KBwjX09dFxOcrDItikesdLL0ThP
05J78l+RSfxBLrGYeOZx9rxgDyRxxunZHCVUC9L4AQ==
X-Google-Smtp-Source: ACJfBouCQzs2rxOOWspLmQOqFPiVwb/QY5BveJvJJ73H9mGkdkQfPpUsdoNk+hMrWKhcEdAIZM5Fc0EdKpBksPJcdb8=
X-Received: by 10.223.130.15 with SMTP id 15mr7477646wrb.94.1516305402187;
Thu, 18 Jan 2018 11:56:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.146.67 with HTTP; Thu, 18 Jan 2018 11:56:41 -0800 (PST)
Received: by 10.28.146.67 with HTTP; Thu, 18 Jan 2018 11:56:41 -0800 (PST)
In-Reply-To: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>
References: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>
From: CryptAxe <cryptaxe@gmail.com>
Date: Thu, 18 Jan 2018 11:56:41 -0800
Message-ID: <CAF5CFkiXAt-xc8g9FLtEuRz1vSu78wMnabjVzKE=Qubb0wU5fA@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114b429ade7c020563125cd1"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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 20:11:38 +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 19:56:44 -0000
--001a114b429ade7c020563125cd1
Content-Type: text/plain; charset="UTF-8"
Technically the change would be an improvement. People should be allowed to
opt-in to systems and big changes like that though, not have developers
change what their outputs mean or open them up to new security risks on
their behalf.
On Jan 18, 2018 11:30 AM, "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114b429ade7c020563125cd1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif">=
Technically the change would be an improvement. </span><span style=3D"font-=
family:sans-serif">People should be allowed to opt-in to systems and big ch=
anges like that though, not have developers change what their outputs mean =
or open them up to new security risks on their behalf.=C2=A0</span></div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jan 18, 20=
18 11:30 AM, "Gregory Maxwell via bitcoin-dev" <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundatio=
n.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>A common question when discussing newer more efficient pubkey types--<br>
like signature aggregation or even just segwit-- is "will this thing<b=
r>
make the spending of already existing outputs more efficient", which<b=
r>
unfortunately gets an answer of No because the redemption instructions<br>
for existing outputs have already been set, and don't incorporate<br>
these new features.<br>
<br>
This is good news in that no one ends up being forced to expose their<br>
own funds to new cryptosystems whos security they may not trust.=C2=A0 When=
<br>
sigagg is deployed, for example, any cryptographic risk in it is borne<br>
by people who opted into using it.<br>
<br>
Lets imagine though that segwit-with-sigagg has been long deployed,<br>
widely used, and is more or less universally accepted as at least as<br>
good as an old P2PKH.<br>
<br>
In that case, it might be plausible to include in a hardfork a<br>
consensus rule that lets someone spend scriptPubkey's matching<br>
specific templates as though they were an alternative template.=C2=A0 So<br=
>
then an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent<br>
as though it used the analogous p2w-sigagg script.<br>
<br>
The main limitation is that there is some risk of breaking the<br>
security assumptions of some complicated external protocol e.g. that<br>
assumed that having a schnorr oracle for a key wouldn't let you spend<b=
r>
coins connected to that key.=C2=A0 This seems like a pretty contrived<br>
concern to me however, and it's one that can largely be addressed by<br=
>
ample communication in advance.=C2=A0 (E.g. discouraging the creation of<br=
>
excessively fragile things like that, and finding out if any exist so<br>
they can be worked around).<br>
<br>
Am I missing any other arguments?<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>
--001a114b429ade7c020563125cd1--
|
