Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 02:03, Logforme  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





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 23:12, hwertiout...@safe-mail.net wrote:
> 
> Hi.
> 
>> TL;DR: Stable non-exit relays can help tor clients use the Tor
>> network. Please opt-in!
> 
> My relay is on the list and I want to opt in!
> 
> eriador 6DE61A6F72C1E5418A66BFED80DFB63E4C77668F

Dear hwertiout695,

It looks like your relay's IP address recently changed from 85.25.138.93 to 
91.121.84.137.
This is OK, we expected some fallback churn, which is why we have 100 in the 
list.

Changing a fallback's IP address has two impacts:
* Clients on 0.2.8-alpha will look for your relay as a fallback directory on 
the old IP address,
* In 0.2.8-rc, your relay was excluded as a fallback because the IP address had 
changed.

Will you be keeping the new IP address for the next 2 years?
If so, I'll update the fallback list with the new IP address, and your relay 
will be considered as a fallback when we next rebuild the list.

Thanks

Tim


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Jan 2016, at 11:07, Roman Mamedov  wrote:
> 
> On Mon, 18 Jan 2016 10:16:40 +1100
> Tim Wilson-Brown - teor  wrote:
> 
>> I think if a client is just using it for bootstrap, any extra latency 
>> shouldn't be an issue.
>> But IPv6 clients may also pick it as a guard, so that should be taken into 
>> account.
>> 
>> Should we be running relays over IPv6 tunnels?
> 
> Hurricane Electric has tunnel servers all over the world, so it's easy to pick
> one which will only add negligible latency: 
> https://tunnelbroker.net/status.php
> 
> Performance is not a concern either, these are not overloaded and should
> be quite fast.
> 
> On the other hand HE.net may or may not want to have a word with you if you
> run a relay through them with hundreds of megabits of IPv6 traffic; but that's
> not something we can expect in the nearest  future. [and such powerful relays
> are most likely in proper DCs with easily obtainable native IPv6 anyways]

We're still working to get Tor clients bootstrapping over IPv6, so there isn't 
going to be much IPv6 relay traffic at the moment.

> There's a possible privacy issue that all the HE.net tunnel traffic can
> technically be captured by HE.net;
> 
> however all of these provide IPv6 addresses under the same AS (6939) and the
> same prefix of 2001:470::/32, so perhaps the same-AS avoidance code will
> ensure that a HE.net IPv6 is only used once in a circuit? Does it correctly
> handle cases when a router's IPv4 and IPv6 addresses are from different ASes?

Tor doesn't use ASs for same-network avoidance, it only uses network masks.

In the current Tor codebase, 
onion_populate_cpath()/addrs_in_same_network_family() avoids adding relays in 
the same IPv4 /16 to the same circuit. IPv6 addresses are not considered, 
because this check uses the relay's primary ORPort IPv4 address.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Jan 2016, at 03:05, Thom Wiggers  wrote:
> 
> Hi all,
> 
> I would like to opt in for this trail,
> 
> My relay is:
> 
> tornoderdednl CBEFF7BA4A4062045133C053F2D70524D8BBE5BE on 178.62.199.226 / 
> [2a03:b0c0:2:d0::b7:5001].
> 
> (Will you also be including IPv6 addresses?)

Hi Thom,

The current fallback directories script looks up each relay's IPv6 address from 
OnionOO and adds it to the relay's fallback directory entry.

These addresses are parsed by Tor as of 0.2.8-alpha-dev, but clients don't use 
them to bootstrap yet.
(I'm working on IPv6 client bootstrap in Trac Ticket #17840, hopefully it will 
make it into 0.2.8.)
https://trac.torproject.org/projects/tor/ticket/17840 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 04:43, t...@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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 06:03, starlight.201...@binnacle.cx wrote:
> 
> Relay 'Binnacle' experienced outages due to a
> loose fiber-option junction in the overhead
> wires that has been repaired.  I believe
> it would make the list if not for this
> and do not foresee further trouble.
> ...
> Available if desired.  Can configure IPv6
> on the HE tunnel here if helpful.

Once clients start bootstrapping over IPv6[0], more IPv6 fallback directories 
and relays would be helpful.

