rich1.0Braydon Fuller [ARCHIVE] (npub1fx…xxtaa)https://nostr.ae/npub1fx2eyw7avet7dut0slazcehwvrrlhjp2u9jc9zd92l7nexpxeahs4xxtaanjumphttps://nostr.ae📅 Original date posted:2020-05-08 📝 Original message: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