rich1.0Marek Palatinus [ARCHIVE] (npub1xt…acz68)https://yabu.me/npub1xtqansnal58rjnnxvyke6kzuvxsz0twg4456awy6ff0525yqgjxqjacz68njumphttps://yabu.me📅 Original date posted:2018-06-26 📝 Original message:On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev < bitcoin-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180626/b277b69a/attachment.html>