But I don't know enough about IPv6 tunnels in general and Hurricane Electric in 
particular to know whether a tunnel is advisable for a tor relay.

I think if a client is just using it for bootstrap, any extra latency shouldn't 
be an issue.
But IPv6 clients may also pick it as a guard, so that should be taken into 
account.

Should we be running relays over IPv6 tunnels?

Tim

[0]: We're working on it in 
https://trac.torproject.org/projects/tor/ticket/17840 


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 04:49, Pascal Terjan  wrote:
> On 17 December 2015 at 14:07, Nick Mathewson  > 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Roman Mamedov]

On Mon, 18 Jan 2016 10:16:40 +1100
Tim Wilson-Brown - teor  wrote:

> I think if a client is just using it for bootstrap, any extra latency 
> shouldn't be an issue.
> But IPv6 clients may also pick it as a guard, so that should be taken into 
> account.
> 
> Should we be running relays over IPv6 tunnels?

Hurricane Electric has tunnel servers all over the world, so it's easy to pick
one which will only add negligible latency: https://tunnelbroker.net/status.php

Performance is not a concern either, these are not overloaded and should
be quite fast.

On the other hand HE.net may or may not want to have a word with you if you
run a relay through them with hundreds of megabits of IPv6 traffic; but that's
not something we can expect in the nearest  future. [and such powerful relays
are most likely in proper DCs with easily obtainable native IPv6 anyways]

There's a possible privacy issue that all the HE.net tunnel traffic can
technically be captured by HE.net;

however all of these provide IPv6 addresses under the same AS (6939) and the
same prefix of 2001:470::/32, so perhaps the same-AS avoidance code will
ensure that a HE.net IPv6 is only used once in a circuit? Does it correctly
handle cases when a router's IPv4 and IPv6 addresses are from different ASes?

-- 
With respect,
Roman


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 09:23, Tim Wilson-Brown - teor  wrote:
>> On 18 Dec 2015, at 06:31, ]V[ > > 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 19 Dec 2015, at 05:53, Felix  wrote:
> ...
> I'm happy to bring in the relay Doedel22 
> '8FA37B93397015B2BC5A525C908485260BE9F422'.

Hi Felix,

There are some other relays in that family, did you want to opt-in or opt-out 
for them?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Thom Wiggers]

Hi all,

I would like to opt in for this trail,

My relay is:

tornoderdednl CBEFF7BA4A4062045133C053F2D70524D8BBE5BE on 178.62.199.226
/ [2a03:b0c0:2:d0::b7:5001].

(Will you also be including IPv6 addresses?)

Best regards,

Thom


On 12/01/16 14:07, Tim Wilson-Brown - teor wrote:
>
>> On 12 Jan 2016, at 23:30, Joost Rijneveld 
>> wrote:
>>
>> Hi all,
>>
>>> On 17 Dec 2015, at 15:07, Nick Mathewson wrote:
>>> 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.
>>
>> I realise it's been a while since the last post in this thread, but
>> I'd like to opt-in.
>
> That's OK, we're still taking opt-ins.
>
> 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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 12 Jan 2016, at 23:30, Joost Rijneveld  wrote:
> 
> Hi all,
> 
>> On 17 Dec 2015, at 15:07, Nick Mathewson wrote:
>> 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.
> 
> I realise it's been a while since the last post in this thread, but
> I'd like to opt-in.

That's OK, we're still taking opt-ins.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Joost Rijneveld]

Hi all,

> On 17 Dec 2015, at 15:07, Nick Mathewson wrote:
> 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.

I realise it's been a while since the last post in this thread, but
I'd like to opt-in.

Relay:
kili DD85503F2D1F52EF9EAD621E942298F46CD2FC10

Cheers,
Joost
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[starlight . 2015q3]

Found a serious bug in the

   updateFallbackDirs.py

script used to generate the fallback relay
candidate list.  The OnionOO retrieval used
to pull flag history returns the entire
history of each relay rather than the
120 days requested.

This results in 145 relays left
off the list as too-old history is
averaged into the percentages.

While this bug appears to be in either
OnionOO or in the constructed request
URL (not sure which), I opted to add a
maximum history age to the script.  The
result is 558 relays instead of the
original 413.  (My relay Binnacle now
easily makes the cut with guard flag at
97.4 percent.)

