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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC293DA0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Aug 2018 18:45:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com
[209.85.214.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4EF41148
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Aug 2018 18:45:58 +0000 (UTC)
Received: by mail-pl1-f172.google.com with SMTP id e11-v6so2695259plb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Aug 2018 11:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=m1zATk/6M08gtMyp0gv9oNO/UzZxsthJ8DFxpDEV6Qc=;
b=XyGW7PgXjkq+H+aQZn/U94KRAxZ569kWyNb+SzVF1zExsOwu/drjJztKR3N98hmiTn
CiNdBpVJX0RcR9E5Tge2yzDAhrQKjNjy85DXwemcaNt/k3AdG1fzvHEkWD7UZy2f7DMx
94khtFnWoY8Mkx2CbZpNFSkKs2DsgcXJfkluI9ApXfXfBrs2HRoL6dGF5h0mbRcjqBhF
JClVOJgH2mJrttt+6Spz8jYNrXr6KnWA44OmZkfIAE8szfsHMsBZbkMgC+S/EbK1mNM6
qFPf89+ZtUwqz+Zn3kQm01xJEdllxgwcPuD8nfoTi6iwwIeEfcq//1Oi69YgtXxolfFU
PkNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=m1zATk/6M08gtMyp0gv9oNO/UzZxsthJ8DFxpDEV6Qc=;
b=Fq2crP5SnAkNwDqg+zjl7ZmVnXSTJwlwFudm4G+dw1C7Zyhe2vd3FD7U+7TPtOugLO
hTyd8clkdyQDDicP65dNxkgOOTiPPRkH/sxG2l1My7ssEjZFltYCQDEL7K62HjcxV/3m
eL61lyST6XEeVqH/aYb2SFoFcc8FpogdbCnl29vuu+UIuhS2Xlm3GglRM9ESFhgNobyP
MdB6se0sc5mEyJgp2QZ/xkeXIZCQ3XrhsOqPKixsDqMAGbwlm1SROCsDrEJEyv8XH4Nr
cU1xSfrA2vDmvjYcpt12eegnO4MpjJjcV7rNAUn2x8fjW2DuesJsfYTvHbvmAlusO9Dl
nVxQ==
X-Gm-Message-State: APzg51Dhu1QhfllNzvgFj8mIWQoRzHBbEZcHIclEvFVE7diGlQvZNiNz
qrAiKl+xAWRTBhzkpjFZAKI8Xw==
X-Google-Smtp-Source: ANB0VdbHiUNu0XotA63oCAat4hEsmcUT+0ekVLeY99ObaYzSEqRguiknh6MiRUrSsYk9Ro8K/247Yw==
X-Received: by 2002:a17:902:2904:: with SMTP id
g4-v6mr6918776plb.70.1535568357672;
Wed, 29 Aug 2018 11:45:57 -0700 (PDT)
Received: from ?IPv6:2601:600:a080:16bb:f08e:ba0b:e616:2be?
([2601:600:a080:16bb:f08e:ba0b:e616:2be])
by smtp.gmail.com with ESMTPSA id
f67-v6sm20300720pfe.75.2018.08.29.11.45.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 29 Aug 2018 11:45:57 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>
Date: Wed, 29 Aug 2018 11:45:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <43C5B077-AFFB-4FCB-8D43-C56FBF835526@voskuil.org>
References: <CA+9w0-77oP3rmW37R6ty4fF_LhaOtQaL52yQUKynXEmZhQ9MeA@mail.gmail.com>
<8AE1517F-88FB-479D-AE89-993A5545D210@jonasschnelli.ch>
<758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org>
<4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_NONE 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: Thu, 30 Aug 2018 02:19:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Blockchain Group <shekharhiran@gmail.com>
Subject: Re: [bitcoin-dev] Building a Bitcoin API and query system.
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: Wed, 29 Aug 2018 18:45:58 -0000
You have created a straw man.
And light clients working against the P2P network (anonymous nodes) implies t=
hey are not fully validating, so you are contradicting yourself.
e
> On Aug 29, 2018, at 11:27, Jonas Schnelli <dev@jonasschnelli.ch> wrote:
>=20
>=20
>> The API implementation is not what is centralizing, nor is full indexatio=
n non-scalable. The centralization is in not running the API from a node und=
er your own control. This is of course implied by the comment, =E2=80=9Cwith=
out the need for syncing=E2=80=9D. In other words it is the deployment cost o=
f the node that is centralizing.
>=20
> IMO an API that serves non verifiable data is supporting centralised valid=
ation. The =E2=80=9EAPI" which supports one of the most important properties=
in Bitcoin =E2=80=93 the ability to self-validate =E2=80=93 is the data ava=
ilable via the p2p network.
>=20
>>=20
>> Yet if people relied only on bitcoind and never centralized services ther=
e would be *no* block explorers (and no secure light wallets), because it do=
es not provide remote query and does not fully index.
>>=20
>> Block explorers and light wallets are pretty useful, so presumably some A=
PI must provide these features (ideally with reduced deployment cost). That w=
ill either be centralized or decentralized services. As such it seems wise t=
o encourage the latter, as opposed to questioning whether there is any valid=
block explorer use case.
>=20
> Bitcoin-Core has all required features to partially =E2=80=9Eindex=E2=80=9C=
data (called the wallet) and provides them via the RPC API. If you don=E2=80=
=99t need to serve thousands of wallets (which smells after centralised vali=
dation), selective indexing (wallets) are the right choice. Also, if you hav=
e a proper light client architecture, you can use Bitcoin Core in pruned mod=
e (<10GB of data) to serve an endless amount of wallets (client/server mode,=
I guess that is what you are referring to with "light clients").
>=20
> I fail to see the use-cases where a fully index blockchain makes sense (th=
e only one I can come up with is instant backup recovery where the transacti=
on history needs to be preserved rather then recovering the UTXOs only).
>=20
> Also, the p2p protocol has built in light client support with BIP37 (bloom=
filters) and soon BIP158 will be available on the network which does allow p=
rivacy-preserving "light clients" in a way where no trusted layer is require=
d (client <-> p2p network rather then client <-> API provider <-> p2p networ=
k).
>=20
> I don=E2=80=99t want to advocate against a full-index blockexplorer-like A=
PI. I just think its important to define the use case and be aware of the co=
nsequences and downsides.
>=20
> /jonas
|
