Report Review Meeting 2020-03-19

• all on track
• testing setup is in progress
  • talked to @devinbileck about testing strategies and he will create a testplan instance once required
  • binaries for all platforms and testing will be prepared
  • then, testing can commence
• I am confident that we can complete the proof-of-concept milestone by end of march.
• first tasks of the ship-it milestone are in progress already

from projects.

Everything is done for Milestone 2 except the "wait and see how it goes over time" part which will be concluded by the upcoming report.

Overall, it seems that v3 onion services did the project no harm whatsoever. I have been monitoring support and issues and there is not a single hint that something does not work - quite the contrary, it feels like support issues regarding tor connection issues and/or startup-issues for people using system tor have vanished. Will do a proper report as scheduled.

from projects.

Reflecting our call last week on this project, I've just applied the has:approval and has:budget labels with regard to the first (proof of concept) milestone. @freimair, please transition this issue to the In progress column if indeed work is underway (which I believe it is).

from projects.

Roger that, @freimair. Thanks for the update even in the absence of yesterday's planned (but cancelled) review meeting.

from projects.

Performance eval

TL;DR hidden service publishing time has dropped from around 33 seconds to <5 seconds, no significant changes otherwise

• 2 evaluations
  • use the monitor for "isolated" Tor measurements
  • Integration tests: start Bisq app to confirm findings

Recent changes to Bisq had an impact on the startup times already, so I decided to get the baseline manually instead of relying on the monitor.

Isolated Tor measurements

• to get an idea of what we can expect

Setup

• single PC, Arch linux, Kernel 5.5.13, Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, Samsung_SSD_970_EVO via M.2 interface
• devices under test (DUTs)
  • bisq-monitor with HSv2: compiled from v1.2.9 tag
  • bisq-monitor with HSv3: compiled from v1.2.9+bisq-network/bisq#4028
• DUTs have been copied to their own workspaces for isolation purposes
• metrics
  • tor startup time: time until Tor.getDefault() returns, includes installing tor to disk and starting it up
  • hidden service startup time: time between telling tor to publish a hidden service until the service has been confirmed by the tor network (in detail, time until the first tor relay announces that it added the hidden service to its "DNS" entries)
  • RTT
    • use a started tor to query an hidden service; ie. v3 onion address of whonix.org
    • 5 measurements each, calculate average, min, max, p25, p50, p75
• test runs alternate between v2 and v3

Results

• hidden service publishing times dropped from around 33 seconds to < 5 seconds
• no significant difference in Tor startup times
• no significant difference in RTT

Integration Tests

• to see if the results of the previous evaluation holds for the real thing.
• please note, measuring the startup-time of the Bisq app until ready is tricky
  • lots of external factors (seed node availability, age of local database, request size...)
  • no definite point of "bisq has started"
• hence, only limit measurements to the stuff we changed

Setup

• single PC, Arch linux, Kernel 5.5.13, Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, Samsung_SSD_970_EVO via M.2 interface
• devices under test (DUTs)
  • bisq-desktop with HSv2: compiled from v1.2.9 tag
  • bisq-desktop with HSv3: compiled from v1.2.9+bisq-network/bisq#4028
• DUTs have been copied to their own workspaces for isolation purposes
• test run script pseudocode
  • clean tor hidden service directory
  • fire up bisq-desktop
  • terminate it after 60 seconds
  • wait for ~10minutes
  • repeat
• metrics
  • tor startup time: extract from bisq.log.
  • hidden service startup time: extract from bisq.log.

################################################################
Tor started after 7182 ms. Start publishing hidden service.
################################################################

################################################################
Tor hidden service published after 1832 ms. Socked=HiddenServiceSocket[addr=kzafzl4nu5kb5vj6tn4esthv5hnnflo6kw6utnsq5hfdjfsmatbhacad.onion,port=9999]
################################################################ 

• run script for each DUT at the same time, over a couple of hours

Results

• hidden service publishing times dropped from around 33 seconds to < 5 seconds
• no significant difference in Tor startup times

from projects.

@freimair, could you give a status update about this project?

from projects.

Closing report on milestone: "Ship it"

There have been no reports that would indicate something not working properly or causing issues with Tor onion services v3. Quite the contrary, it seems like connection issues have gone down. It even seems that people have upgraded to v3 on their own - at least that is one explanation of the number of v3 hosts in the Bisq P2P network has reached the neighborhood of 40% already.

All in all, although we could and probably should have done it earlier, moving to Tor onion services v3 has been a success.

from projects.

Regarding the next steps for this project. I would only add the option to update to a new v3 address without taking the reputation over. I don't think it is worth the hassle to do this.

from projects.

Well, now that V2 is officially deprecated, migrating to V3 is required and we will need to force all users to migrate to V3 onions at some point in the future. Some kind of migration plan like:

• After X date, disable taking offers using V2 onions
• After Y date, disable making offers and all active offers using V2 onions
• After Z date, disable V2 onion entirely and force users to upgrade

from projects.

basically:

1. do we want to just move users to v3 once or
2. do we want to allow them to change their address at will?

both need similar preparations. in order to safely change the hidden service host users need to

• make sure they have no ongoing trades
• make sure they have no ongoing disputes
• (already fixed that a while ago bisq-network/bisq#4021) make sure they have no open offers

violating these preconditions will result in unrecoverable trade states and lost funds.

Once we hit wiz's third step, we need to do these checks automatically.

My suggestion is to reactivate this one year old PR: bisq-network/bisq#3044. It provides the tools to follow wiz's proposed timeline.

Your opinion?

from projects.

@ripcurlx @cbeams Can we close that project?

from projects.

Closing as complete given that we have in fact migrated to Tor v3. The milestone on allowing clients to upgrade was not completed, but it appears to be a separate concern at this point.

from projects.

I've also closed the associated project board at https://github.com/orgs/bisq-network/projects/15.

from projects.