In addition several data validation bugs
were discovered empirically and corrected.

Changes:

* support maximum history age in _avg_generic_history()

* create and apply MAX_AGE_DAYS=120 in calls
  to _avg_generic_history()

* fix division-by-zero trap in _avg_generic_history()

* skip missing (i.e. null/None) intervals in _avg_generic_history()

* Python timedelta.total_seconds() function not
  available in 2.6; replace with equivalent expression

* set DEBUG logging level to make relay
  exclusion reasons visible

* move CUTOFF_GUARD test to end in order to
  expose more exclusion reasons

Attached to this message are

1) revised script
2) script patch

Posted to PasteBin (one month expire):

3) fallback_dirs.inc as-of 2016/01/11
   http://pastebin.com/8cxKCEP6

4) debug output showing causes of relay exclusions
   http://pastebin.com/raw/3SBpgECm

updateFallbackDirs.py.patch
Description: Binary data


updateFallbackDirs.py
Description: Binary data
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[starlight . 2015q3]

follow up:

Looking at the URL it appears that the selection criteria indicates which 
records to select NOT the range of history to return.  So the having the script 
filter by MAX_AGE (per the patch) is correct.  A quick examination of

https://onionoo.torproject.org/protocol.html

reveals no obvious way to restrict the history time-range returned.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 12 Jan 2016, at 12:11, Tim Wilson-Brown - teor  wrote:
> 
> 
>> On 12 Jan 2016, at 10:14, starlight.201...@binnacle.cx 
>>  wrote:
>> 
>> Found a serious bug in the
>> 
>>   updateFallbackDirs.py
>> 
>> script used to generate the fallback relay
>> candidate list.  The OnionOO retrieval used
>> to pull flag history returns the entire
>> history of each relay rather than the
>> 120 days requested.
>> 
>> This results in 145 relays left
>> off the list as too-old history is
>> averaged into the percentages.
> 
> Thanks, logged as #18035
> https://trac.torproject.org/projects/tor/ticket/18035 
> 
I've reviewed this patch and it looks good.
I updated it for the latest version of the script in the tor git repository, as 
it was based on an old version.

I've also logged the more general issue with OnionOO and date ranges as #18036.
https://trac.torproject.org/projects/tor/ticket/18036 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[starlight . 2015q3]

At 14:24 1/12/2016 +1100, you wrote:

>I've reviewed this patch and it looks good.
>I updated it for the latest version of the script in the tor git repository, 
>as it was based on an old version.

great, thanks!



>I've also logged the more general issue with OnionOO and date ranges as #18036.
>https://trac.torproject.org/projects/tor/ticket/18036


I looked at it more closely and I think that OnionOO
does not support time-ranges in the retrieved data
--one seems to always get everything.

Posted a follow-up to the original forum message
about this shortly after the original.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 12 Jan 2016, at 10:14, starlight.201...@binnacle.cx wrote:
> 
> Found a serious bug in the
> 
>   updateFallbackDirs.py
> 
> script used to generate the fallback relay
> candidate list.  The OnionOO retrieval used
> to pull flag history returns the entire
> history of each relay rather than the
> 120 days requested.
> 
> This results in 145 relays left
> off the list as too-old history is
> averaged into the percentages.

Thanks, logged as #18035
https://trac.torproject.org/projects/tor/ticket/18035 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[contact]

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_dirs.inc
> 
> 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,
-- 
Guilhem.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Dr. Who]

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_dirs.inc
> 
> 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
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[NOC]

