Title: Abstracting several geographically distant nodes with a proxy node Post by: NotATether on February 02, 2022, 11:56:00 AM It has come to my mind recently that to make use of the Bitcoin Core RPC protocol, you need to have a node running somewhere that you can query.
I was thinking, maybe it is possible to set up a proxy node facing a domain or IP address that scrapes the peer list from other nodes and keeps them in one big list, checking periodically, like every hour, if the nodes are still running by sending some *info RPC. This is not intended to replace the decentralized network of nodes, just augmenting it by enabling people/corporations to run well-known proxy nodes for sending RPC calls to (wallet RPC calls would not be supported, as would "shutdown"). It would require virtually no resources to run, and would fit on a small VPS system. Title: Re: Abstracting several geographically distant nodes with a proxy node Post by: JRamos on February 02, 2022, 12:05:06 PM If you are a corporation/individual you should run your own bitcoin node as they do not require trust.
But if you want to play with bitcoin rpc without installing a node you can use this page https://chainquery.com/bitcoin-cli# (https://chainquery.com/bitcoin-cli#) Title: Re: Abstracting several geographically distant nodes with a proxy node Post by: Quickseller on February 02, 2022, 10:40:33 PM You can only make RPC commands to nodes that you control. The documentation (https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf) on how to setup RPC configuration explicitly says to keep the RPC credentials confidential.
I don't believe that nodes will ever give their peer list to their peers, at least not intentionally (assuming there are no flaws in the node implementation). If you want to run a (very) light node that connects to other nodes, the only real information you can obtain is historical blocks (by block number) and newly broadcast transactions. I don't believe a peer node will ever provide information contained in most RPC commands. If you are wanting to create a new implementation of core that allows an arbitrary user to obtain information that you might get from RPC commands -- the only information I can think of would be information about address balances and transactions -- you could connect to an electrum server to get this information. Title: Re: Abstracting several geographically distant nodes with a proxy node Post by: NotATether on February 03, 2022, 06:39:53 AM I don't believe that nodes will ever give their peer list to their peers, at least not intentionally (assuming there are no flaws in the node implementation). I meant, that a person running this proxy node would also get the peer information from a node they are running simultaneously somewhere else, and the peers are collected organically via peer discovery. Then the proxy nodes can be gathered into some list online, and a load balancer can be placed in front of the various proxy nodes to distribute request traffic across proxy nodes, and hence, geographically distant full nodes. Only load balancer costs will be incurred in that case, while a rate limiter can be set to avoid being bombarded with requests and paying for too much bandwidth. If you want to run a (very) light node that connects to other nodes, the only real information you can obtain is historical blocks (by block number) and newly broadcast transactions. I don't believe a peer node will ever provide information contained in most RPC commands. Historical transactions and blocks (assuming the proxy node impl can deduce the nodes running with -txindex using trial and error). But then again, it's much better than paying for an API token to fetch the equivalent data. If you are wanting to create a new implementation of core that allows an arbitrary user to obtain information that you might get from RPC commands -- the only information I can think of would be information about address balances and transactions -- you could connect to an electrum server to get this information. I know Electrum API is always a thing but that can't fetch blocks, and it can only get transaction history of an address you put inside your wallet. It's very cumbersome if you just want to analyze a group of transactions with different features (source address not being one of them). Title: Re: Abstracting several geographically distant nodes with a proxy node Post by: Quickseller on February 06, 2022, 09:15:34 PM I don't believe that nodes will ever give their peer list to their peers, at least not intentionally (assuming there are no flaws in the node implementation). I meant, that a person running this proxy node would also get the peer information from a node they are running simultaneously somewhere else, and the peers are collected organically via peer discovery. Then the proxy nodes can be gathered into some list online, and a load balancer can be placed in front of the various proxy nodes to distribute request traffic across proxy nodes, and hence, geographically distant full nodes. Only load balancer costs will be incurred in that case, while a rate limiter can be set to avoid being bombarded with requests and paying for too much bandwidth. If you want to run a (very) light node that connects to other nodes, the only real information you can obtain is historical blocks (by block number) and newly broadcast transactions. I don't believe a peer node will ever provide information contained in most RPC commands. Historical transactions and blocks (assuming the proxy node impl can deduce the nodes running with -txindex using trial and error). But then again, it's much better than paying for an API token to fetch the equivalent data. Also, trying to find a particular transaction or a particular block will be inefficient this way if you don't know which block you are looking for. If you are wanting to create a new implementation of core that allows an arbitrary user to obtain information that you might get from RPC commands -- the only information I can think of would be information about address balances and transactions -- you could connect to an electrum server to get this information. I know Electrum API is always a thing but that can't fetch blocks, and it can only get transaction history of an address you put inside your wallet. It's very cumbersome if you just want to analyze a group of transactions with different features (source address not being one of them). If you are searching for transactions based on some criteria, and are making multiple queries, you will ultimately have to access the same block multiple times. The time it takes to query a block from a peer is going to be much longer than the time to query a block locally. So you will see negative performance issues if you don't have the blockchain stored on the machine (or accessible via storage bucket) running the queries. |