Bisq - The P2P Exchange Network

Did you still use Whonix gateway?

Hi @Patrick , I’ve set up about 100 onion services, and that skills is not helpful to understand how to use Bisq with Whonix.

I continue to be unable to use Bisq on Whonix, despite Bisq being a supported program for Whonix. This is recent, and other users continue to have this issue also.

It’s possible that a recent Bisq update has made the old instructions incomplete or incorrect, and without any information on how to debug, it’s a matter of reading raw packets. Not so easy. It would be much more helpful if you or another dev could answer @plasticpalmarvin, specifically when it comes to Whonix-specific things like onion-grater-add. The word “debug” does not appear anywhere on the onion-grater-add man page so saying that he should run in debug mode is not very helpful. If you know how to run onion-grater-mode in debug mode, it would be very helpful to share that.

But it is not clear that debugging onion-grater-add would help. How would it? I think this only adds the config file, but does not tell you anything about the connectivity status to the downstream whonix workstation that has the onion service (Bisq) on it.

Also, the instructions on the Whonix wiki are poorly formatted, as in a CSS or HTML problem, and it makes it very difficult to read the instructions. How recently has the Whonix team tested Bisq and these instructions?

And it is not clear if onion-grater-add should be run on the gateway only once, or every time.

What I have a feeling is that 40_bisq.yml is not current, for newer versions of Bisq circa autumn 2022. I would like to help you debug this, but I am at the limit of what I am able to test without more input from you or another developer. Please tell me how I can help.

I hope that’s not needed… And there’s a good chance it’s not.

onion-grater-add probably does not need debugging. It’s a simple script, helper utility that works for other onion-grater profiles.

What would need debugging the bisq onion-grater profile.

If/when that has happened, was/will be mentioned in this forum thread.

Generally, Principle of least astonishment - Wikipedia is the goal. Should something user unfriendly / complicated / weird be required (such as if there was a case where setup command that needs to be re-run every time), then this will be mentioned. Otherwise, default assumption would be the user friendly situation, i.e. following documentation as is, only needing to run the command once being required.

Quite likely.

Yes, help needed and wanted for this one.

I don’t know what you mean. Please report this in a separate forum thread and perhaps a screenshot would be helpful.

Great. I followed the instructions you linked to and I edited …/50_user.conf. I restarted daemons and onion-grater, and I am currently running with journalctl -f -i onion-grater.

I don’t know what I should expect to see here, but I am excited to learn. This is what you mean by debug, yes?

Something that can help: do you have any ideas for how I can test the connection to the Bisq node? Something similar to testing an SMTP server with openssl_connect -s_client? I know you are not a Bisq dev and I have asked them but it was worth asking you also. This could help me test onion-grater and the tor connection directly ( such as on localhost:9999)

Oh shit. So Whonix has never tested Bisq? Whonix devs do not know if 40_bisq is current? I know the Bisq devs do not know.

That makes sense, but let me ask: how does this work in Whonix-gateway on Qubes where the sys-whonix takes itself from a template every time?

Also, if a person was not thinking clearly and he ran onion-grater-add 40_bisq more than one time, will this cause a problem? Should he re-create the whonix-gateway?

Another question. Where does onion-grater-add copy 40_bisq data to? What file/directory should I be checking to make sure that the data copied over, and only copied over once? Or does this load into RAM?

Okay here is my first observation:

The whonix gateway, under sudo journalctl -f -u onion-grater I see this:

Jan 31 11:03:38 host onion-grater[3029]: Tor control port filter started, listening on 10.137.0.127:9051

Why is it listening on 10.137.0.127:9051? The Bisq node on the whonix workstation is listed as port 9999. Does 40_bisq translate from 9051 to 9999? I do not see this in github (/Whonix/onion-grater/blob/master/usr/share/doc/onion-grater-merger/examples/40_bisq.yml)

