MIME-Version: 1.0
In-Reply-To: <87h8lpbi39.fsf@jb55.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
	<21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
	<20180621195654.GC99379@coinkite.com>
	<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
	<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
	<f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com>
	<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
	<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
	<87h8lpbi39.fsf@jb55.com>
From: Marek Palatinus <marek@palatinus.cz>
Date: Tue, 26 Jun 2018 19:11:05 +0200
Message-ID: <CAJna-HiJ9S8D_Jrw6ho_tTUEaF9bGxPnXmEUmUNRuJV-rDizPQ@mail.gmail.com>
To: William Casarin <jb55@jb55.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d2392e056f8e97ba"
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list

--000000000000d2392e056f8e97ba
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> seems a bit overkill for how simple the format is, and pulling in a
> large dependency just for this is a bit silly. Although making it
> protobuf-compatible is an interesting idea, but I fear would be more
> work than is worth? I haven't looked closed enough at the protobuf
> encoding to be sure.
>
> > ...while at the same time, implementing "protobuf-based-BIP174" by
> > hand is roughly equally difficult as implementing the current BIP174.
>
> as a data point, I was able to build a simple serializer[1] in about an
> afternoon. I would much prefer to use this lib in say, clightning (my
> original goal), without having to have the larger protobuf dependency.
>
>
That was exactly matejcik's point; you can easily write protobuf-compatible
encoder/decoder for such simple structure in about an afternoon, if you
need. Or you can use existing protobuf parsers in matter of minute, if you
don't care about dependencies.

Also, many projects already have protobuf parsers, so it work in other way,
too; you need BIP174 parser as extra dependency/library, although you
already use protobuf library (like Trezor device does). For needs of
BIP174, the difference between ad-hoc format and protobuf is neglible, so
it is a mistake to introduce yet another format.

slush

--000000000000d2392e056f8e97ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev <span =
dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">seems a bit overkill for how simple the form=
at is, and pulling in a<br>
large dependency just for this is a bit silly. Although making it<br>
protobuf-compatible is an interesting idea, but I fear would be more<br>
work than is worth? I haven&#39;t looked closed enough at the protobuf<br>
encoding to be sure.<br>
<span class=3D""><br>
&gt; ...while at the same time, implementing &quot;protobuf-based-BIP174&qu=
ot; by<br>
&gt; hand is roughly equally difficult as implementing the current BIP174.<=
br>
<br>
</span>as a data point, I was able to build a simple serializer[1] in about=
 an<br>
afternoon. I would much prefer to use this lib in say, clightning (my<br>
original goal), without having to have the larger protobuf dependency.<br>
<br></blockquote><div><br></div><div>That was exactly matejcik&#39;s point;=
 you can easily write protobuf-compatible encoder/decoder for such simple s=
tructure in about an afternoon, if you need. Or you can use existing protob=
uf parsers in matter of minute, if you don&#39;t care about dependencies.</=
div><div><br></div><div>Also, many projects already have protobuf parsers, =
so it work in other way, too; you need BIP174 parser as extra dependency/li=
brary, although you already use protobuf library (like Trezor device does).=
 For needs of BIP174, the difference between ad-hoc format and protobuf is =
neglible, so it is a mistake to introduce yet another format.</div><div><br=
></div><div>slush</div></div></div></div>

--000000000000d2392e056f8e97ba--