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
Content-Type: multipart/alternative;
	boundary="_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_"
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list

--_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>&gt; 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>&gt; is still subject to change. A response of &quot;t=
his is way too late&quot; is</p><p class=3DMsoNormal>&gt; perfectly fine.</=
p><p class=3DMsoNormal>...</p><p class=3DMsoNormal><o:p>&nbsp;</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>&nbsp;</o:p></p><p class=
=3DMsoNormal>&gt; 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>&gt;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>&nbsp;</o=
:p></p><p class=3DMsoNormal>&gt;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>&nbsp;</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>&nbsp;</o:p><=
/p><p class=3DMsoNormal>Best,</p><p class=3DMsoNormal>Jason Les</p><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=

--_964DFD8B-30EE-4C6B-ACB4-3156DA0DBE69_--