diff options
| -rw-r--r-- | changes/bug8965 | 3 | ||||
| -rw-r--r-- | doc/TODO | 3 | ||||
| -rw-r--r-- | doc/contrib/authority-policy.txt | 89 | ||||
| -rw-r--r-- | doc/contrib/tor-rpm-creation.txt (renamed from doc/tor-rpm-creation.txt) | 0 | ||||
| -rw-r--r-- | doc/contrib/torel-design.txt | 181 | ||||
| -rw-r--r-- | doc/include.am | 2 | ||||
| -rw-r--r-- | doc/spec/README | 11 | ||||
| -rw-r--r-- | doc/tor-win32-mingw-creation.txt | 119 | ||||
| -rw-r--r-- | doc/translations.txt | 182 | ||||
| -rw-r--r-- | doc/v3-authority-howto.txt | 84 |
10 files changed, 3 insertions, 671 deletions
diff --git a/changes/bug8965 b/changes/bug8965 new file mode 100644 index 000000000..b5af27963 --- /dev/null +++ b/changes/bug8965 @@ -0,0 +1,3 @@ + o Removed documentation: + - Remove some of the older contents of doc/ as obsolete; move others + to torspec.git. Fixes bug 8965. diff --git a/doc/TODO b/doc/TODO deleted file mode 100644 index 7e547496e..000000000 --- a/doc/TODO +++ /dev/null @@ -1,3 +0,0 @@ - -We no longer track our TODO lists in git. To see open Tor tasks, visit -our bugtracker and wiki at trac.torproject.org. diff --git a/doc/contrib/authority-policy.txt b/doc/contrib/authority-policy.txt deleted file mode 100644 index 7072082d1..000000000 --- a/doc/contrib/authority-policy.txt +++ /dev/null @@ -1,89 +0,0 @@ - -0. Overview. - - This document contains various informal policies for how to operate - a directory authority, how to choose new ones, etc. - -1. How to pick a new directory authority. - - Here's our current guidelines for how to pick new directory - authorities. - - (These won't ever be formal criteria -- we need to keep this flexible - so we can adapt to new situations.) - - o Stability: - - Must be a low-downtime Tor server (computer as well as network). - - Must have a static IP. - - The operator must have been running a stable Tor server for at least - 3 months. - - Must intend for this server to stick around for the next 12 months - or more. - - Must not hibernate. - - Should not be an exit node (as this increases the risk both of - downtime and of key compromise). - - o Performance: - - Must have sufficient bandwidth: at least 10mbit/s symmetric, - though in practice the inbound traffic can be considerably less. - - o Availability: - - Must be available to upgrade within a few days in most cases. - (While we're still developing Tor, we periodically find bugs that - impact the whole network and require authority upgrades.) - - Should have a well-known way to contact the administrator - via PGP-encrypted message. - - o Integrity: - - Must promise not to censor or attack the network and users. - - Should be run by somebody that Tor (i.e. Roger) knows. - - Should be widely regarded as fair/trustworthy, or at least - known, by many people. - - If somebody asks you to backdoor or change your server, legally or - otherwise, you will fight it to the extent of your abilities. If - you fail to fight it, you must shut down the Tor server and notify - us that you have. - - o Diversity - - We should avoid situations that make it likelier for multiple - authority failures to happen at the same time. Therefore... - - It's good when authorities are not all in the same country. - - It's good when authorities are not all in the same jurisdictions. - - It's good when authorities are not all running the same OS. - - It's good when authorities are not all using the same ISP. - - It's good when authorities are not all running the same - version of Tor. - - No two authorities should have the same operator. - - Maximal diversity, however, is not always practical. Sometimes, - for example, there is only one version of Tor that provides a - given consensus generation algorithm. - - A small group of authorities with the same country/jurisdiction/OS is - not a problem, until that group's size approaches quorum (half the - authorities). - -2. How to choose the recommended versions - - The policy, in a nutshell, is to not remove versions without a good - reason. So this means we should recommend all versions except: - - - Versions that no longer conform to the spec. That is, if they wouldn't - actually interact correctly with the current Tor network. - - Versions that have known security problems. - - Versions that have frequent crash or assert problems. - - Versions that harm the performance or stability of the current Tor - network or the anonymity of other users. For example, a version - that load balances wrong, or a version that hammers the authorities - too much. - - -> some use the slight variant of requiring a *good* reason. -> excellent reasons include "there's a security flaw" -> good reasons include "that crashes every time you start it. you would think -+tor is dumb if you tried to use that version and think of it as tor." -> good reasons include "those old clients do their load balancing wrong, and -+they're screwing up the whole network" -> reasons include "the old one is really slow, clients should prefer the new -+one" -> i try to draw the line at 'good reasons and above' - - diff --git a/doc/tor-rpm-creation.txt b/doc/contrib/tor-rpm-creation.txt index a03891e2b..a03891e2b 100644 --- a/doc/tor-rpm-creation.txt +++ b/doc/contrib/tor-rpm-creation.txt diff --git a/doc/contrib/torel-design.txt b/doc/contrib/torel-design.txt deleted file mode 100644 index 610cbe21f..000000000 --- a/doc/contrib/torel-design.txt +++ /dev/null @@ -1,181 +0,0 @@ -Design For A Tor DNS-based Exit List - -Status: - - This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes. - See http://exitlist.torproject.org/ for an implementation. - -Why? - - It's useful for third parties to be able to tell when a given connection - is coming from a Tor exit node. Potential applications range from - "anonymous user" cloaks on IRC networks like oftc, to networks like - Freenode that apply special authentication rules to users from these - IPs, to systems like Wikipedia that may want to make a priority of - _unblocking_ shared IPs more liberally than non-shared IPs, since shared - IPs presumably have non-abusive users as well as abusive ones. - - Since Tor provides exit policies, not every Tor server will connect to - every address:port combination on the Internet. Unless you're trying to - penalize hosts for supporting anonymity, it makes more sense to answer - the fine-grained question "which Tor servers will connect to _me_?" than - the coarse-grained question "which Tor servers exist?" The fine-grained - approach also helps Tor server ops who share an IP with their Tor - server: if they want to access a site that blocks Tor users, they - can exclude that site from their exit policy, and the site can learn - that they won't send it anonymous connections. - - Tor already ships with a tool (the "contrib/exitlist" script) to - identify which Tor nodes might open anonymous connections to any given - exit address. But this is a bit tricky to set up, so only sites like - Freenode and OFTC that are dedicated to privacy use it. - Conversely, providers of some DNSEL implementations are providing - coarse-grained lists of Tor hosts -- sometimes even listing servers that - permit no exit connections at all. This is rather a problem, since - support for DNSEL is pretty ubiquitous. - - -How? - - Keep a running Tor instance, and parse the cached-routers and - cached-routers.new files as new routers arrive. To tell whether a given - server allows connections to a certain address:port combo, look at the - definitions in dir-spec.txt or follow the logic of the current exitlist - script. If bug 405 is still open when you work on this - (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll - probably want to extend it to look at only the newest descriptor for - each server, so you don't use obsolete exit policy data. - - FetchUselessDescriptors would probably be a good torrc option to enable. - - If you're also running a directory cache, you get extra-fresh - information. - - -The DNS interface - - Standard DNSEL, if I understand right, looks like this: There's some - authoritative name server for foo.example.com. You want to know if - 1.2.3.4 is in the list, so you query for an A record for - 4.3.2.1.foo.example.com. If the record exists and has the value - 127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list. If you get an NXDOMAIN - error, 1.2.3.4 is not in the list. If you ask for a domain name outside - of the foo.example.com zone, you get a Server Failure error[RFC 1035]. - - Assume that the DNSEL answers queries authoritatively for some zone, - torhosts.example.com. Below are some queries that could be supported, - though some of them are possibly a bad idea. - - - Query type 1: "General IP:Port" - - Format: - {IP1}.{port}.{IP2}.ip-port.torhosts.example.com - - Rule: - Iff {IP1} is a Tor server that permits connections to {port} on - {IP2}, then there should be an A record with the value 127.0.0.2. - - Example: - "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the - value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1 - that allows connections to port 80 on 1.2.3.4. - - Example use: - I'm running an IRC server at w.x.y.z:9999, and I want to tell - whether an incoming connection is from a Tor server. I set - up my IRC server to give a special mask to any user coming from - an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com. - - Later, when I get a connection from a.b.c.d, my ircd looks up - "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see - if it's a Tor server that allows connections to my ircd. - - - Query type 2: "IP-port group" - - Format: - {IP}.{listname}.list.torhosts.example.com - - Rule: - Iff this Tor server is configured with an IP:Port list named - {listname}, and {IP} is a Tor server that permits connections to - any member of {listname}, then there exists an A record. - - Example: - Suppose torhosts.example.com has a list of IP:Port called "foo". - There is an A record for 4.3.2.1.foo.list.torhosts.example.com - if and only if 1.2.3.4 is a Tor server that permits connections - to one of the addresses in list "foo". - - Example use: - Suppose torhosts.example.com has a list of hosts in "examplenet", - a popular IRC network. Rather than having them each set up to - query the appropriate "ip-port" list, they could instead all be - set to query a central examplenet.list.torhosts.example.com. - - Problems: - We'd be better off if each individual server queried about hosts - that allowed connections to itself. That way, if I wanted to - allow anonymous connections to foonet, but I wanted to be able to - connect to foonet from my own IP without being marked, I could add - just a few foonet addresses to my exit policy. - - - Query type 3: "My IP, with port" - - Format: - {IP}.{port}.me.torhosts.example.com - - Rule: - An A record exists iff there is a tor server at {IP} that permits - connections to {port} on the host that requested the lookup. - - Example: - "4.3.2.1.80.me.torhosts.example.com" should have an A record if - and only if there is a Tor server at 1.2.3.4 that allows - connections to port 80 of the querying host. - - Example use: - Somebody wants to set up a quick-and-dirty Tor detector for a - single webserver: just point them at 80.me.torhosts.example.com. - - Problem: - This would be easiest to use, but DNS gets in the way. If you - create DNS records that give different results depending on who is - asking, you mess up caching. There could be a fix here, but might - not. - - - RECOMMENDATION: Just build ip-port for now, and see what demand is - like. There's no point in building mechanisms nobody wants. - -Web interface: - - Should provide the same data as the dns interface. - -Other issues: - - After a Tor server op turns off their server, it stops publishing server - descriptors. We should consider that server's IP address to still - represent a Tor node until 48 hours after its last descriptor was - published. - - 30-60 minutes is not an unreasonable TTL. - - There could be some demand for address masks and port lists. Address - masks wider than /8 make me nervous here, as do port ranges. - - We need an answer for what to do about hosts which exit from different - IPs than their advertised IP. One approach would be for the DNSEL - to launch periodic requests to itself through all exit servers whose - policies allow it -- and then see where the requests actually come from. - -References: - - [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for - E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November - 2005. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. diff --git a/doc/include.am b/doc/include.am index 9eb919b9e..9695292bd 100644 --- a/doc/include.am +++ b/doc/include.am @@ -36,8 +36,6 @@ endif EXTRA_DIST+= doc/HACKING doc/asciidoc-helper.sh \ $(html_in) $(man_in) $(txt_in) \ - doc/tor-rpm-creation.txt \ - doc/tor-win32-mingw-creation.txt doc/spec/README \ doc/state-contents.txt docdir = @docdir@ diff --git a/doc/spec/README b/doc/spec/README deleted file mode 100644 index ccd33a421..000000000 --- a/doc/spec/README +++ /dev/null @@ -1,11 +0,0 @@ -The Tor specifications and proposals have moved to a new repository. - -To browse the specifications, go to - https://gitweb.torproject.org/torspec.git/tree - -To check out the specification repository, run - git clone git://git.torproject.org/torspec.git - -For other information on the repository, see - https://gitweb.torproject.org/torspec.git - diff --git a/doc/tor-win32-mingw-creation.txt b/doc/tor-win32-mingw-creation.txt deleted file mode 100644 index 4a25e47a8..000000000 --- a/doc/tor-win32-mingw-creation.txt +++ /dev/null @@ -1,119 +0,0 @@ -## -## Instructions for building Tor with MinGW (http://www.mingw.org/) -## - -Stage One: Download and Install MinGW. ---------------------------------------- - -Download mingw: -http://prdownloads.sf.net/mingw/MinGW-5.1.6.exe?download - -Download msys: -http://prdownloads.sf.net/ming/MSYS-1.0.11.exe?download - -Download msysDTK: -http://sourceforge.net/projects/mingw/files/MSYS%20Supplementary%20Tools/msysDTK-1.0.1/msysDTK-1.0.1.exe/download - -Install MinGW, msysDTK, and MSYS in that order. - -Make sure your PATH includes C:\MinGW\bin. You can verify this by right -clicking on "My Computer", choose "Properties", choose "Advanced", -choose "Environment Variables", select PATH. - -Start MSYS(rxvt). - -Create a directory called "tor-mingw". - -Stage Two: Download, extract, compile openssl ----------------------------------------------- - -Download openssl: -http://www.openssl.org/source/openssl-0.9.8l.tar.gz - -Extract openssl: -Copy the openssl tarball into the "tor-mingw" directory. -Type "cd tor-mingw/" -Type "tar zxf openssl-0.9.8l.tar.gz" -(Note: There are many symlink errors because Windows doesn't support -symlinks. You can ignore these errors.) - -Make openssl libraries: -Type "cd tor-mingw/openssl-0.9.8l/" -Type "./Configure -no-idea -no-rc5 -no-mdc2 mingw" -Edit Makefile and remove the "test:" and "tests:" sections. -Type "rm -rf ./test" -Type "cd crypto/" -Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;" -Type "cd ../ssl/" -Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;" -Type "cd .." -Type "cp *.h include/openssl/" -Type "find ./fips -type f -name "*.h" -exec cp {} include/openssl/ \;" -# The next steps can take up to 30 minutes to complete. -Type "make" -Type "make install" - - -Stage Three: Download, extract, compile zlib ---------------------------------------------- - -Download zlib source: -http://www.zlib.net/zlib-1.2.3.tar.gz - -Extract zlib: -Copy the zlib tarball into the "tor-mingw" directory -Type "cd tor-mingw/" -Type "tar zxf zlib-1.2.3.tar.gz" - -CHOICE: - -Make zlib.a: -Type "cd tor-mingw/zlib-1.2.3/" -Type "./configure" -Type "make" -Type "make install" - -Done. - - -Stage Four: Download, extract, and compile libevent ------------------------------------------------------- - -Download the latest libevent release: -http://www.monkey.org/~provos/libevent/ - -Copy the libevent tarball into the "tor-mingw" directory. -Type "cd tor-mingw" - -Extract libevent. - -Type "./configure --enable-static --disable-shared" -Type "make" -Type "make install" - -Stage Five: Build Tor ----------------------- - -Download the current Tor alpha release source code from https://torproject.org/download.html. -Copy the Tor tarball into the "tor-mingw" directory. -Extract Tor: -Type "tar zxf latest-tor-alpha.tar.gz" - -cd tor-<version> -Type "./configure" -Type "make" - -You now have a tor.exe in src/or/. This is Tor. -You now have a tor-resolve.exe in src/tools/. - -Stage Six: Build the installer -------------------------------- - -Install the latest NSIS: -http://nsis.sourceforge.net/Download - -Run the package script in contrib: -From the Tor build directory above, run: -"./contrib/package_nsis-mingw.sh" - -The resulting Tor installer executable is in ./win_tmp/. diff --git a/doc/translations.txt b/doc/translations.txt deleted file mode 100644 index 06d16f446..000000000 --- a/doc/translations.txt +++ /dev/null @@ -1,182 +0,0 @@ -## Instructions for helping translate text for Vidalia, TorButton -## and TorCheck -## ( More translation information for Tor related apps will accumulate here ) - -Our translations are handled in one of two places. The Tor Translation Portal -handles all of the translations for Vidalia, Torbutton and TorCheck. The Tor -website itself is currently handled by hand translations using subversion. - -------------------------------------------------------------------------- - -For the Tor website, you'll need a Tor SVN account. -If you do not have one and you need one, please run this command with your -desired username in place of 'USERNAME': - htdigest -c passwd.tmp "Tor subversion repository" USERNAME -and send us the contents of passwd.tmp. - -------------------------------------------------------------------------- - -For the Portal-based projects, all three check in their respective .po -files into the following subversion urls: - - https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton - https://tor-svn.freehaven.net/svn/translation/trunk/projects/torcheck - https://svn.vidalia-project.net/svn/vidalia/trunk/src/vidalia/i18n/ - -The current pootle configuration is checked into subversion as well: - - https://tor-svn.freehaven.net/svn/translation/trunk/pootle - ----------------------------- TorCheck ------------------------------- - -TorCheck uses our translation portal to accept translations. Users use -the portal to check in their changes. To make use of the translations -that users have committed to the translations/ subversion module, you'll -need to ensure that you have a current checked out copy of TorCheck: - - cd check/trunk/i18n/ - check/trunk/i18n$ svn up - -You should see something like the following: - - Fetching external item into 'pootle' - External at revision 15300. - - At revision 15300. - -Now if you had changes, you'd simply want to move the newly updated .po files -into the current stable directory. Moving the .po files from -'check/trunk/i18n/pootle/' into 'check/trunk/i18n' properly naming the files -for their respective locale. - -Here's an example of how to move all of the current pootle translations into -the svn trunk area of TorCheck: - - cd check/trunk/i18n/ - for locale in `ls -1 pootle/|grep -v template`; - do - mv -v pootle/$locale/TorCheck_$locale.po TorCheck_$locale.po; - done - -Now check the differences (ensure the output looks reasonable): - - svn diff - -Ensure that msgfmt has no errors: - - msgfmt -C *.po - -And finally check in the changes: - - svn commit - ----------------------------- Torbutton ------------------------------- - -Torbutton uses our translation portal to accept translations. Users use -the portal to check in their changes. - -To make use of the translations that users have committed to the translations/ -subversion module, you'll need to ensure that you have a current checked out -copy of them in your torbutton git checkout: - - cd torbutton.git/trans_tools - torbutton.git/trans_tools$ svn co https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton pootle - -You should see something like the following: - - Checked out revision 21092. - -If you made changes to strings in Torbutton, you need to rebuild the -templates in torbutton.git/trans_tools/pootle/templates. This is done with -the following command from within the torbutton.git checkout directory: - - moz2po -P -i src/chrome/locale/en/ -o trans_tools/pootle/templates/ - -You now have two options: - -Option 1 (The [shitty] Pootle Web UI Way): - -View then commit the changes to the template with: - - cd trans_tools/pootle - svn diff templates - svn commit templates - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough -times, he may give you a button to click to update templates in Pootle, -or maybe even an account on the Pootle server. Persistence is a virtue. - -You then need to go to the Pootle website and click the checkbox next to -every language on: -https://translation.torproject.org/projects/torbutton/admin.html -and then click "Update Languages" at the bottom. - -You then need to go to each language and go to "Editing Options" and click -"Commit" for each one. - -You then need to 'svn up' locally, and follow the procedure above for -rebuilding your .dtd and .properties files. - -Yes, this sucks. :/ - -Option 2 (Use your own msgmerge: YMMV, may change .po flags and formatting): - -Run msgmerge yourself for each language: - - cd trans_tools - for i in `ls -1 pootle` - do - msgmerge -U ./pootle/$i/torbutton.dtd.po ./pootle/templates/torbutton.dtd.pot - msgmerge -U ./pootle/$i/torbutton.properties.po ./pootle/templates/torbutton.properties.pot - done - svn diff pootle - svn commit pootle - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough times, -he may give you a button on Pootle, or maybe even an account on the Pootle -server. Persistence is a virtue. - -You may notice that some .po file flags and string formatting have changed -with this method, depending on your gettext version. It is unclear if this -is a problem. Please update this doc if you hit a landmine and everything -breaks :) - -After this process is done, you then need to regenerate the mozilla -.dtd and .properties files as specified above. - - -Regardless of whether or not you had changes in the torbutton strings, if there -were updated strings in pootle that you checked out from svn you now need to -convert from .po and move the newly updated mozilla files into the current -stable locale directory. First convert them with the 'mkmoz.sh' script and -then move the proper mozilla files from 'torbutton.git/trans_tools/moz/' into -'torbutton.git/src/chrome/locale/' directory while properly naming the files -for their respective locale. - -Here's an example of how to move all of the current pootle translations into -the svn trunk area of Torbutton: - - cd trans_tools - ./mkmoz.sh - for locale in `ls -1 moz/`; - do - mv -v moz/$locale/*.{dtd,properties} ../src/chrome/locale/$locale/ - done - -Now check the differences to your git branch to ensure the output looks -reasonable: - - cd .. - git diff - -And finally check in the changes: - - cd src/chrome/locale - git commit . - ----------------------------- Vidalia ------------------------------- - -Vidalia uses our translation portal to accept translations. Users use the -portal to check in their changes. No conversion or moving is required other -than normal pootle usage. - diff --git a/doc/v3-authority-howto.txt b/doc/v3-authority-howto.txt deleted file mode 100644 index e4470e8c8..000000000 --- a/doc/v3-authority-howto.txt +++ /dev/null @@ -1,84 +0,0 @@ - - How to add a v3 directory authority. - -What we'll be doing: - - We'll be configuring your Tor server as a v3 directory authority, - generating a v3 identity key plus certificates, and adding your v3 - identity fingerprint to the list of default directory authorities. - -The steps: - -0) Make sure you're running ntp, and that your time is correct. - - Make sure you have Tor version at least r12724. In the short term, - running a working authority may mean running the latest version of - Tor from SVN trunk. Later on, we hope that it will become easier - and you can just run a recent development release (and later still, - a recent stable release). - -1) First, you'll need a certificate. Run ./src/tools/tor-gencert to - generate one. - - Run tor-gencert in a separate, very secure directory. Maybe even on - a more secure computer. The first time you run it, you will need to - run it with the --create-identity-key option to make a v3 authority - identity key. Subsequent times, you can just run it as-is. - - tor-gencert will make 3 files: - - authority_identity_key -- THIS IS VERY SECRET AND VERY SENSITIVE. - DO NOT LEAK IT. DO NOT LOSE IT. - - authority_signing_key -- A key for signing votes and v3 conensuses. - - authority_certificate -- A document authenticating your signing key - with your identity-key. - - You will need to rotate your signing key periodically. The current - default lifetime is 1 year. We'll probably take this down to a month or - two some time soon. To rotate your key, run tor-gencert as before, - but without the --create-identity-key option. - -2) Copy authority_signing_key and authority_certificate to your Tor keys - directory. - - For example if your data directory is /var/lib/tor/, you should run - cp authority_signing_key authority_certificate /var/lib/tor/keys/ - - You will need to repeat this every time you rotate your certificate. - -3) Tell your Tor to be a v3 authority by adding these lines to your torrc: - - AuthoritativeDirectory 1 - V3AuthoritativeDirectory 1 - -4) Now your authority is generating a networkstatus opinion (called a - "vote") every period, but none of the other authorities care yet. The - next step is to get a Tor developer (likely Roger or Nick) to add - your v3 identity fingerprint to the default list of dirservers. - - First, you need to learn your authority's v3 identity fingerprint. - It should be in your authority_certificate file in a line like: - - fingerprint 3041632465FA8847A98B2C5742108C72325532D9 - - One of the Tor developers then needs to add this fingerprint to - the add_default_trusted_dirservers() function in config.c, using - the syntax "v3ident=<fingerprint>". For example, if moria1's new v3 - identity fingerprint is FOO, the moria1 dirserver line should now be: - - DirServer moria1 v1 orport=9001 v3ident=FOO 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441 - - The v3ident item must appear after the nickname and before the IP. - -5) Once your fingerprint has been added to config.c, we will try to - get a majority of v3 authorities to upgrade, so they know about you - too. At that point your vote will automatically be included in the - networkstatus consensus, and you'll be a fully-functioning contributing - v3 authority. - - Note also that a majority of the configured v3 authorities need to - agree in order to generate a consensus: so this is also the point - where extended downtime on your server means missing votes. - |