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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC75C9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jun 2016 14:40:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
[209.85.215.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBFD81C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jun 2016 14:40:19 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id f6so50022819lfg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jun 2016 07:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc; bh=3RFSHgoQCQ1uWMD7QspZY/ODOPDKoS3ItGG1YM4vLrU=;
b=tMCaZ3xIywVp+58IYYKLf3jx/RRjhxTKui+xpafKVdTFPQ0XDbeI+kAv31LW3iF45r
vM1eCGEUSfSpiFkTfN7aPyGb5icz1W33RgvDkdlYoH8msuIwrDYZ4/gcp8ss7l73asYy
BS2L9FAmf++EukSydaAVEvoax3TzjoliA44K8jyLvCbwVtKExn5hyRsMT2Q2YA4U7PhZ
zFUtu4+xb0yQWXL6sGXY6WGVRGiszSnTp4Q1i89K/kxpjmQ/1cAVL4X+ga93az9pQ2VV
dngNETbV1TEhB0g0H7kKrFhofOePAEq/DcXX9ubgZ4/nDBZu5StEVMhlfnu7hZ9YwAkZ
TZGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=3RFSHgoQCQ1uWMD7QspZY/ODOPDKoS3ItGG1YM4vLrU=;
b=JCnkljaeJTxfNLgEHXR2BVtWzSZB8agCRuZ/oMTEkNrSR4t+dGvMpUtm7rzSZTbuua
sj9Z/4hWLhYK7dEFuSiyK0ibSffzLxBUHv884MZWFWCwvabwmTB2zAr7vYgDhZM739hV
1oOrNCzK14jnWYwVuDWuMfTvh/SHZrgc0ejzEb5BEBlJvduLTK7Hzju6BifmZFqSCQKS
ML/HaxXU3zNlAf6dTngYXI4Pzv2pwOmO/2TaKXNZ1zKPFwZnG/I/kKEg7hXopkUXSjcn
Mrl9BJOV2mrQeC+Udu+LLwnz8bWnBjrt2baba1i44KrKQVOuLYtB23EXJlZJVgyGTsd+
xwhg==
X-Gm-Message-State: ALyK8tLlaJ2Q8a30Lzp051D1lKHLhRQcC2E1Dm12Bsn08li1i42VJZB0fC4nRY8xbiqJv1EAIfE3cqEdfsgazA==
MIME-Version: 1.0
X-Received: by 10.46.0.16 with SMTP id 16mr2748911lja.48.1465742417779; Sun,
12 Jun 2016 07:40:17 -0700 (PDT)
Received: by 10.114.172.115 with HTTP; Sun, 12 Jun 2016 07:40:17 -0700 (PDT)
Received: by 10.114.172.115 with HTTP; Sun, 12 Jun 2016 07:40:17 -0700 (PDT)
In-Reply-To: <201606081645.12598.luke@dashjr.org>
References: <A7E9BC23-6860-4B31-9D4E-11F771A5E581@xbt.hk>
<201606080729.24789.luke@dashjr.org>
<D192E876-1A4F-4B06-86F6-54F1BDEC857D@xbt.hk>
<201606081645.12598.luke@dashjr.org>
Date: Sun, 12 Jun 2016 16:40:17 +0200
Message-ID: <CAPg+sBjXctdezfSbi1y7KVpNS4BwD6HESCgZLNaQGqDotVtwGQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Luke Dash-Jr <luke@dashjr.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1142c0aa24e348053515c0db
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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] BIP141 segwit consensus rule update: extension of
witness program definition
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, 12 Jun 2016 14:40:20 -0000
--001a1142c0aa24e348053515c0db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Jun 8, 2016 18:46, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote:
> > If someday 32 bytes hash is deemed to be unsafe, the txid would also be
> > unsafe and a hard fork might be needed. Therefore, I don=E2=80=99t see =
how a
> > witness program larger than 40 bytes would be useful in any case (as it
is
> > more expensive and takes more UTXO space). I think Pieter doesn=E2=80=
=99t want
to
> > make it unnecessarily lenient.
>
> There is no harm in being lenient, but it limits the ability to do
softfork
> upgrades in the future. I appreciate Pieter's concern that we'd need to d=
o
> more development and testing to go to this extreme, which is why I am onl=
y
> asking the limit raised to 75 bytes.
No strong opinion, but I'd rather not change it anymore, as I don't see the
point. Any data you would want to encode there can be moved to the witness
at 1/4 the cost and replaced by a 256-bit hash. If the data is 43 bytes or
higher, that is even cheaper. The only thing that cannot be in the hash is
metadata to indicate what hashing/rule scheme itself is used. I think 68
bits (OP_n + 8 bytes) for that is plenty.
--=20
Pieter
--001a1142c0aa24e348053515c0db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Jun 8, 2016 18:46, "Luke Dashjr via bitcoin-dev"=
; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>> wrote:<br>
><br>
> On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote:<br>
> > If someday 32 bytes hash is deemed to be unsafe, the txid would a=
lso be<br>
> > unsafe and a hard fork might be needed. Therefore, I don=E2=80=99=
t see how a<br>
> > witness program larger than 40 bytes would be useful in any case =
(as it is<br>
> > more expensive and takes more UTXO space). I think Pieter doesn=
=E2=80=99t want to<br>
> > make it unnecessarily lenient.<br>
><br>
> There is no harm in being lenient, but it limits the ability to do sof=
tfork<br>
> upgrades in the future. I appreciate Pieter's concern that we'=
d need to do<br>
> more development and testing to go to this extreme, which is why I am =
only<br>
> asking the limit raised to 75 bytes.</p>
<p dir=3D"ltr">No strong opinion, but I'd rather not change it anymore,=
as I don't see the point. Any data you would want to encode there can =
be moved to the witness at 1/4 the cost and replaced by a 256-bit hash. If =
the data is 43 bytes or higher, that is even cheaper. The only thing that c=
annot be in the hash is metadata to indicate what hashing/rule scheme itsel=
f is used. I think 68 bits (OP_n + 8 bytes) for that is plenty.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a1142c0aa24e348053515c0db--
|
