-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transition from Tor HS v2 to Tor HS v3 #101
Comments
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. |
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. |
@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 |
@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. |
@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.... |
|
|
ad new trade protocol: but this hard fork is not going to have any affect on the reputation as the IDs remain the same? |
Hi @freimair, how is the status of this proposal? Should I label it as approved? |
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) |
Hi @freimair, any update for this proposal? |
@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. |
Updateit 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. |
@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. |
Performance evaluation results |
Closed as: approved |
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
Impact on the Bisq Network
However,
Strategy Brainstorming
Roadmap
The text was updated successfully, but these errors were encountered: