Return-Path: 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: <202005051300.38836.luke@dashjr.org> In-Reply-To: From: Keagan McClelland Date: Fri, 8 May 2020 14:01:40 -0600 Message-ID: To: Braydon Fuller Content-Type: multipart/alternative; boundary="0000000000001f586805a528790c" X-Mailman-Approved-At: Fri, 08 May 2020 21:00:21 +0000 Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
> The RPC interface in Bitcoin Core, and others, i= s 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 intr= oduce risks, we could just use that and be done with it. But I'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't have full ability to administrate the node.

<= div>Perhaps I wasn't explicit in my previous note but what I mean is th= at there seems to be a demand for something in between 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.

Keagan

On Fri, May 8, 2020 at 1:51 PM Braydon Fuller <braydon@purse.io> wrote:
On 5/6/20 9:07 PM, Keagan McCl= elland 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 unrealisti= c to
> have everyone run their own node (fwiw, I don=E2=80=99t), there is sti= ll a trust
> model where you can pick your trusted source.
>
> This way you could have many light clients working off of a family nod= e,
> and the peer services could be limited to some sort of =E2=80=9Cauthen= ticated=E2=80=9D
> peers. Perhaps this is better accomplished over the RPC interface in C= ore,
> 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 amou= nt 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/5b24f6084ede92d0f493ff= 416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
[2]:
https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc3000= 11779b/src/query.rs#L284-L289


--0000000000001f586805a528790c--