-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 > > 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJWdqIbAAoJELGHAxAqVA+lIBwQAM8ySwfyyvrnfTKCrFNbavfz
atVzEk5W/ITbr2rL3E0ZRhsZSkntGBdlkxtcwfw2aAiWX8AEtvK7uLvg+90INk8Q
xGD+qDsBcB6T+RQYMKMSVrUsv1KAF0V3AAd85B5tbaXWbOLecTjnvm3Hob1tPTRu
fgKGKOQkHyLMoNfzNgXGjsc6nNMvBNr98jLdT3hqKDisF+nWqZ6745U6akPegtUV
pOOlPvFeBQt3tKQR6h368Xb6SNuzPMCho+EPJtHtiLQMB39obOh1iitXaLEOCe34
3yoBSDd85NOTiB8PJJ2tAjnheYKu+dQXZGctz73TaEK75cCrw9c3cEmJUYoH5Wr8
hJZy0frxC9Hw492RpptUoJw4EK+Mgw4B6d23EWe+yk6sZSxyV0VYUoInu4HSjVcI
TaB4cnqdXUOXsstPwz624H06ZuDcGzTU/g12kij2nqFqmra6xod6LZ+FuqH0cOPm
3tzgnlxz8+HNEkHowpnkKtmbbXEN1tdgeCVESy47now6wuzNQEPZTlr+mzufo3q3
PDHZQqlgpIKjz4K4VQSY/SI5mu6Af/hqgoxKexwBfaLUq9IrgUJB7QgLUykvNEBz
XtSq/e6E3GATEZdJ7MzUD2wG5HWTBCCpeZxLYoJ2oP0Fn8FfXCfc3V8PwcuD9lwY
N4HQqMBT0AkI87nsdCtj
=sgdN
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 20 Dec 2015, at 02:55, NOC  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[s7r]

-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-consensus-bootstrap.txt
>
> 
> 


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWdsFzAAoJEIN/pSyBJlsRCTsIAIe1rq9wMejw+iUzAygNo04/
qpVfbupTvCe0CcbbadAEndpboKQGVDgXSTrj7fx59DC0oQcKvOlpjyKin13xxPoy
HPV2ClurHJD2PrM7p4ZUSHhSkwL2PBQyO9X3or+RXiSeqy1E+mLEyjOT9ckjawX3
6hgLm7VD9Jj2+z2GRLp8caXjfNmIb4trYZ1G1PF/AKQdpGJhIAgOHILsuRiXI9EU
rFcpchYnXSksSfG9tZCVcQR3dHB6cejTIFpWMijdoLtmdy+CeDumwJa5C5CK1WCX
ncERnai+KFFOQZZx3s8UyzaU8Lyk+spGL5tt5jQ8qaVPv5muKwvoK/RyzgMmto4=
=XhXY
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 20 Dec 2015, at 23:42, NOC  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-headless-consensus-bootstrap.txt
 



> 
> 
> On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote:
> >
> >> On 20 Dec 2015, at 02:55, NOC  >> > 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 

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 21 Dec 2015, at 01:55, s7r  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_dirs.inc

> 
> 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 

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[NOC]

-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 > > 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 > 
 > 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
>> 

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[NOC]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hereby I want to opt-in the following relays which are present on the
list:

BabylonNetwork02 (fingerprint: 54660C671B47E6986B465B8014BD19E5A34B)
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_dirs.inc
>
>  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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJWdX3/AAoJELGHAxAqVA+lH0IQAKAXNieyoMdc4BgldRZok/er
OuZZJcy2tMpUdgvoODt4vdl3cHstexbn/G4XiDLwxpFi+xT4dFo5ppyy0rDdZ6Xj
+0lKGclOowtCVzYsP3DY+M8c+pBaqlOeGc3lekHn1rAutlgK4Pi7vFbxd0YI3XjG
mVwLv/8XA0R3QD2F5my4sjZMAH9M7E6ySGOYj5CJY4BmUMIvSwYHp/Y7nU0x5b7y
BoUPoN84PKhYr3IEsjMiBY/NeFRYqJEtXpAoCUE+TaBVe8HAp4g8itoowrzJGpey
UEzhZRCJx5fwzvfGQbw517CuZJQI5IlW3As2aWQyd2IbSU68nztcw9Di7QJZg0Rc
x4H7M44Ohe8LUZTWZkQgjwnHLAvSYrs2CF25XSq7/yB1qU/rT3OipO5hUeXSW0RL
RSSmChyQI5sLuGD+p77rDr4W2TAVYU3LvKNY3ywM2Abc4kkxA4XzKCz5+oLOicpt
WT6zm7EAkSYyJNrF9wm9HyncZFT8bmI7VjkVeqqHUl85BLdjJzRztQASDdGdlv2Z
xrBiIc53fLZPTt85ZYnQp2H+oBdsEKpUnlKcFMNhUI/a+7sP60SHKfUopayKrlZ5
YXokK4XLuMpND5RxhU12NE0As2RzfJVDieBXy7fY3jE+NPG8lngJV8yjpLa+TgYm
oYBkTOL9tXu11tSWIlpU
=nBZA
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Christian Sturm]

