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
|
Return-Path: <jasonles@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 531329E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jun 2018 00:39:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
[209.85.192.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E56F48A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jun 2018 00:39:45 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id a22-v6so674190pfo.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Jun 2018 17:39:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=message-id:mime-version:to:from:subject:date:importance;
bh=XNdtzX6JuDtGaqOmhh43tmj/ocvLH6wBk/Y1d/lnuWY=;
b=tBI+tlHz8vEN4xOjJ2Pyts/PBe/lY0+ZOUcPXe+2C3VbmKLRtDWqrLQ6hMsCjJCSRA
u7BOxi5DfE1eVuZGHZy+9KJNdw1Nrqi94Iu6mNBt7XF650+3hQrfHT3y8XLYao09jTJ3
JrkqFiI63imXdj1rYO93Plzui/CNnhxXEQeHF2PlgEU5Cnvo98oVa9YLus1zLCCGTCFd
HaZdkYwK4kBNV12RBGOTZpIgxo1UDCsTZAfbBOh+knTiBKEO72YQM7Z1pE9s7WOT44fR
CbHwubeRJQQYOob+YxF8drjA/rnqItr/oa7rqElldPGcK6n52K2b89AR1HP31NLWVLTF
wtQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:message-id:mime-version:to:from:subject:date
:importance;
bh=XNdtzX6JuDtGaqOmhh43tmj/ocvLH6wBk/Y1d/lnuWY=;
b=QmpGzN3AKr4En8ItGDpiv3Y0c/pq5xaoWpQWLY3apTVEQVoTSyE1uQ//xdzuytMdiQ
5p9Yr/310Iu9IjX6GxkhNPsrCjE1wjmmeW+KnetHJuDqIjJj+/hYK7BvQstfwBvDLFoN
/nO7aF/zW40Jrq/2+8/ceQ6vPG+1GHYOrft3vNiMRA4KeGGqdivrmWahJeW1He24+2mA
o8lbvc7UQZxNrre9L3Jiz3KtecUxD3qDbwnSXxPTo+XrF27xsGsTEaLVyii3TmnorRZR
qe094Mg3l2TeDaD4l8UkNofIeXOWtfLFOFrjAPYBUwxDcwkpsZRxcUtLA1NaYDaqcyjC
zwXQ==
X-Gm-Message-State: APt69E0jIcQIZzvLUlusNYZ4xObA88LcCYuA4btFIAnYb+L7nXui7ADZ
O1thFbGTvO6fDZONZWTeJm1vPxA=
X-Google-Smtp-Source: ADUXVKJ5hUxBf5vz+0aH2iokYf6CMFcYbNuT2o7VTkmtTj9zWmmvaR9tYs4j4oEy/9xXAOerH2ZTXw==
X-Received: by 2002:a62:6f86:: with SMTP id
k128-v6mr20400619pfc.150.1529455185249;
Tue, 19 Jun 2018 17:39:45 -0700 (PDT)
Received: from ?IPv6:::ffff:192.168.7.31? (cpe-107-185-81-42.socal.res.rr.com.
[107.185.81.42]) by smtp.gmail.com with ESMTPSA id
g4-v6sm1174103pfg.38.2018.06.19.17.39.44
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 19 Jun 2018 17:39:44 -0700 (PDT)
Message-ID: <5b29a250.1c69fb81.8d368.4610@mx.google.com>
MIME-Version: 1.0
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
From: Jason Les <jasonles@gmail.com>
Date: Tue, 19 Jun 2018 17:39:46 -0700
Importance: normal
X-Priority: 3
Content-Type: multipart/alternative;
boundary="_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_"
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: Wed, 20 Jun 2018 00:42:48 +0000
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, 20 Jun 2018 00:39:46 -0000
--_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote:
...
> First of all, it's unclear to me to what extent projects have already
> worked on implementations, and thus to what extent the specification
> is still subject to change. A response of "this is way too late" is
> perfectly fine.
...
I am working on a python implementation of BIP 174 as part of a multi-sig h=
ardware wallet I have in the works. I am not so far along as to say that al=
l these changes are way too late, but I=E2=80=99ll comment on the following=
:
> Key-value map model or set model
I believe the key-value map model should be kept because as Jonas Schnelli =
said it=E2=80=99s probably not worth significantly breaking existing implem=
entations like Peter Gray=E2=80=99s, or maybe more who have not spoken up. =
However, I appreciate the benefit of the set model particularly in regards =
to size consideration and the merging of redeemscripts and witnesscripts in=
to single =E2=80=9Cscripts=E2=80=9D records.
>Ability for Combiners to verify two PSBT are for the same transaction
This idea makes a lot of sense, much more intuitive.
>Hex encoding?
I was hoping for some standard here was well and I agree using something mo=
re compact than hex is important. My understanding is Z85 is better for use=
with JSON than Base64, which is probably a good benefit to have here.
I will continue developing under the current spec and if there ends up bein=
g consensus for some of the changes here I=E2=80=99m fine with re-doing the=
work. I will be following this thread closer now.
Best,
Jason Les
--_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht=
tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name=
=3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=3DEN-US><div class=3DWordSection1><p class=3DM=
soNormal>On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote:</p>=
<p class=3DMsoNormal>...</p><p class=3DMsoNormal>> First of all, it's un=
clear to me to what extent projects have already</p><p class=3DMsoNormal>&g=
t; worked on implementations, and thus to what extent the specification</p>=
<p class=3DMsoNormal>> is still subject to change. A response of "t=
his is way too late" is</p><p class=3DMsoNormal>> perfectly fine.</=
p><p class=3DMsoNormal>...</p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>I am working on a python implementation of BIP 174 as par=
t of a multi-sig hardware wallet I have in the works. I am not so far along=
as to say that all these changes are way too late, but I=E2=80=99ll commen=
t on the following:</p><p class=3DMsoNormal><o:p> </o:p></p><p class=
=3DMsoNormal>> Key-value map model or set model</p><p class=3DMsoNormal>=
I believe the key-value map model should be kept because as Jonas Schnelli =
said it=E2=80=99s probably not worth significantly breaking existing implem=
entations like Peter Gray=E2=80=99s, or maybe more who have not spoken up. =
However, I appreciate the benefit of the set model particularly in regards =
to size consideration and the merging of redeemscripts and witnesscripts in=
to single =E2=80=9Cscripts=E2=80=9D records.</p><p class=3DMsoNormal><o:p>&=
nbsp;</o:p></p><p class=3DMsoNormal>>Ability for Combiners to verify two=
PSBT are for the same transaction</p><p class=3DMsoNormal>This idea makes =
a lot of sense, much more intuitive.</p><p class=3DMsoNormal><o:p> </o=
:p></p><p class=3DMsoNormal>>Hex encoding?</p><p class=3DMsoNormal>I was=
hoping for some standard here was well and I agree using something more co=
mpact than hex is important. My understanding is Z85 is better for use with=
JSON than Base64, which is probably a good benefit to have here.</p><p cla=
ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I will continue de=
veloping under the current spec and if there ends up being consensus for so=
me of the changes here I=E2=80=99m fine with re-doing the work. I will be f=
ollowing this thread closer now.</p><p class=3DMsoNormal><o:p> </o:p><=
/p><p class=3DMsoNormal>Best,</p><p class=3DMsoNormal>Jason Les</p><p class=
=3DMsoNormal><o:p> </o:p></p></div></body></html>=
--_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_--
|
