simon:
> As I see it, removing via directory authority consensus is still the
> cleaner way, especially in a case of ~100 similar nodes.
>
> What came to my mind was something like a bugtracker for bad nodes.
Yes, but it's too crafty and should be done by hand. Doing so is error
On 06.07.2016 15:50, Ivan Markin wrote:
> The introduction of peering policy definitely solves this issue in a
> transparent and harmless way. Filed a ticket #19625 [1] to move this
> discussion
> there.
On 06.07.2016 14:56, Roger Dingledine wrote:
> Speaking of which, a while ago I started a
s7r:
> The path of a circuit is selected by the client (i.e. user). So,
> each and every relay / bridge, in order to be considered a valid one,
> should be able to extend a circuit when requested to any other
> relay, otherwise everything gets broken.
So does everything break if there are
On 7/6/2016 4:50 PM, Ivan Markin wrote:
> Andreas Krey:
>> That will cause issues for everyone that happens to select your
>> relay and the 'blocked' relays in a circuit - the connections will
>> just fail, and the user will wonder what happened, and why TBB
>> doesn't work.
>
> Sure, I made a
Andreas Krey:
> That will cause issues for everyone that happens to select your
> relay and the 'blocked' relays in a circuit - the connections will
> just fail, and the user will wonder what happened, and why TBB
> doesn't work.
Sure, I made a notice that you shouldn't do it if you care about
On Tue, Jul 05, 2016 at 10:00:22PM -0700, Green Dream wrote:
> So... what's going on in this particular case and what are the directory
> authorities going to do, if anything?
Yesterday we started the move towards blocking them. (The move takes a
little while, since it needs a sufficient fraction
On 7/6/16, Green Dream wrote:
>> It's up to directory authority operators to deal with
>> suspicious/rogue/misconfigured relays by marking them as
>> invalid/rejected/badexit.
>
> So... what's going on in this particular case and what are the directory
> authorities going
simon:
> If I understood the documentation correctly, as a node operator I can't
> blacklist hosts individually (unless I'm putting them into MyFamily,
> which I don't want to).
AFAIK, there is no option in tor itself to exclude relays from the routing.
But you're still able to restrict
> It's up to directory authority operators to deal with
> suspicious/rogue/misconfigured relays by marking them as
> invalid/rejected/badexit.
So... what's going on in this particular case and what are the directory
authorities going to do, if anything?
As a relay operator near the top of the CW
> In good news, 91 new high speed exits means Tor network should be
> truly blazing for a while :)
these are non-exits relays (currently)
currently 93 relays (89 running):
On Tue, Jul 05, 2016 at 05:10:49PM +0200, Niklas K. wrote:
> It's up to directory authority operators to deal with
> suspicious/rogue/misconfigured relays by marking them as
> invalid/rejected/badexit.
>
> Relay operators are not supposed to decide what other relays they may be put
> in a
On 05.07.2016 13:31, Xza wrote:
> 91 at the moment and they will soon gain more flags.
> https://sourceforge.net/p/nepenthes/wiki/Home/
> Seems like some sort of honeypot.
> Most seem to be from AWS & Linode & Leaseweb USA.
How does the process work to exclude nodes from the network?
If I
91 at the moment and they will soon gain more flags.
https://sourceforge.net/p/nepenthes/wiki/Home/
Seems like some sort of honeypot.
Most seem to be from AWS & Linode & Leaseweb USA.
On July 3, 2016 10:59:00 AM GMT+02:00, nusenu wrote:
>some new ones:
13 matches
Mail list logo