kixunil / btc-rpc-proxy Goto Github PK

As explained by cdecker Bitcoind limits number of connections to 4. This proxy could help by queuing multiple connections.

Ideally have configurable connection pool of 1-4 connections.

It'd be nice to be able to reload the configuration without restarting whole program. Not sure how valuable it is, since btc-rpc-proxy starts very fast.

Would be useful to have a collection of profiles available somewhere, so users don't need to figure out the exact calls that need to be whitelisted for c-lightning, lnd, liquid, etc...

I have to temporarily downgrade to 0.21.2 and run with -deprecatedrpc=getpeerinfo_addnode -deprecatedrpc=whitelisted -deprecatedrpc=banscore , otherwise when btc-rpc-proxy receives json from getpeerinfo, it will fail to parse and won't be able to connect to peers to fetch missing blocks. There are many other fields added on rpc as well, but the missing ones cause it to fail.

Currently we race archive peers to fetch blocks that have been pruned. We should either cap the number of peers we do this for, or we should scale logarithmically or abandon parallel fetches altogether for an in-series fetch approach.

Recent versions of bitcoind expose a new RPC call: getblockfrompeer

Would it be an idea to use this function to retrieve the blocks instead of the custom code?

We should make extra sure the number of connections to bitcoind is limited because it can't accept many connections. We should probably block incoming requests if there are too many and round-robin them based on user name and peer.

Allowing changing UID after bind would allow us to run the proxy safely with privileged ports.

Implement reading of the cookie file

Having an option to broadcast all transactions over Tor would be a very useful feature since bitcoind doesn't support it directly and some clients don't support it. Having it in the proxy would make sure no transaction leaks over clearnet.

A global proxied_tx_brodcast option would be sufficient but perhaps doing it the same way as fetch_blocks - per-user AND global is better (consistent). We should also use RPC for testing if the TX would be accepted in the mempool before actually broacasting it.

@dr-bonez how hard do you think it'd be given that some required infrastructure (getting peers) is already implemented?

It'd be useful to proxy P2P connections too. At least two applications (electrs, NBXplorer) now use P2P to sync.

See also romanz/electrs#368 (comment)

1. running cargo run --release -- --conf btc_rpc_proxy.toml with:

bitcoind_user = "nathanael"
bitcoind_password = "[redacted]"
bind_address = "127.0.0.1"

[user.test]
password = "test"
allowed_calls = [
        "getmininginfo"
]

2. running bitcoin-cli -rpcuser=test -rpcpassword=test -rpcport=8331 getmininginfo:

error: Could not connect to the server 127.0.0.1:8331 (error code 1 - "EOF reached")

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.

the proxy is running cause netstat -na -f inet | grep 8331 gives me:

tcp          0      0  127.0.0.1.8331         *.*                    LISTEN

of course when i run bitcoin-cli -rpcuser=nathanael -rpcpassword=[redacted] getmininginfo it works (using the values inserted in the config file of btc-rpcy-proxy seen above)

has anyone an idea what i am doing wrong? something to do with openbsd?

interface files would make it easier to configure btc-rpc-proxy.

Hi. I tried running the proxy using the default ./btc_rpc_proxy.toml.
The only change I made was to update the Bitcoin RPC username and password.

I ran

cargo run --release

However, I received the error

Error: missing authentication information

Is this expected behaviour? It looks like the the config file is not being found....

More specifically, within src/create_state.rs, the varaibles config.bitcoind_user and config.bitcoind_password are both set to None in

    let auth = AuthSource::from_config(
        config.bitcoind_user,
        config.bitcoind_password,
        config.cookie_file,
    )?;

Not sure why that might be. As I said, I'm using the default btc_rpc_proxy.toml which is provided in the repo.

Thanks for the help!

The standback crate achieves what we do using old_rust more nicely and may simplify future development.

Do you see any issue with this idea @dr-bonez?

It is legal to call the Bitcoin Core JSON-RPC interface with named parameters, and in fact there are several examples of doing so in the API help.

However, all named parameter (i.e. "params":{}) calls fail with a 500 response code:

> {"jsonrpc":"2.0","method":"getnetworkinfo","params":{},"id":1}
< {"id":null,"error":{"code":-32700,"message":"invalid type: map, expected a sequence at line 1 column 52"},"result":null}

I was searching for a solution similar to btc-rpc-proxy to operate a pruned Bitcoin node alongside CLN.

Unfortunately, it seems that it no longer functions with the latest version of bitcoind (e.g. v25.0).

Since I'm not familiar with Rust, I opted to develop a Python script that accomplishes a similar task (although it lacks user permission management) and leverages the getblockfrompeer function to retrieve missing blocks.

You can find it here on github: pyBTCProxy