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
|
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 77C8F11E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 20:05:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com
[209.85.217.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1E23772
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 20:05:34 +0000 (UTC)
Received: by mail-ua0-f176.google.com with SMTP id t14-v6so16995407uao.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 13:05:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=4VQFrtwHA1cKnJk1HvAGL+r9lQ2KSGn9fgQW51037Hc=;
b=ri12L1u0ocopChYCS+95xb8gLrPgIcDsmlHJSidlfaZblVsLTNHrWB9f6jVgQJF7G6
+SzsSMoER8X9QOyoBN5KBc+NdOcoK3Hu6TjdFm3ikqkf9uiSdsWAAnSJ4sfdGJyLoDT1
0Jryw2AV5KdKQWRoRMxRGKIsOCUfCAK8N15Acl9iygLiHx+Eo4CrgmBnMwRoABiDfGWg
G/wpS1TBSFDj1gDjgnCwq3GCLSWkTlXNGniwj7JduqDJ5VUmjj7e+WcUDzh0gpQwtFpy
XdMiCuPNlCp/Ke9WxGEY9AWDpXs+AxRW+yj8c+3/Ya4FFrW/MKQV9w5m8+H5yrLM6gFa
V36g==
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:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=4VQFrtwHA1cKnJk1HvAGL+r9lQ2KSGn9fgQW51037Hc=;
b=q0KHEq4jywKyrG9Z2eR2OyjHJLIRKb10b5lc1jVoVjCbch93vvzsYNKwdymgsF44WO
neXGSxIJyV0nh7UUj1fuDwQMfF2bAaKOd2wYhn6zUfApNPGbIJRTMpbeFSW+7RrA4E9n
VXX144E2M2Dmw6CiQ04vdlfYxxqLPMTGtMH+rB7xnt2DghQ6azmX684WyQyHVtYZIr+n
JuscL8V8R7Vj2QYxCKVLzy51Y2D6lm4h0p1us8NKQXJ4RmGD0OkmUNaX+vbOrn8/U5oi
1KTEwyoARBj3YnqS6MoVcZD0FgF1eaYPpHvKCQVRhsd6Dlbj27hKjpm/pKYDk4hmjEzT
USBw==
X-Gm-Message-State: AOUpUlE13+3JvKgihOjsIFDEj/AsqzvqmSlHtQtrgb635VP4eziqZydf
QFa29B0D0CAIbyhcp0aZ9wHxY7GeLQ3RK+QCnq8=
X-Google-Smtp-Source: AAOMgpfcyQz8pywOwUbN8gB68BUQbbkFbRVPuz/+bAnquTQ6Q4Ia4T2n27+xWL8Mc8y7CSPYpdva7zWv9J/cH3aB0FQ=
X-Received: by 2002:ab0:5cc7:: with SMTP id z7-v6mr37473uaf.107.1531339533955;
Wed, 11 Jul 2018 13:05:33 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 2002:a67:51c9:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 13:05:32
-0700 (PDT)
In-Reply-To: <CAPg+sBi0zqpUka_YLDAgh1WHbYmXCdRyb=Givz-k1X=L9hV+Lw@mail.gmail.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
<f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com>
<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
<CAPg+sBhhYuMi6E1in7wZovX7R7M=450cm6vxaGC1Sxr=cJAZsw@mail.gmail.com>
<881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com>
<CAPg+sBg4MCOoMDBVQ2eZ=p3iS3dq506Jh4vUNBmmM20a6uCwYw@mail.gmail.com>
<95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com>
<RdSjdFhvANrG9ve8bXVnqs68ih5_iVK11jdOAL6WoMI2358TdylR3H2SyGHQfByKwMYYOfIJIOq0l6clYf-az8_D_D-D7cByzqbyYt1nV4c=@achow101.com>
<c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
<CAPg+sBjczKB-tvGTpsDr8qDwfh6b_8M-2AdCwHR+DSC8pwY92Q@mail.gmail.com>
<d1cc06c5-1d75-902a-1f2b-e5352c862fd6@satoshilabs.com>
<CAPg+sBi1Rt_V1V0K50RN-c6wr8hW+5OYWx4aR-Kh8Dp-U0LLdA@mail.gmail.com>
<797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com>
<CAPg+sBi0zqpUka_YLDAgh1WHbYmXCdRyb=Givz-k1X=L9hV+Lw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 11 Jul 2018 20:05:32 +0000
X-Google-Sender-Auth: Ye7dcGoW4F0ft8ixBxwkcPGP7J4
Message-ID: <CAAS2fgSah=v3p78WDNnnk_vQh65OhcFo7WnnSSf4ni8kzZw_ew@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <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: Re: [bitcoin-dev] BIP 174 thoughts
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: Wed, 11 Jul 2018 20:05:35 -0000
On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I don't think that's a particularly useful policy, but certainly
> Signers are allowed to implement any policy they like about what they
> accept in signing.
Do we really want the specification to permit conforming
implementations to refuse to sign because there is extra metadata?
ISTM this would make it very hard to implement new features that
require extra data. For example, say you have a checkmultisig with one
key in it using schnorr multisignature which require the extra rounds
to establish an R, and the other keys are legacy stuff. If the other
signer(s) suddenly stop working when there are extra fields irrelevant
to them, then this will create a substantial pressure to not extend
the PSBT in the intended way, but to instead find places to stuff the
extra data where it won't interfere with already deployed signers.
This would be really unfortunate since PSBT was created specifically
to avoid field stuffing (otherwise we could have accomplished all the
intended goals by field stuffing a bitcoin transaction encoding).
Obviously no signer should be signing data they don't understand, but
extra data that they ignore which doesn't change their signature
should not stop them. Another way of looking at it, perhaps somewhere
someplace some idiot defined signatures starting with 0xdead to give
away all the users funds or whatever. That's something you "can't
understand" either, ... but no one would conclude because something
could happen somewhere that you don't know about that you just can't
sign at all... yet it is possible. :)
If someone wants to make a non-conforming signer, that is cool too and
they may have good reason to do so-- but I think it would be sad if
new applications get gunked up, slowed down or forced to use ugly
hacks, due to the intentional extension support in the protocol being
blocked by things claiming to support the spec. The whole reason the
spec doesn't lock in exactly the possible fields and allow no others
is to allow extensions without breaking compatibility.
|
