path: root/38/5b35deedd77ddb3321ee7587c2d4d66f3eea87

Return-Path: <keagan.mcclelland@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 19FFBC07FF;
 Fri,  8 May 2020 20:02:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 0129926BE2;
 Fri,  8 May 2020 20:02:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0ymdiBeZRLRX; Fri,  8 May 2020 20:02:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com
 [209.85.208.66])
 by silver.osuosl.org (Postfix) with ESMTPS id AB83726F05;
 Fri,  8 May 2020 20:02:14 +0000 (UTC)
Received: by mail-ed1-f66.google.com with SMTP id y24so2300960edo.0;
 Fri, 08 May 2020 13:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Z+N7cbuZqP9jczejPiXHAoj06ZwouYiJfs1USYbBy5o=;
 b=rEc7ZQT/nqfcoBPTZOeME3mPfoaAnimvnqNInC4QUrCrqoNKvIOgTUP5Td2QG5JTKO
 IXNYNAuwgCEmnt2VSEbLuzbWquWfzQ1uPiXMpUrMLgex/R2GUm2cdhcv/WkktoHhH9Au
 NY2PzLI8w18zxfLxbBHrCHidzR4gjMYsYXNJkY9cuUCyC+eVimjqh16gqnlp0eYC558g
 do3YGU7dUgi6LPsNWT9Tr/K55RZW5icahK04i7HoG3SReWhQjeFgU6z/Q1h0WI9Mk4CE
 Yb1aMpBEqrq0HdySfvYQt+qPZIO+vCSseurJuTrTzOlqE8dVVLyyCW4zh8cBtyR5WNt2
 Q4QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Z+N7cbuZqP9jczejPiXHAoj06ZwouYiJfs1USYbBy5o=;
 b=e9lRGZinAEiUHOcPH+QBay1wzBsii+FUQsPj1/b0jHAPv/l0J16jFF7T7MCKX4PWO5
 si9yQpf6Yao6dWTEQzDYSwLkIVrQ8VQIju+Ce5w0ycm8miBvO4g4SSmRFGg4lXZ/eUii
 WlK5RTJgK+VLSS9tkpVeHxAglQOigwU5dgK7nOoBScnKWoPbfz5EJeDaL3ojr06XzM7h
 t5acNKqrS1mH8MIGIZzuK8VL1NbPxminiUTuw6VzK/DpzfUXdxDVXAfs8SmQnHRnqeXK
 D7Cfbtt3wB7FnR085Vy3Vggb2NKZIuVtZ+bzgOWMuLjliWLj9/1sQmy4Et1IdzRgdAgd
 MUcA==
X-Gm-Message-State: AGi0PuZsUja0Kp69LRT70cnnLQ73TwpeC7vT3HbsDzkMvdKp1q4CpAx6
 r+zNbrf3HwLjzAfDV43heWWRIxtO/gWcRXioWXI=
X-Google-Smtp-Source: APiQypL4rkxl1cTkVxA0BJ653A1/eL+nuVkAP3k9OYo9H3OFXmui3pvvxmTESc1PdgKLpvjgpavevAqB1frpTV1Zeeg=
X-Received: by 2002:a50:bb6b:: with SMTP id y98mr3599665ede.296.1588968132923; 
 Fri, 08 May 2020 13:02:12 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
 <CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com>
 <CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
 <CALZpt+Fmv3d-J69uyoJ5XB9hP78vqoS76Y2OVmHWqafkHTm5ZQ@mail.gmail.com>
 <CALeFGL3WRF11Q7d3Mea5nHS2da1atEfXArpdAfMfd1uJ+5f3JA@mail.gmail.com>
 <ecce23db-2622-b257-5a05-22a40aafd1e3@purse.io>
In-Reply-To: <ecce23db-2622-b257-5a05-22a40aafd1e3@purse.io>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Fri, 8 May 2020 14:01:40 -0600
Message-ID: <CALeFGL0vRM5o21oD0mrtPFnRCdRTUkyEv_nry3SQ4nvgyShGdA@mail.gmail.com>
To: Braydon Fuller <braydon@purse.io>
Content-Type: multipart/alternative; boundary="0000000000001f586805a528790c"
X-Mailman-Approved-At: Fri, 08 May 2020 21:00:21 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of
 onboarding millions of LN mobile clients
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Fri, 08 May 2020 20:02:18 -0000

--0000000000001f586805a528790c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks.

This is actually somewhat my point. If the RPC interface was good for this
and *didn't* introduce risks, we could just use that and be done with it.
But I'm finding there are many use cases that you want to have low cost
ways to serve peer services to people whom you have given explicit
permission, but they shouldn't have full ability to administrate the node.

Perhaps I wasn't explicit in my previous note but what I mean is that there
seems to be a demand for something *in between* a peer interface, and an
owner interface. I have little opinion as to whether this belongs in core
or not, I think there are much more experienced folks who can weight in on
that, but without something like this, you cannot limit your exposure for
serving something like bip157 filters without removing your own ability to
make use of some of those same services.