I would like to opt-in my relay, which is on the candidate list.

pixelminer

CE75BF0972ADD52AF8807602374E495C815DB304


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[hwertiout695]

Hi.

> TL;DR: Stable non-exit relays can help tor clients use the Tor
> network. Please opt-in!

My relay is on the list and I want to opt in!

eriador 6DE61A6F72C1E5418A66BFED80DFB63E4C77668F
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Raul Fournier]

Feel free to opt-in my relay

wagner
5525D0429BFE5DC4F1B0E9DE47A4CFA169661E33
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Felix]

Hi

I'm happy to bring in the relay Doedel22 
'8FA37B93397015B2BC5A525C908485260BE9F422'.

Best regards, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[David Schulz]

hi,

you can took coby "A360C21FA87FFA2046D92C17086A6B47E5C68109" too.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Sebastian Hahn]

Hi there,

> On 17 Dec 2015, at 15:07, Nick Mathewson  wrote:
> In December 2015, we created a list of ~400 candidate fallbacks.
> https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc
> 
> 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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Opt-In Trial: Fallback Directory Mirrors

[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_dirs.inc

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

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Logforme]

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!
>
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Jannis Wiese]

Hi Nick,

> On 17.12.2015, at 15:07, Nick Mathewson  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/8827944C4BDCBDAC9079803F47823403C11A9B7A




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Hermann Lienstromberg]

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 
:
>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_dirs.inc
>
>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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[12xBTM]

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_dirs.inc
> 
> 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
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[tor]

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 
:

 

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_dirs.inc

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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Aeris]

>  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é-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[]V[]

Able!

Op do 17 dec. 2015 20:19 schreef Aeris :

> >  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é-vie-privée.fr/ 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Sam Lanning]

I'm happy to have ratchet on there: FA3415659444AE006E7E9E5375E82F29700CFDFD

Cheers,
Sam.
On 17 Dec 2015 7:51 p.m., "Kurt Besig"  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_dirs.inc
> >
> >  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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Kurt Besig]

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_dirs.inc
>
>  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'



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 06:31, ]V[  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Tim Wilson-Brown - teor]

> On 18 Dec 2015, at 04:49, Pascal Terjan  wrote:
> 
> 
> 
> On 17 December 2015 at 14:07, Nick Mathewson  > 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[goll]

Hello,

I'd also be happy to opt-in:

14419131033443AE6E21DA82B0D307F7CAE42BDB

BR


On Fri, 18 Dec 2015 09:17:37 +1100
Tim Wilson-Brown - teor  wrote:

> > On 18 Dec 2015, at 04:49, Pascal Terjan  wrote:
> > 
> > 
> > 
> > On 17 December 2015 at 14:07, Nick Mathewson  > > 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
> 



pgpn9Dusw2lBo.pgp
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[starlight . 2015q3]

Relay 'Binnacle' experienced outages due to a
loose fiber-option junction in the overhead
wires that has been repaired.  I believe
it would make the list if not for this
and do not foresee further trouble.

Has a static IP and another Verizon FiOS relay
qualifies, a positive reflection on the
network.

Available if desired.  Can configure IPv6
on the HE tunnel here if helpful.


$ python updateFallbackDirs.py

DEBUG:root:Failed to get an ipv6 address for 
4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2.
DEBUG:root:Adding uptime 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2.
DEBUG:root:4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 not a candidate: guard avg 
too low (0.910189)

{
"dir_address":"108.53.208.157:80",
"or_addresses":["108.53.208.157:443"],
"contact":"starlight dot qQ at binnacle dot cx",
"consensus_weight":17500,
"fingerprint":"4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2",
"recommended_version":true,
"nickname":"Binnacle",
"last_changed_address_or_port":"2015-06-12 18:00:00"
}

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays