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
|
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 1225149D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 20:39:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f196.google.com (mail-pf0-f196.google.com
[209.85.192.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4FADC467
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 20:39:15 +0000 (UTC)
Received: by mail-pf0-f196.google.com with SMTP id f84so3717722pfj.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Oct 2017 13:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=/xqh2X7ZwqJyJBM/v+rL88GJg/QtuRFK4us16alWSwk=;
b=OO2isP94cw5Xf6ncoEQJym3ga3afr/ugDzgQ977++9efRLkQ2cjBpk92hJjgqiolBj
SSUQ66XBUCaCKUGOmuFlyAdQ3cisH9NkY7RdPbYKSNYXjdWB2GjuE4R5eX3tjLeoisZy
AkEg47fimD0KSbUL7O6uqjxQScetaBB3nPc6DD21NTGPYQTCZN0kR42p9NiQERD/6fQO
+AxZLgvuAE41HwAYhongZEzB/DGaR/4ZaSh6sXTkelnj9RoV6b4ANNDrYgLbSh1L1/5X
7QCGSU8xaFAE+o6xkuCL3Ve0BNPcVx72njMdLO7CM0cpna8g6xhT/JHzE2PpQZkJCTTt
Jizw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=/xqh2X7ZwqJyJBM/v+rL88GJg/QtuRFK4us16alWSwk=;
b=bN5TSK+tMhGvB0O7rE8nGVfsSQmu4sx3p+Hr0JXm4GkUjqQ+NdKCy+km9NVn+0y5pF
fW7gQIdyPPV6wOGQUPOoIJ5LKRQi+yt/bi2FGmjP5JTLAXDHTn1LvDCh0AzdQYU3WmcO
dymMcSkLj1j/MVkdjLA4x82v2E43UND6SRxia5xpwWQYc3RXriA/RnOwAoMDvoiPrqbJ
9dVNLRjNJguFEEaIAAlXeqfOIpxZrenNjZ0GH0EA7w/fQX7cvHT2l1p7aIBrwnaC7qTp
zjJSZhdmK3x9vW3PKGP1BBM7ccN7/JTxWpnkn44TttjKLkd7ak6JDYg0zfqzFPsopSVt
d5ww==
X-Gm-Message-State: AHPjjUjm4H8dt7gGyr2M5StL0vrkS/vD/UnpRxCXQRo0oDmuIuxTLVQM
kEPH9zxA0q23kT3Bp5x6nnevnDcNQYY=
X-Google-Smtp-Source: AOwi7QChZLOh+RXAFPAUCGVWUiHhZ5AM5ipNnpZAkIB7B9Vfftp83biPi+BG4mof+Zg7CtNk+ZRkDw==
X-Received: by 10.98.159.76 with SMTP id g73mr12731341pfe.293.1506890354777;
Sun, 01 Oct 2017 13:39:14 -0700 (PDT)
Received: from [192.168.1.125] (c-73-241-30-225.hsd1.ca.comcast.net.
[73.241.30.225])
by smtp.gmail.com with ESMTPSA id d7sm1238712pgf.20.2017.10.01.13.39.13
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 01 Oct 2017 13:39:13 -0700 (PDT)
Content-Type: text/plain;
charset=gb2312
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (15A402)
In-Reply-To: <CAMZUoK=heF1FALyGbi7cpzLiQuhLnsq-5Z2-sTgq5b28sjjeUw@mail.gmail.com>
Date: Sun, 1 Oct 2017 13:39:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC800737-7B93-41BD-BA87-F25B25F95426@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
<201710010247.42180.luke@dashjr.org>
<D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
<CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
<460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org>
<CAMZUoK=heF1FALyGbi7cpzLiQuhLnsq-5Z2-sTgq5b28sjjeUw@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
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: Sun, 01 Oct 2017 20:39:16 -0000
> On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor@blockstream.io> wr=
ote:
>=20
> Creating a Bitcoin script that does not allow malleability is difficult an=
d requires wasting a lot of bytes to do so, typically when handling issues a=
round non-0-or-1 witness values being used with OP_IF, and dealing with non-=
standard-zero values, etc.
Script validation flags of the correct place to do this. We already have pol=
icy validation flags that check for these things. They were not made consens=
us rules with Segwit v0 mainly due to concern over scope creep in an already=
large overhaul, of my memory is correct. Script versions and quadratic hash=
ing fixes where the minimum necessary to allow segwit to activate safely whi=
le still enabling future upgrades that would otherwise have been hard forks.=
We knew that we would be later changing the EC signature scheme to be somet=
hing that supported signature aggregation, and that would be more appropriat=
e time to discuss such changes. As we are considering to do now (although wi=
tness versions means we don=A1=AFt need to omnibus the script upgrade here e=
ither, so a v1 before signature aggregation is ready is fine IMHO).
In any case if there is any general witness malleability due to opcode seman=
tics that it=A1=AFs not fixed by one of our existing policy flags, that is a=
bug and I would encourage you to report it.
> I'll argue that I don't want my counter-party going off and using a very d=
eeply nested key in order to subvert the fee rate we've agreed upon after I'=
ve signed my part of the input. If we are doing multi-party signing of inpu=
ts we need to communicate anyways to construct the transaction. I see no pr=
oblem with requiring my counter-party to choose their keys before I sign so t=
hat I know up front what our fee rate is going to be. If they lose their ke=
ys and need a backup, they should have to come back to me to resign in order=
that we can negotiate a new fee rate for the transaction and who is going t=
o be covering how much of the fee and on which inputs.
Arguing that every single user should be forced to restart an interactive si=
gning session. That=A1=AFs a very strong statement based on something that I=
would say is a preference that depends on circumstances.
What about an optional commitment to witness size in bytes? The value zero m=
eaning =A1=B0I don=A1=AFt care.=A1=B1 I would argue that it should be a maxi=
mum however, and therefor serialized as part of the witness. The serializati=
on of this would be very compact (1 plus the difference between actual and m=
aximum, with zero meaning not used.)=
|