Keagan

On Fri, May 8, 2020 at 1:51 PM Braydon Fuller <braydon@purse.io> wrote:

> On 5/6/20 9:07 PM, Keagan McClelland wrote:
>
> > I think that one of the solutions here is to have light clients choose
> > their full node tethers explicitly. Even if you think it is unrealistic
> to
> > have everyone run their own node (fwiw, I don=E2=80=99t), there is stil=
l a trust
> > model where you can pick your trusted source.
> >
> > This way you could have many light clients working off of a family node=
,
> > and the peer services could be limited to some sort of =E2=80=9Cauthent=
icated=E2=80=9D
> > peers. Perhaps this is better accomplished over the RPC interface in
> Core,
> > but the idea is to have some sort of peer service model between =E2=80=
=9Cfull
> > public=E2=80=9D and =E2=80=9Cowner only=E2=80=9D. This limits the amoun=
t of costs that can be
> > properly externalized, without exposing risk of consensus capture by
> > economically weighty institutions.
>
> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks. For example the `gettxoutsetinfo` can start a very
> intensive CPU and disk I/O task. There are several others, for example:
> `stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
> full raw blocks isn't very efficient with JSON. Electrum servers (e.g
> electrs) for example read blocks from disk instead and use the RPC
> interface to sync headers. Though, Electrum servers also have a risk of
> DoS with addresses that have many transactions, see the `--txid-limit`
> option [2].
>
> [1]:
>
> https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245=
140b2c1/src/rpc/blockchain.cpp#L954-L956
> [2]:
>
> https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc3000=
11779b/src/query.rs#L284-L289
>
>
>

--0000000000001f586805a528790c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; The RPC interface in Bitcoin Core, and others, i=
s not great for this<br>
&gt; because it exposes a lot of functionality that isn&#39;t necessary and=
<br>
&gt; introduces risks. </div><div><br></div><div>This is actually somewhat =
my point. If the RPC interface was good for this and <i>didn&#39;t</i> intr=
oduce risks, we could just use that and be done with it. But I&#39;m findin=
g there are many use cases that you want to have low cost ways to serve pee=
r services to people whom you have given explicit permission, but they shou=
ldn&#39;t have full ability to administrate the node.</div><div><br></div><=
div>Perhaps I wasn&#39;t explicit in my previous note but what I mean is th=
at there seems to be a demand for something <i>in between</i> a peer interf=
ace, and an owner interface. I have little opinion as to whether this belon=
gs in core or not, I think there are much more experienced folks who can we=
ight in on that, but without something like this, you cannot limit your exp=
osure for serving something like bip157 filters without removing your own a=
bility to make use of some of those same services.</div><div><br></div><div=
>Keagan<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, May 8, 2020 at 1:51 PM Braydon Fuller &lt;<a href=
=3D"mailto:braydon@purse.io">braydon@purse.io</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">On 5/6/20 9:07 PM, Keagan McCl=
elland wrote:<br>
<br>
&gt; I think that one of the solutions here is to have light clients choose=
<br>
&gt; their full node tethers explicitly. Even if you think it is unrealisti=
c to<br>
&gt; have everyone run their own node (fwiw, I don=E2=80=99t), there is sti=
ll a trust<br>
&gt; model where you can pick your trusted source.<br>
&gt;<br>
&gt; This way you could have many light clients working off of a family nod=
e,<br>
&gt; and the peer services could be limited to some sort of =E2=80=9Cauthen=
ticated=E2=80=9D<br>
&gt; peers. Perhaps this is better accomplished over the RPC interface in C=
ore,<br>
&gt; but the idea is to have some sort of peer service model between =E2=80=
=9Cfull<br>
&gt; public=E2=80=9D and =E2=80=9Cowner only=E2=80=9D. This limits the amou=
nt of costs that can be<br>
&gt; properly externalized, without exposing risk of consensus capture by<b=
r>
&gt; economically weighty institutions.<br>
<br>
The RPC interface in Bitcoin Core, and others, is not great for this<br>
because it exposes a lot of functionality that isn&#39;t necessary and<br>
introduces risks. For example the `gettxoutsetinfo` can start a very<br>
intensive CPU and disk I/O task. There are several others, for example:<br>
`stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading<br=
>
full raw blocks isn&#39;t very efficient with JSON. Electrum servers (e.g<b=
r>
electrs) for example read blocks from disk instead and use the RPC<br>
interface to sync headers. Though, Electrum servers also have a risk of<br>
DoS with addresses that have many transactions, see the `--txid-limit`<br>
option [2].<br>
<br>
[1]:<br>
<a href=3D"https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff41=
6b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956" rel=3D"noreferrer" targe=
t=3D"_blank">https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff=
416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956</a><br>
[2]:<br>
<a href=3D"https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866=
550dc300011779b/src/query.rs#L284-L289" rel=3D"noreferrer" target=3D"_blank=
">https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc3000=
11779b/src/query.rs#L284-L289</a><br>
<br>
<br>
</blockquote></div>

--0000000000001f586805a528790c--