Bitcoin Core onion-grater profile

I started to learn onion-grater for the first time and I managed to make a profile for Bitcoin Core (tested on v0.17). It allows creating mainnet or testnet hidden service and discards private key to keep services ephemeral.

I’ve found it useful, hopefully others will to.


Awesome! Interested to have it shipped in Whonix by default? Please pull request here:

If so please consider add a comment on top naming you as maintainer with this with @qubenix Whonix user forum (or phabrictor) account.

1 Like

I realized that this profile can be simplified, but I’m wondering what you think about it @Patrick.

This is how I’ve been running. Is it too permissive like this?

- exe-paths:
    - '*'
    - '*'
    - '*'
      ## {{{ bitcoind onion service
      - pattern:     'NEW:(\S+) Port=(\S+),\S+)'
        replacement: 'NEW:{} Port={},{client-address}:{} Flags=DiscardPK'
      ## }}}
1 Like

No opinion yet. Since you maintain this, please do as you think this can be best maintained.

1 Like

I don’t see why this pattern is beneficial?

It is allowing services to be created to any port to be used instead of only 8333.

Ok, so the person wants to create a restest and testnet service, they would need to edit the config, or the config should use all the default ports, eg. 18333 for testnet.

But the default ports can be hardcoded, if a person uses a non default port, then they are already configuring the service diffferently.

My proposal is to implement all default ports patterns so the above can be avoided.

Of course the service is only reachable after port is opened on the firewall. But I think the control port should not allow all ports, only the whitelisted ports.

Seeing the examples
onion-grater/usr/share/doc/onion-grater-merger/examples at master · Whonix/onion-grater · GitHub

None is allowing all ports, only onionshare that has a huge range, but that is onionshare default to have that range and search for open ports.

1 Like
bitcoind -help

       Listen for connections on <port>. Nodes not using the default ports
       (default: 8333, testnet: 18333, signet: 38333, regtest: 18444)
       are unlikely to get incoming connections. Not relevant for I2P
       (see doc/

So the ports are: 8333, 18333, 38333, 18444

Any counter arguments to this?

1 Like

Not from me.

## Maintained by: <>


Revert simplify 40_bitcoind.yml · Whonix/onion-grater@9539d88 · GitHub?

Removed the maintained by qubenix, he has not been active since january and did not reply on time.

Did not put my name because I am using default configuration, there is no need to be dependent on me.

“Complicated” the ports to only use defaults instead of allowing any port to be used.

1 Like

wait a little bit before merging, I’m correcting something

1 Like

Good to go now.

Corrected the binding ports.

Bitcoind binds onions to: P2P_port + 1.

This is the request:

ADD_ONION NEW:ED25519-V3 Port=8333,

sudo netstat -tulnp | grep bitcoin

tcp        0      0  *               LISTEN      1564026/bitcoind    
tcp        0      0*               LISTEN      1564026/bitcoind    
tcp        0      0*               LISTEN      1564026/bitcoind    
tcp6       0      0 :::8333                 :::*                    LISTEN      1564026/bitcoind    
tcp6       0      0 ::1:8332                :::*                    LISTEN      1564026/bitcoind


  • RPC: 8332
  • P2P: 8333
  • bind onion p2p port: 8334

The virtual port is still 8333, but they use a different binding port for onion.

Just saying this so it is easier to debug next time.

I did not choose/configure these ports, this are the default ports.

1 Like

Thanks! Merged.

Ok, there is a problem with the current pattern.

Bitcoin onion-grater profile is only necessary if you want to listen=1 for incoming connections, this means relaying blocks on the p2p network.

Bitcoind does indeed start the onion binding port on This means that it isn’t reachable on $(qubesdb-read /qubes-ip):8334.

It would be reachable on that interface if the onion binding port was or the $(qubesdb-read /qubes-ip):8334, but the first option is better because it does not depend on knowing the qubes ip and updating it.

So if you want to listen for incoming connections, you need to set on the bitcoin.conf:

## although this is the default binding address:port,
## it is necessary to set it for it to listen on multiple addresses
## if not set, only would be binded and the default
## bind address and port would not be used

and opening external port 8334 on the workstation.

This also means that I need to update the onion-grater profile to overwrite the client add onion address with regex to match every address ( and should be modified to {client-address}). Something like (\S+), will test later.

You can test this is the case for example with nginx by listening on, only that address will be reachable and not the qubes ip and same port.

1 Like

(I don’t really understand how to print the link and not the title of the page with discourse…)

Just like apache only listening on, its traffic needs to be redirected to the Workstation listening interface. The thing is that by default nginx starts with (all interfaces).

And using sudo ncat -l 8334 -c 'ncat 8334' but that is just dumb and prone to mistakes of forgetting about it, better to set in the bitcoin.conf.

So yeah, changing the bitcoin.conf to bind= is necessary.

And I believe it is reasonable for bitcoind default to for onion connections and not, because it could leak server info, but not for Whonix, as it is isolated network with the Gateway.

1 Like

Used the same pattern as 40_wayhay.yml

1 Like

Note the first listening address 8333 is only necessary if you want applications to use that address. This is useful for qubes if you want to bind 8333 to another qube and have a pruned node on one qube and a full on another, without the need to set rpc for the other node, thus minimizing risks when possible.

So in the end, it is good to have 8333 always set because that is default bitcoind behavior that most applications will be expecting.

And the reason to set a different port for onion 8334 is:

  • default bitcoind configuration (except the address which needs to be changed to
  • correctly tagging incoming connections to that separate port as onion, thus making it very clear it is not coming from localhost. Useful for debugging, logs, verification etc.
1 Like

Makes sense.

(Avoid Oneboxing for Anchored Links + Created Improve oneboxing for anchored links - feature - Discourse Meta just now. To discuss this further, would be best to post there or create a new forum thread here.)