summaryrefslogtreecommitdiff
path: root/6c/43b53895b614eabfce78e6034df70cda2d4199
blob: 095ff9857290d61dd13c9f94386e59a6190dea57 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Return-Path: <jb55@jb55.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 35AB9B9E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 17 Feb 2019 18:00:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from jb55.com (jb55.com [45.79.91.128])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAB48782;
	Sun, 17 Feb 2019 18:00:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d= jb55.com;
	h=from:to:subject:date:message-id; s=default;
	bh=ldsvNyhscdur361y5npw9dCfOuYW2ZpxWtJEtsQsEYQ=;
	b=r3YTIBogAIh27Vht9Io5jnHHjjlOQkv0WuBOi0ftfgLJVhRt0lBzqQvCaX+5J9xhK0qcc9UW251mkIP9pcLt+UnihyPrSosFvtx3H+iAyuSuzP572JdI0jyq/SziHECIDYwz1z+/Oe1xFAysFY3Wyju6md0hpZMKD/30eIOSw2XprACAZchkb/GCXGzj/om8/PNoIewpVp0eNaXIm/W2DLEw/7Oayek0mgml+VjYPvv2FJ4SYxVG6HRZebngU5B87KZphulKUZBvcy5ScotFK3BiV+CqylzndO1aPmIVgFqJDQ0e75soB1AWAYo+bwGLxLBrzi6udszXjdo9Lz3miQ==
Received: from jb55.com (S010660e327dca171.vc.shawcable.net [24.84.152.187])
	by jb55.com (OpenSMTPD) with ESMTPSA id 46e9368c
	TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256
	verify=NO; Sun, 17 Feb 2019 18:00:33 +0000 (UTC)
From: William Casarin <jb55@jb55.com>
To: Pavol Rusnak <stick@satoshilabs.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Steven Roose <stevenroose@gmail.com>
In-Reply-To: <37f1c2f8-5c2e-0224-1557-f041f4b842ca@satoshilabs.com>
References: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com>
	<201902151518.50135.luke@dashjr.org>
	<37f1c2f8-5c2e-0224-1557-f041f4b842ca@satoshilabs.com>
Date: Sun, 17 Feb 2019 10:00:32 -0800
Message-ID: <87h8d2l2gv.fsf@jb55.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 17 Feb 2019 18:01:15 +0000
Subject: Re: [bitcoin-dev] NIH warning (was Re: [BIP Proposal] Simple
	Proof-of-Reserves Transactions)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 18:00:34 -0000

Pavol Rusnak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:

> We've been using Protocol buffers in Trezor since the beginning and so
> far it has proven to be as a great choice.
>
> While I agree it is always risky to add an exotic dependency to a
> software project, this one has lots of interoperable implementations in
> all possible languages you can name and it's very easy to work with.
>
> In the past, the Bitcoin dev community used the same arguments with
> regards to PSBT and we ended up with something that is almost as complex
> as protobuf, but it's de-facto proprietary to Bitcoin.
>
> Cherry on top is that PSBT format can be easily translated back and
> forth to PB making it even more obvious that PB should have been used in
> the first place.

One argument against Protobuf is that people are already moving away
from it in favor of FlatBuffers, Google's successor to Protobuf that
doesn't require serialization/deserialization of structures.

Do we really want to be chasing the latest serialization library fad
each time a new one comes out? I do think there is value in having
accessible serialization formats, which is why I think it's a good idea
to provide custom format to protobuf conversion tools.

This way users who prefer not to include large dependencies don't have
to, and protobuf users can just do an extra step to convert it into
their preferred format.

Cheers,
Will

-- 
https://jb55.com