(On the other hand, netstat -tupnl does not show any activity for port 9999 on the workstation. Hm. Anyway, it will help to have this question answered.

Second observation:

When I run a second Bisq instance and I try to take the offer that I make in the first Whonix workstation (the one where the Whonix gateway is on debut), I do not see any messages at all in the debug console.

But if someone (me) is connecting to Tor address in the Bisq instance, inside the Whonix Workstation, running on the Whonix Gateway, then… shouldn’t I see some evidence that it is trying to connect?

The second Bisq instance says that

Warning
You cannot take that offer because the maker is offline.

This is the error that everyone is getting recently using Bisq on Whonix. I have the debug window open (explained above), so what more can I do to help debug this?

Yes.

No.

It was tested a long time ago. See this forum thread. I didn’t re-read all posts. But if you want to pick this up, please read the full forum thread.

Folder /usr/local/etc/onion-grater-merger.d/ is persistent even in an App Qube because it’s in /usr/local. See Qubes-Whonix ™ Overview chapter Qubes Persistence in Whonix wiki.

No. The script is idempotent.

No. That would be Microsoft Windows style “re-install Windows”. Hopefully on Linux such crude fixes aren’t required.

Best to look at the short source code of /usr/bin/onion-grater-add and/or run the script in verbose mode (xtrace).

sudo bash -x /usr/bin/onion-grater-add 40_bisq

It creates a symlink to /usr/local/etc/onion-grater-merger.d/.

/usr/local/etc/onion-grater-merger.d/

Also onion-grater journal log will show which profiles are load.

The actual file created by onion-grater-merger which will be consumed eventually by onion-grater is

/etc/onion-grater.d/30_autogenerated.yml

No. The kernel will eventually but that’s very low level and very most likely not something to worry about.

That’s Qubes-Whonix-Gateway internal IP. Reachable from Whonix-Workstation.

This most likely won’t be the issue. onion-grater is generally functional. Whonix-Workstation 127.0.0.1 is redirected to Whonix-Gateway. (anon-ws-disable-stacked-tor)

onion-grater, a Tor Control Port Filter Proxy - filtering dangerous Tor Control Port commands - Design Documentation - Whonix chapter Connect to onion-grater from Whonix-Workstation ™ in Whonix wiki

Tor ControlPort

That’s most likely different. That’s the Onion Service port.

No. And it doesn’t need to because the one is Tor ControlPort the other is the Onion Service port.

Try something simpler first. Some other application that uses the Tor control protocol. Something that isn’t complex or broken.

Inside Whonix-Workstation:

tor-ctrl signal NEWNYM

That Tor control protocol command should then be visible on Whonix-Gateway with onion-grater in debug mode.

You would probably need to learn a few components beforehand.

  • Setting up a “normal” Onion Service as per Onion Services - Whonix
  • Interacting with the Tor control protocol generally.
  • Opening a Tor Onion Service using add_onion using Tor control protocol. (Maybe enough if understanding this in theory.)
  • Interacting with the Tor from Whonix-Gateway.
  • Interacting with the Tor from Whonix-Workstation.
  • onion-grater debug mode, log watching for functional things.

On which IP / port is Bisq listening inside Whonix-Workstation?

Does Bisq still use the Tor control protocol to create its Onion Service?

Does Bisq require an Onion Service nowadays?

1 Like

No, with whonix-gw as network qube the inbound connection do not get through. As inbound connections are required for Bisq to run properly, I had to completely abandon Whonix.

I’d love to see Bisq work on Whonix, but the instructions on the Whonix Wiki simply don’t work.

Yeah those instructions suck in every way. That’s why we’re debugging this. And it used to work last year, so something changed and so maybe it can be fixed.

Any progress?

1 Like

No. And none should be expected, unless contributed.

1 Like

bisq signing key recently changed. I couldn’t find any explanation for the change.

An anonymous wiki edit was suggested to update the signing key.
Bisq: Difference between revisions - Whonix

Related issue:

(Contains links to various pull requests related to Tor integration.)


Bisq 2 bug report:

1 Like
1 Like

Might be fixed at least for Bisq version 1.x.

The Bisq wiki page has been recently updated. (changes: Bisq: Difference between revisions - Whonix)

See the wiki page here:

  • Version 1.9.14: has been reported to be functional.
  • Version 1.9.15: might be broken but I only got 1 report for that. Still worth trying.
  • Version 2.x: Not worth bothering with until/if above tickets are updated, unless you are a developer.

Please test.

1 Like

Seems to be broken: [StartTor] ERRORbisq.network.p2p.network.RunningTor: Couldn't connect to Tor. net.freehaven.tor.control.TorControlError: Error reply: Command filtered

Error message may indicate an Onion Grater problem. Would require further testing to see what command is being sent.

Did some further digging.

This is the command being sent to Tor control port GETINFO status/bootstrap-phase

Then reply received: 510 Command filtered

That command happens after a bit of other back and forth control commands.

1 Like
1 Like

Seems to have done the trick. I attempted something like this but did not add the response pattern and it hung because of that by the looks of it.

1 Like

The fixed onion-grater profile is now available in all Whonix repositories.