📅 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>;
Marek Palatinus [ARCHIVE] /
npub1xt…acz68
2023-06-07 18:13:12
in reply to nevent1q…wn6t
Author Public Key
npub1xtqansnal58rjnnxvyke6kzuvxsz0twg4456awy6ff0525yqgjxqjacz68Published at
2023-06-07 18:13:12Event JSON
{
"id": "69a67fa02f9467974d9845b6a67438f74e38c0214e565dd8c2921a7b1d24585c",
"pubkey": "32c1d9c27dfd0e394e66612d9d585c61a027adc8ad69aeb89a4a5f455080448c",
"created_at": 1686161592,
"kind": 1,
"tags": [
[
"e",
"cde3c2f1af5ec4e3200e32c7fdbcba54b58741a9d65d38dd383e78325ee0ffcd",
"",
"root"
],
[
"e",
"4dd215ccd19ab147413e47cd94362f827b36d3bde05354ef007c102a4aa8ac49",
"",
"reply"
],
[
"p",
"6fb2fd1f8df298fef3464d220666d5ae7184dfe89dc5cc7d3a177579986c31cb"
]
],
"content": "📅 Original date posted:2018-06-26\n📝 Original message:On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e seems a bit overkill for how simple the format is, and pulling in a\n\u003e large dependency just for this is a bit silly. Although making it\n\u003e protobuf-compatible is an interesting idea, but I fear would be more\n\u003e work than is worth? I haven't looked closed enough at the protobuf\n\u003e encoding to be sure.\n\u003e\n\u003e \u003e ...while at the same time, implementing \"protobuf-based-BIP174\" by\n\u003e \u003e hand is roughly equally difficult as implementing the current BIP174.\n\u003e\n\u003e as a data point, I was able to build a simple serializer[1] in about an\n\u003e afternoon. I would much prefer to use this lib in say, clightning (my\n\u003e original goal), without having to have the larger protobuf dependency.\n\u003e\n\u003e\nThat was exactly matejcik's point; you can easily write protobuf-compatible\nencoder/decoder for such simple structure in about an afternoon, if you\nneed. Or you can use existing protobuf parsers in matter of minute, if you\ndon't care about dependencies.\n\nAlso, many projects already have protobuf parsers, so it work in other way,\ntoo; you need BIP174 parser as extra dependency/library, although you\nalready use protobuf library (like Trezor device does). For needs of\nBIP174, the difference between ad-hoc format and protobuf is neglible, so\nit is a mistake to introduce yet another format.\n\nslush\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180626/b277b69a/attachment.html\u003e",
"sig": "374bc5179d8c1d388abc35339a981b1911034c857e5b21b26ee9b7fdbca1fb19ca025d07aa10a381eab6d53501c7ef76af29e075167324d987572a58c7c04535"
}