Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Braydon Fuller <braydon@purse.io>]

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