Topic: Abstracting several geographically distant nodes with a proxy node (Read 120 times)

This is confusing. Are you saying that you are already running a node? Why would you not query the node you already have running?

Yes, nodes will send you existing blocks. However if you try to use other nodes as an API to find transactions, the number of nodes that are willing to provide "new" nodes historical blocks will go down. The cost of sending data is more expensive than the cost of receiving data (most cloud service providers do not charge for data downloaded, but do charge for data uploaded).

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 this is your goal, I would suggest that you put all transactions and blocks in a SQL database and search accordingly. This is assuming that you are searching for something that is not supported by a RPC command, and if that was the case, you should just use a full node that has the entire blockchain downloaded.

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.

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.


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.


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).

You can only make RPC commands to nodes that you control. The documentation 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.

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#

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.