{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-08\n📝 Original message:\u003e The RPC interface in Bitcoin Core, and others, is not great for this\n\u003e because it exposes a lot of functionality that isn't necessary and\n\u003e introduces risks.\n\nThis is actually somewhat my point. If the RPC interface was good for this\nand *didn't* introduce risks, we could just use that and be done with it.\nBut I'm finding there are many use cases that you want to have low cost\nways to serve peer services to people whom you have given explicit\npermission, but they shouldn't have full ability to administrate the node.\n\nPerhaps I wasn't explicit in my previous note but what I mean is that there\nseems to be a demand for something *in between* a peer interface, and an\nowner interface. I have little opinion as to whether this belongs in core\nor not, I think there are much more experienced folks who can weight in on\nthat, but without something like this, you cannot limit your exposure for\nserving something like bip157 filters without removing your own ability to\nmake use of some of those same services.\n\nKeagan\n\nOn Fri, May 8, 2020 at 1:51 PM Braydon Fuller \u003cbraydon at purse.io\u003e wrote:\n\n\u003e On 5/6/20 9:07 PM, Keagan McClelland wrote:\n\u003e\n\u003e \u003e I think that one of the solutions here is to have light clients choose\n\u003e \u003e their full node tethers explicitly. Even if you think it is unrealistic\n\u003e to\n\u003e \u003e have everyone run their own node (fwiw, I don’t), there is still a trust\n\u003e \u003e model where you can pick your trusted source.\n\u003e \u003e\n\u003e \u003e This way you could have many light clients working off of a family node,\n\u003e \u003e and the peer services could be limited to some sort of “authenticated”\n\u003e \u003e peers. Perhaps this is better accomplished over the RPC interface in\n\u003e Core,\n\u003e \u003e but the idea is to have some sort of peer service model between “full\n\u003e \u003e public” and “owner only”. This limits the amount of costs that can be\n\u003e \u003e properly externalized, without exposing risk of consensus capture by\n\u003e \u003e economically weighty institutions.\n\u003e\n\u003e The RPC interface in Bitcoin Core, and others, is not great for this\n\u003e because it exposes a lot of functionality that isn't necessary and\n\u003e introduces risks. For example the `gettxoutsetinfo` can start a very\n\u003e intensive CPU and disk I/O task. There are several others, for example:\n\u003e `stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading\n\u003e full raw blocks isn't very efficient with JSON. Electrum servers (e.g\n\u003e electrs) for example read blocks from disk instead and use the RPC\n\u003e interface to sync headers. Though, Electrum servers also have a risk of\n\u003e DoS with addresses that have many transactions, see the `--txid-limit`\n\u003e option [2].\n\u003e\n\u003e [1]:\n\u003e\n\u003e https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956\n\u003e [2]:\n\u003e\n\u003e https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200508/dd8331af/attachment-0001.html\u003e"}