<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">seems a bit overkill for how simple the format 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't looked closed enough at the protobuf<br>
encoding to be sure.<br>
<span class=""><br>
> ...while at the same time, implementing "protobuf-based-BIP174" by<br>
> 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'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.</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/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.</div><div><br></div><div>slush</div></div></div></div>