On 5/8/20 1:01 PM, Keagan McClelland wrote: >> 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.
An idea I was thinking about was having three ports for a full node: 1) Consensus bitcoin protocol. This is the existing peer-to-peer protocol without additional services. 2) Wallet services protocol. Adds additional functionality for wallets. For example bloom filtering, compact block filters, and potentially output and address indexes for electrum-like support. It's nearly identical to the consensus peer-to-peer protocol, supporting the same wire format. As it's on another port, various middleware could be added to support various authentication and transports. 3) Control interface. This is the existing JSON-RPC interface, without all wallet related RPC methods. _______________________________________________ bitcoin-dev mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev