TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor!
Hi there,
On 17 Dec 2015, at 15:07, Nick Mathewson nickm@torproject.org wrote: In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
Happy to opt in my relays fluxe3 and fluxe4. The former is on the list, the latter is not for reasons unknown to me - it is on the list if I run the onionoo query today.
Cheers Sebastian
My relay, Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34), is not on the list even though it fits all the criteria, except the HSDir flag which I lost when I upgraded to the latest version. Hint, hint, Mr Roger "We should somehow teach everybody that losing their flags for a few days is totally fine" Dingledine :)
Anyhow, I'm glad to opt in my relay if you'll have it
On 2015-12-17 15:07, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
On 18 Dec 2015, at 02:03, Logforme m7527@abc.se wrote:
My relay, Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34), is not on the list even though it fits all the criteria, except the HSDir flag which I lost when I upgraded to the latest version. Hint, hint, Mr Roger "We should somehow teach everybody that losing their flags for a few days is totally fine" Dingledine :)
Anyhow, I'm glad to opt in my relay if you'll have it
Hi,
Your relay changed its IPv4 address on around 2016-06-16 at 12:00:00. This makes it unsuitable as a fallback directory mirror.
Is the new address permanent for the next two years? If so, we can add it to the list for consideration in 0.2.9.
Tim
On 2015-12-17 15:07, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
Hi Nick,
On 17.12.2015, at 15:07, Nick Mathewson nickm@torproject.org wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
I’m happy to opt-in my relay Vadelma [0], but it’s not on the original list - running the onionoo query now includes it, however. I’ve got all the flags, but I can’t guarantee a stable IP address because it’s running on a home connection. So, as far as I understand
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
it doesn’t make sense for me - right? (I’m more than happy to do more than “just” running my relay!)
All the best to you, too!
Cheers, Jannis
[0] https://atlas.torproject.org/#details/8827944C4BDCBDAC9079803F47823403C11A9B...
Howdy,
I'm not on the list and wish to opt-in (for future releases I suppose).
My relay, 00C4B4731658D3B4987132A3F77100CFCB190D97 , does not fit the criteria because it's an exit node, but my exit node does not experience high load, and averages out at about ~60% capacity by bandwidth and <50% by processing, so I'm interested in contributing as much as I can.
On 17.12.15 9:07, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 18 Dec 2015, at 04:09, 12xBTM 12xbtm@gmail.com wrote:
Howdy,
I'm not on the list and wish to opt-in (for future releases I suppose).
My relay, 00C4B4731658D3B4987132A3F77100CFCB190D97 , does not fit the criteria because it's an exit node, but my exit node does not experience high load, and averages out at about ~60% capacity by bandwidth and <50% by processing, so I'm interested in contributing as much as I can.
Hi 12xBTM,
It looks like your relay's key recently changed from 00C4B4731658D3B4987132A3F77100CFCB190D97 to CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
We expected some fallback churn, which is why we have 100 in the list.
Changing a fallback's key has two impacts: * Clients on 0.2.8-alpha will expect the old key, and refuse to connect to your relay as a fallback directory, * In 0.2.8-rc, your relay was excluded as a fallback because the key had changed.
Will you be keeping the new key for the next 2 years? If so, I'll update the fallback list with the new key, and your relay will be considered as a fallback when we next rebuild the list.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
Hey there,
i'd be happy to join with my relay 'GrmmlLitavis'.
Best regards Nurtic-Vibe
Am 17. Dezember 2015 15:07:16 MEZ, schrieb Nick Mathewson nickm@torproject.org:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Not on the list of candidate fallbacks i still offering my family: $4B9E2C56FB42B891794FE2CD2FCAD08A320CC3BB,$BEE2317AE127EB681C5AE1551C1EA0630580638A,$F6279A203C1950ACF592322A235647A05BFBCF91,$5BFDECCE9B4A23AE14EC767C5A2C1E10558B00B9
Am Donnerstag, 17. Dezember 2015 15:07 schrieb Nick Mathewson nickm@torproject.org:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 18 Dec 2015, at 04:43, tor@use.startmail.com wrote:
Not on the list of candidate fallbacks i still offering my family: $4B9E2C56FB42B891794FE2CD2FCAD08A320CC3BB,$BEE2317AE127EB681C5AE1551C1EA0630580638A,$F6279A203C1950ACF592322A235647A05BFBCF91,$5BFDECCE9B4A23AE14EC767C5A2C1E10558B00B9
Hi,
Thanks for the opt-in, but these relays have no DirPort configured. Relays need a DirPort to act as fallback directory mirrors.
If you are able to configure a DirPort on these relays, please let me know, and I'll add them to the list.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 17 December 2015 at 14:07, Nick Mathewson nickm@torproject.org wrote:
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
Just to be sure, you are not yet interested in opt-outs? I have a relay quite high in the list (chopin, 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am likely to move in less than 2 years so it should be opted out when things will no longer be optin.
On 18 Dec 2015, at 04:49, Pascal Terjan pterjan@gmail.com wrote:
On 17 December 2015 at 14:07, Nick Mathewson <nickm@torproject.org mailto:nickm@torproject.org> wrote: For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
Just to be sure, you are not yet interested in opt-outs? I have a relay quite high in the list (chopin, 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am likely to move in less than 2 years so it should be opted out when things will no longer be option.
(Hi, I'm teor, I'll be pulling together the opt-ins and opt-outs for Nick.)
I'll keep a list of opt-outs. They will be useful if we move to automatically including relays in future releases.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hello,
I'd also be happy to opt-in:
14419131033443AE6E21DA82B0D307F7CAE42BDB
BR
On Fri, 18 Dec 2015 09:17:37 +1100 Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 18 Dec 2015, at 04:49, Pascal Terjan pterjan@gmail.com wrote:
On 17 December 2015 at 14:07, Nick Mathewson <nickm@torproject.org mailto:nickm@torproject.org> wrote: For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
Just to be sure, you are not yet interested in opt-outs? I have a relay quite high in the list (chopin, 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am likely to move in less than 2 years so it should be opted out when things will no longer be option.
(Hi, I'm teor, I'll be pulling together the opt-ins and opt-outs for Nick.)
I'll keep a list of opt-outs. They will be useful if we move to automatically including relays in future releases.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 18 Dec 2015, at 04:49, Pascal Terjan pterjan@gmail.com wrote: On 17 December 2015 at 14:07, Nick Mathewson <nickm@torproject.org mailto:nickm@torproject.org> wrote: For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
Just to be sure, you are not yet interested in opt-outs? I have a relay quite high in the list (chopin, 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am likely to move in less than 2 years so it should be opted out when things will no longer be option.
Hi Pascal,
Thanks for the opt-out, it helps us know which relays to avoid in future.
I noticed there are some other relays in that family, should they be opt-in or opt-out?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
we will only add your relay if you opt in.
You obviously have my opt-in for my kitten1 (86E78DD3720C78DA8673182EF96C54B162CD660C) relay !
<3,
Able!
Op do 17 dec. 2015 20:19 schreef Aeris aeris+tor@imirhil.fr:
we will only add your relay if you opt in.
You obviously have my opt-in for my kitten1 (86E78DD3720C78DA8673182EF96C54B162CD660C) relay !
<3,
Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/
Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://caf%C3%A9-vie-priv%C3%A9e.fr/ https://xn--caf-vie-prive-dhbj.fr/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 18 Dec 2015, at 06:31, ]V[ martijn@beekhuis.org wrote:
Able!
(Hi, I'm teor, I'll be pulling together the opt-ins and opt-outs for Nick.)
Thanks, can you let me/us know the names your relay(s)? (I need to know the names to add them to the opt-in list.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 18 Dec 2015, at 09:23, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 18 Dec 2015, at 06:31, ]V[ <martijn@beekhuis.org mailto:martijn@beekhuis.org> wrote: Able!
... Thanks, can you let me/us know the names your relay(s)? (I need to know the names to add them to the opt-in list.)
Hi Martjin,
I could not find any relays with your email address in their contact info.
If you want to opt-in your relays as fallback directory mirrors, can you send me their names or fingerprints?
Thanks
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 12/17/2015 6:07 AM, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Relay was down during transition to new VPS, meets all criteria at this point. Available if needed. New Fingerprint: 'horizons E65D300F11E1DB12C534B0146BDAB6972F1A8A48'
I'm happy to have ratchet on there: FA3415659444AE006E7E9E5375E82F29700CFDFD
Cheers, Sam. On 17 Dec 2015 7:51 p.m., "Kurt Besig" kbesig@socal.rr.com wrote:
On 12/17/2015 6:07 AM, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see:
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks.
https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Relay was down during transition to new VPS, meets all criteria at this point. Available if needed. New Fingerprint: 'horizons E65D300F11E1DB12C534B0146BDAB6972F1A8A48'
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I would like to opt-in my relay, which is on the candidate list.
pixelminer
CE75BF0972ADD52AF8807602374E495C815DB304
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hereby I want to opt-in the following relays which are present on the list:
BabylonNetwork02 (fingerprint: 54660C671B47E6986B465B80444414BD19E5A34B) BabylonNetwork03 (fingerprint: C79552275DFCD486B942510EF663ED36ACA1A84B)
And opt-out the next one for not being able to guarantee it will stay up for next 1-2 years:
BabylonNetwork04 (fingerprint: 3BEFAB76461B6B99DCF34C285E933562F5712AE4)
The initial message states that the relays should be non-exit replays. All these relays are exit relays with enough resources to spare so I would love to see them added.
On 12/17/2015 03:07 PM, Nick Mathewson wrote:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
On 20 Dec 2015, at 02:55, NOC noc@babylon.network wrote:
The initial message states that the relays should be non-exit replays. All these relays are exit relays with enough resources to spare so I would love to see them added. ...
-- Tim Semeijn
Hi Tim,
Thanks for opting-in these relays.
I didn't realise that there are under-utilised exit relays in the Tor network. (I was the one who added "not an exit relay" to the fallback directory criteria.) We'll review the criteria before we select the final list.
Please feel free to opt-in other under-utilised exit relays.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Good to hear the criteria will be reviewed. As far as I am aware there are under-utilised resources on these two exit relays so that is why I am opt-ing in these relays.
If there is any more information on the expected resources for the fallback directory mirrors that will be used I am all ears ;)
On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote:
On 20 Dec 2015, at 02:55, NOC <noc@babylon.network mailto:noc@babylon.network> wrote: The initial message states that the relays should be non-exit replays. All these relays are exit relays with enough resources to spare so I would love to see them added. ...
-- Tim Semeijn
Hi Tim,
Thanks for opting-in these relays.
I didn't realise that there are under-utilised exit relays in the Tor network. (I was the one who added "not an exit relay" to the fallback directory criteria.) We'll review the criteria before we select the final list.
Please feel free to opt-in other under-utilised exit relays.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
On 20 Dec 2015, at 23:42, NOC noc@babylon.network wrote:
Signed PGP part Good to hear the criteria will be reviewed. As far as I am aware there are under-utilised resources on these two exit relays so that is why I am opt-ing in these relays.
If there is any more information on the expected resources for the fallback directory mirrors that will be used I am all ears ;)
With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load.
Here are the details:
At the moment, new Tor clients contact a directory authority to download their initial consensus.
After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight.
If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus.
We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror.
Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.)
Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses.
If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight.
It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load.
If you're interested in some further background, the original proposal is at [2].
Tim
[0]: https://globe.torproject.org/ https://globe.torproject.org/ [1]: https://metrics.torproject.org/dirbytes.html https://metrics.torproject.org/dirbytes.html [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless... https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt
On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote:
On 20 Dec 2015, at 02:55, NOC <noc@babylon.network mailto:noc@babylon.network> wrote: The initial message states that the relays should be non-exit replays. All these relays are exit relays with enough resources to spare so I would love to see them added. ...
-- Tim Semeijn
Hi Tim,
Thanks for opting-in these relays.
I didn't realise that there are under-utilised exit relays in the Tor network. (I was the one who added "not an exit relay" to the fallback directory criteria.) We'll review the criteria before we select the final list.
Please feel free to opt-in other under-utilised exit relays.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
The estimated extra load looks good, it shouldn't be a problem.
Are we entirely sure we want to hardcode a static weight for each fallback directory relay? I know we require it to be stable enough but sometimes the weight assigned to a relay is outside the control of the operator (more relays are added to the Tor network so consensus weight distribution changes, the relay gets DoS-ed and becomes slow at the next measurement).
If all the relays eligible for being added as fallback directory relays are required to have a big enough weight, this means the estimated extra load shouldn't be a problem for neither of them. In this case how bad will it be if we do not hardcode a static weight and give equal chances to all fallback directory relays to be selected by new clients?
As you said on irc, a client will try (maybe 3) fallback directories before giving up and going to the directory authorities.
On 12/20/2015 3:37 PM, Tim Wilson-Brown - teor wrote:
With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load.
Here are the details:
At the moment, new Tor clients contact a directory authority to download their initial consensus.
After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight.
If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus.
We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror.
Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.)
Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses.
If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight.
It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load.
If you're interested in some further background, the original proposal is at [2].
Tim
[0]: https://globe.torproject.org/ [1]: https://metrics.torproject.org/dirbytes.html [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless...
On 21 Dec 2015, at 01:55, s7r s7r@sky-ip.org wrote:
Signed PGP part Hi,
The estimated extra load looks good, it shouldn't be a problem.
Are we entirely sure we want to hardcode a static weight for each fallback directory relay? I know we require it to be stable enough but sometimes the weight assigned to a relay is outside the control of the operator (more relays are added to the Tor network so consensus weight distribution changes, the relay gets DoS-ed and becomes slow at the next measurement).
If there are 100 fallback directories, and clients try several (see below), it doesn't matter if a few are down or busy or are being DoSed.
And it's the relative weights among the set of fallback directories that are used by clients to select a fallback directory: if more relays are added to the Tor network, the relative weights of the fallback directories stay the same. (And we pick up the new weights in the next release.)
If all the relays eligible for being added as fallback directory relays are required to have a big enough weight, this means the estimated extra load shouldn't be a problem for neither of them. In this case how bad will it be if we do not hardcode a static weight and give equal chances to all fallback directory relays to be selected by new clients?
That's a possibility, it's what we currently do for authorities - clients select an authority at random, without considering their consensus weights. I like the simplicity of giving all the fallback directories the same weight, but I think it's wise to add any extra load in proportion to the existing load on the relay.
And I don't know whether equal weights is a viable option for fallback directories - it will depend on their consensus weights being similar enough. (The code currently uses weights, but we could set them all to the same weight if we wanted to.)
The December 2015 list of candidate fallback directories[0] has relative weights from 2.3% to 0.008%.
While we'd likely exclude some relays at the lower end, a relay that helps 1 in 1000 clients connect to the Tor network is still performing a useful role. And there's several tradeoffs we will consider when creating the list.
There's a tradeoff between including small relays, and the cost of increasing the size of the tor binary with each fallback in the list. There's also the risk that including small relays will lead to them not being able to cope with the extra load.
At the higher end, there's a tradeoff between weighting according to consensus weight, and letting a fallback directory see too many clients join the network. (Authorities see approximately 11% of clients that join the Tor network, so we would set the maximum fallback weight lower than that.)
The script we use to select fallback directories has parameters that allow us to control these sorts of tradeoffs, you can see many of them listed in a comment at the top of the file[0].
[0]: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
As you said on irc, a client will try (maybe 3) fallback directories before giving up and going to the directory authorities.
Currently, a client will try 3 fallback directories before trying an authority, another fallback directory, another authority, then giving up for an hour. (This aims to provide ~99.9% bootstrap success within 20 seconds, without increasing the load on the authorities - even if a few authorities and many fallbacks are down. We can fine-tune it before release if we need to.)
Tim
On 12/20/2015 3:37 PM, Tim Wilson-Brown - teor wrote:
With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load.
Here are the details:
At the moment, new Tor clients contact a directory authority to download their initial consensus.
After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight.
If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus.
We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror.
Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.)
Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses.
If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight.
It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load.
If you're interested in some further background, the original proposal is at [2].
Tim
[0]: https://globe.torproject.org/ [1]: https://metrics.torproject.org/dirbytes.html [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Thanks for the information. The load should be no problem at all, great to hear ;)
On 20/12/15 14:37, Tim Wilson-Brown - teor wrote:
On 20 Dec 2015, at 23:42, NOC <noc@babylon.network mailto:noc@babylon.network> wrote:
Signed PGP part Good to hear the criteria will be reviewed. As far as I am aware there are under-utilised resources on these two exit relays so that is why I am opt-ing in these relays.
If there is any more information on the expected resources for the fallback directory mirrors that will be used I am all ears ;)
With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load.
Here are the details:
At the moment, new Tor clients contact a directory authority to download their initial consensus.
After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight.
If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus.
We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror.
Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.)
Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses.
If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight.
It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load.
If you're interested in some further background, the original proposal is at [2].
Tim
[0]: https://globe.torproject.org/ [1]: https://metrics.torproject.org/dirbytes.html [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-he
adless-consensus-bootstrap.txt
On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote:
On 20 Dec 2015, at 02:55, NOC <noc@babylon.network
mailto:noc@babylon.network> wrote: The initial message states that the relays should be non-exit replays. All these relays are exit relays with enough resources to spare so I would love to see them added. ...
-- Tim Semeijn
Hi Tim,
Thanks for opting-in these relays.
I didn't realise that there are under-utilised exit relays in the Tor network. (I was the one who added "not an exit relay" to the fallback directory criteria.) We'll review the criteria before we select the final list.
Please feel free to opt-in other under-utilised exit relays.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org
mailto:tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
You can add me too:
330CD3DB6AD266DC70CDB512B036957D03D9BC59
TeamTardis
Am 17.12.2015 um 15:07 schrieb Nick Mathewson:
TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!
We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.
Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.
For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.
We want relays that expect to be stable for the next 2 years, with:
good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity.
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)
For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)
all best wishes, & thanks for running Tor! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Nick,
On Thu, 17 Dec 2015 at 09:07:16 -0500, Nick Mathewson wrote:
In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial.
Sure, feel free to add these two:
jaures 2CDCFED0142B28B002E89D305CBA2E26063FADE2 bakunin 92CFD9565B24646CAC2D172D3DB503D69E777B8A
Cheers,
tor-relays@lists.torproject.org
-
12xBTM -
]V[ -
Aeris -
Christian Sturm -
contact＠gtor.org -
Dr. Who -
goll＠kset.org -
Hermann Lienstromberg -
Jannis Wiese -
Kurt Besig -
Logforme -
Nick Mathewson -
NOC -
Pascal Terjan -
s7r -
Sam Lanning -
Sebastian Hahn -
Tim Wilson-Brown - teor -
tor＠use.startmail.com