Braydon Fuller [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-08 📝 Original message: On 5/8/20 1:01 PM, Keagan ...
📅 Original date posted:2020-05-08
📝 Original message:
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.
📝 Original message:
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.