Transition from Tor HS v2 to Tor HS v3

[freimair]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

TL;DR

The Tor binary is going to make its new and shiny hidden service infrastructure the default in the near future (months). I propose to make Bisq ready for the new hidden service address format ASAP. When the new infrastructure becomes the default, new users will use the new infrastructure, legacy users will use the old infrastructure - Bisq clients will be able to connect to both infrastructures. Afterwards, we can talk about migrating from old to new.

Introduction

The Onion Router (TOR) offers a version 3 of its hidden service technology (HSv3) for quite some time now. Bisq, until now, held onto HSv2 because the Tor devs themselves did not consider HSv3 as "BEST", at least until Tor v0.3.5.1. However, a tiny line of code prevented HSv3 to actually become the expected default back then, so we spent our time working on other Bisq issues. Now, motivated by an upcoming tor 0.4.2 and bisq-network/bisq#2873 it is time to seriously think about HSv3 and how Bisq can make a transition from HSv2 to HSv3 without segmenting the Bisq network to a point beyond usability.

Tor Hidden Service Versions

• non-functional differences source
  • HSv3 has improves security/privacy
  • HSv3 features new introduction/rendezvous protocol (may boost performance - source needed!)
  • HSv3 features a cleaner codebase
• technical differences source
  • 56 char address HSv3 vs. 16 char address in HSv2
  • HSv3 is based on SHA3 and EC cryptography, HSv2 is based on SHA1 and RSA cryptography (in words, SHA1 is on the brink of being broken, and Elliptic Curve Cryptography (ECC) is more futureproof AND faster than the old and trusty RSA)

Impact on the Bisq Network

• Might have a positive performance impact on the Bisq network. Less timeouts, smaller RTT, more stable services, ...
• tor can talk to HSv2 and HSv3 alike, no issue here

However,

• Bisq nodes using HSv2 cannot talk to upcoming Bisq clients using HSv3, hence, network segmentation (parsing, display, ...)
• Peer requests may have to distinguish whether the asker knows v3 or not
• The HS address is used as kind of an ID of the trader, if we migrate to v3 addresses, gained trust level/reputation/witness of how long a trader has been active/whatever you want to call it is lost (except if we find a way to preserve that)

Strategy Brainstorming

• force users to "upgrade" their ID
  • +: clean cut
  • -: transition to a new address is only possible when no more trades are active
  • -: reputation is lost
• same as above, but wait for a specific date before starting the upgrade process (suggested by @ManfredKarrer)
• same as above but tell others that oldID = newID, so reputation is kept
  • +: clean cut
  • -: transition to a new address is only possible when no more trades are active
• hard fork, align with e.g. the new trade protocol. Leave the old network as is, a new client of version X only supports HSv3 addresses (suggested by @ManfredKarrer)
  • what do with ongoing trades and disputes?
• use 2 hidden services:
  • the old one is kept until all trades and disputes are done
  • the new one is created as soon as a specific date arrives
  • the new one is used for new offers
  • offers are republished with the new address

Roadmap

• make sure Bisq clients can talk to legacy HSv2 and HSv3 alike
  • if there are issues (in onion parsing for example) make appropriate changes
  • reduce clients that cannot talk to HSv3 by releasing the fix before HSv3 becomes a thing
  • only afterwards, release the HSv3 feature for Bisq
  • doing so would leave legacy users/clients at HSv2, new users would use HSv3. Given most of the clients get updated beforehand, there will be no break in operations
• update tor when it has HSv3 as default
• evaluate performance and see if HSv3 makes a difference for our use case
• make the "renew" address feature a thing (via Backup, restore and create a new onion address via GUI bisq#3044)
• see if we really need to transfer reputation (if legacy users want to keep their reputation, they may just stay with HSv2) because crafting such a feature requires quite a bit of effort (> 15000 USD I guess)

[ManfredKarrer]

Another strategy could be to implement it but keep it inacive until an activation date. So we get time that most users have updated. After activation date we can set the min. version for trading to the version when it was shipped, so old clients are forced to update. Might still cause some confusion/friction but should be acceptable. Maybe some seed nodes need to be running a while with old version to ensure those old users get their app started up.

[mpolavieja]

I think that account age (reputation) should always be kept no matter the strategy. Losing account age could be quite frustrating for fiat pairs, and it would impact liquidity and activity for at least a couple of months.

[freimair]

@ManfredKarrer what you are suggesting is that after a specific date users are asked/forced to update their ID? Or the software does this on its own as soon as no more trades are active? can we assume that each user has a time frame were no trade is active?

@mpolavieja agreed

[ManfredKarrer]

@mpolavieja Account age witness should not be affected by that, but the local reputation (nr. of trades you had with a user) as that is based on the onion address. To introduce a new keypair for representing that local reputation would be better anyway as that would allow to decouple renewal of onion addresses with the local reputation.
From the last (and only) hardfork I was surprised that people complained a lot about the loss of that local reputation so it seems it is an important feature to many traders. There might be some solutions to convert that over by introducing a new fields carrying the old onion address...

[ManfredKarrer]

@freimair That must happen when the user has no open trades or disputes. Open offers will become invalid. But there are some complexity to handle that all and it seems more difficult as it looks first....
I would suggest to try to syn that when a hardfork is justifies (e.g. new trade protocol). That would reduce risk as well as then there are 2 networks and if the new would have a fatal flaw the old network still works. So both risks from new trade protocol and onion change would be contained by that.

[freimair]

@ManfredKarrer

• do we have a strategy on how to transition to the new trade protocol? the new trade protocol for me sounds as simple as adding a new capability. Old trades are completed with the old protocol, new trades (given both parties know the new one) are performed with the new protocol.
• an open offer can be taken down and republished with the new HSv3 address. Quite the same as closing the client an starting the client later.
  • is the offer cryptographically bound to the ID?
  • are there any fees lost by changing the ID?

[ManfredKarrer]

@freimair

• No, we will not support both trade protocols as that would cause too much dev effort and code bloat. So when releasing it users cannot trad between old and new versions. I have not thought about details of the transition. If offers do not change from data structure those get updated once the user has updated. Otherwise we need a way to convert the offers to the new version.
• Yes the offer can be republished with the new onion. No fees lost and no restriction I am aware of.

[freimair]

ad new trade protocol: but this hard fork is not going to have any affect on the reputation as the IDs remain the same?

[mpolavieja]

Hi @freimair, how is the status of this proposal? Should I label it as approved?

[freimair]

Hi @mpolavieja, ahm the stuff is still WIP as I do not see a clear way as of now. However, the first step is getting reviewed and afterwards, I will see if I can update this proposal (since tor will eventually update their default HS version to v3 soon)

[mpolavieja]

Hi @freimair, any update for this proposal?

[freimair]

@mpolavieja I just updated the proposal to its final state and asked for thumbs up/down in the keybase proposal channel. Sorry for the long wait and uncertainty.

[freimair]

Update

it seems like the Bisq application will work with v3 peers without any changes. Further testing is needed of course but chances are high that we do not need to do anything.

That in turn means that there might not even be any network segmentation. Hooray.

[ripcurlx]

@freimair Can you prepare a PR for review by multiple contributors (different OSes) so we can give it a good test run for v1.2.7?

[freimair]

@freimair Can you prepare a PR for review by multiple contributors (different OSes) so we can give it a good test run for v1.2.7?

It seems that we do not have to change anything to get the v3 compatibility. The stuff is already shipped - so nothing to deliver, nothing to test for others.

[freimair]

Performance evaluation results

see bisq-network/projects#23 (comment)

[MwithM]

Closed as: approved