> 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’t), there is still 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 “authenticated”
> 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 “full
> public” and “owner only”. This limits the amount 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/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
[2]:
https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289