July 2015 - tor-relays - lists.torproject.org

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

Reminder: exit nodes probably shouldn't be using Google's DNS servers
by Nick Mathewson 25 Feb '16

25 Feb '16

Hi, all! While looking into a bug report, I noticed that an exit node was using one of Google's well-known public DNS servers for its own DNS server. No disrespect to the operators of Google's fine public DNS service, but my sense is that using it for a Tor exit node might not be the greatest idea for users' privacy, having one DNS provider that gets to see so many requests. It's probably a better idea to have your own local cacheing DNS server. Would anybody like to share a guide about how to set one of those up safely and migrate correctly? best wishes, -- Nick

23 38

Relays with misconfigured MyFamily (declared vs. effective)
by nusenu 17 Feb '16

17 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, the following relays have misconfigured MyFamily settings. 'misconfigured' is defined by declared family does not match effective family (as computed by onionoo's new effectiv_family field [1] - thanks Karsten). Maybe we will see future versions of globe or atlas displaying a diff of the two family sets to make such misconfigurations more visible. Please let me know if you find any errors (I did not fact check the output). +------------------------------------------+----------+ | Contact (truncated) | Fingerpr | +------------------------------------------+----------+ | +1 303-265-9283, rdump@OFTC | 09683D5D | | 0x3AEE83BB539036CA <bb AT symvaro DOT co | 6FDF2D3B | | 0x6F6D60C1 Security Dept <hello@brasshor | 445F1C85 | | 0x6F6D60C1 Security Dept <hello@brasshor | 6BC82EBA | | 0x6F6D60C1 Security Dept <hello@brasshor | 254EB51B | | 0x6F6D60C1 Security Dept <hello@brasshor | B3515F16 | | 0xDE731050 Gareth Llewellyn <gareth@netw | 5CAECF26 | | 0xFD78BCE1 Fruity Oaty Tor Exit <torexit | 1ECD73B9 | | 1024D/1DFBA164 Bernhard M. Wiedemann <to | 172DC95F | | 1024D/39B9820C admin at perfect minus pr | B897826E | | 1024D/39B9820C admin at perfect minus pr | 5FCC8306 | | 1024D/39B9820C admin at perfect minus pr | 2421E10D | | 1024D/39B9820C admin at perfect minus pr | AC7AE98C | | 1024D/39B9820C admin at perfect minus pr | E8B7D19C | | 1024D/39B9820C admin at perfect minus pr | ED9F582E | | 1024D/39B9820C admin at perfect minus pr | B1843B40 | | 1MTUwHFknUyUgRYqpNDYiA2j7sXTYoCe2P | E799227D | | 4096R/8BA2371C Fabian Keil <fk@fabiankei | 34A5FBA4 | | 8192R/0xB431B67770E4AA38 Mikal Villa <me | FE305F8E | | <hneal AT imalazybastard dot com> | CF9E4605 | | <hneal AT imalazybastard dot com> | D12F66D6 | | <periplanetaamericanus AT gmail dot com> | 5B5213C4 | | <periplanetaamericanus AT gmail dot com> | 47D04EC4 | | <periplanetaamericnaus AT gmail dot com> | F19106D7 | | <support at gkware dot com> | E754AA99 | | <support at gkware dot com> | 868A253C | | <support AT gkware dot com> | 48674035 | | <tech AT dana dot io> - 1AgYtavutLAMxUYM | 752DA4A4 | | <tor .AT. jgjtech .DOT. com> BTC: 1QHXLy | 0DA71D95 | | <tor .AT. jgjtech .DOT. com> BTC: 1QHXLy | 31A40828 | | <tor AT 1d4 dot us> - 1N7sBLKvekRD4EUL2b | F1107CB0 | | Abuse Department <abuse AT hartvoorinter | 81B75D53 | | Abuse Department <abuse AT hartvoorinter | 89E3170B | | abuse<__aT>icetor{_DoT===}is - 1GDerBXAJ | 1D9D1C1D | | anders.io | 91361C96 | | anders.io | D56AA4A1 | | anders.io | 3A2192F5 | | Bauruine <torcontact aatt tuxli.ch> - 1C | 63C1904F | | Bauruine <torcontact aatt tuxli.ch> - 1C | 52F7C67B | | BFC62AD3 johannes <tor (@) kontrollappar | 750941D5 | | Big Jim Slade <sysop AT bigjimslade dot | 9AFA555B | | Big Jim Slade <sysop AT bigjimslade dot | ACDC9C49 | | DFRI <tor AT dfri dot se> | A10C4F66 | | DFRI <tor AT dfri dot se> | DD8BD730 | | DFRI <tor AT dfri dot se> | EC84E232 | | DFRI <tor AT dfri dot se> | A478E421 | | Fabian Keil <fk(a)fabiankeil.de> 8BA2371C | 5CE3AD8A | | General Zod <zod(a)kdf.mil> | 556D59FA | | General Zod <zod(a)kdf.mil> | CBABC09D | | GetReal <x50 AT riseup dot net> | 51529D02 | | http://www.onion.network/ <info at onion | F89A5238 | | http://www.privacyfoundation.ch/abuse/ | DC41244B | | http://www.privacyfoundation.ch/abuse/ | 0111BA9B | | http://www.privacyfoundation.ch/abuse/ | DE7DE889 | | http://www.privacyfoundation.ch/abuse/ | 487092BA | | http://www.privacyfoundation.ch/abuse/ | AD86CD1A | | http://www.privacyfoundation.ch/abuse/ | 95DA61AE | | http://www.privacyfoundation.ch/abuse/ | B060482C | | http://www.privacyfoundation.ch/abuse/ | 88487BDD | | https://www.torservers.net/donate.html < | 4E021F36 | | https://www.torservers.net/donate.html < | F657ACB3 | | https://www.torservers.net/donate.html < | 64D500C4 | | iggs <tor.20.iggs AT spamgourmet dot com | 2F557D48 | | jvictors at jessevictors com, PGP 0xC20B | C6DC982A | | jvictors at jessevictors com, PGP 0xC20B | 4B8C39A5 | | jvictors at jessevictors com, PGP 0xC20B | BFA0E9F3 | | jvictors at jessevictors com, PGP 0xC20B | 40DF7E2E | | Kevin <tor AT kberanek dot com> - 14BTbA | 92EA887F | | Kevin <tor AT kberanek dot com> - 14BTbA | A1E02458 | | kingbiskit(a)gmail.com - 18gEJokSQ3uwo3QTM | C921704A | | kingbiskit(a)gmail.com - 1CoXRRwDt6YVTZmJ3 | 3246AF7B | | M.K. Nitrox <mk DOT reg AT t-online DOT | BD912646 | | montanisemperliberi <a> safe-mail.net | E8B6E46B | | Nicholas Merrill <nick AT calyx dot com> | 51BFE90C | | Nicholas Merrill <nick AT calyx dot com> | 0B5E5E70 | | Nicholas Merrill <nick AT calyx dot com> | 84D361B7 | | Nicholas Merrill <nick AT calyx dot com> | E4D1F25D | | Pascal666 at Users dot SourceForge dot N | C9437269 | | Pascal666 at Users dot SourceForge dot N | 5B7AEB14 | | Peter Palfrader | 847B1F85 | | R P <edschlonz AT yahoo dot de> | FF06E7A0 | | Samuel Whited 0x54083AE104EA7AD3 <sam AT | CA54C9F2 | | Sebastian <tor(a)sebastianhahn.net> - 12Nb | EBE718E1 | | snIP3r <sniper(a)restricted-area.de> | 3EE8D536 | | tor TA fejk tod se | 2AFE9201 | | torelay [ANTISPAM at] ruggedinbox [ANTIS | 0559A3D3 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | BAACCB29 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 0B454C7E | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 5A551BF2 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 4436A57F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6D3A3ED5 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 75C4495F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6A29FD8C | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 0C77421C | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 8073670F | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | B35C5739 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | E6E18151 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 6A37488D | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | E11B6AE1 | | torpids AT yahoo dot com - 1JYHfzVFVD7n2 | 70C55A11 | | Torservers.net <support .AT. torservers | 488239E0 | | Torservers.net <support .AT. torservers | 6B1E0019 | | Torservers.net <support .AT. torservers | C46524E5 | | Torservers.net <support .AT. torservers | 770BE0CD | | Torservers.net <support .AT. torservers | 5C84C359 | | Torservers.net <support .AT. torservers | 20B0038D | | Torservers.net <support .AT. torservers | 5714542D | | Torservers.net <support .AT. torservers | B4F883DB | | Torservers.net <support .AT. torservers | 78213EC8 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 4E918B21 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A494237E | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 35FEEA5F | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 2576BFB0 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A1025D32 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | C8D44E91 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | B7EC0C02 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | FFD6C2CE | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 4C6F66B1 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 43D0AB1B | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | A57B43E1 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 9030DCF4 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 3A5F08D0 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 5C1E076A | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 482A381B | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 2D671A4A | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 66CFF345 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 55F5CF9D | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | FEF59210 | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | B4A553CB | | TvdW <tor AT tvdw DOT eu> - bitcoin 1NKK | 92506510 | +------------------------------------------+----------+ ..based on onionoo.thecthulhu.com's data from 2015-07-15 18:00 [1] https://trac.torproject.org/projects/tor/ticket/16276 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVprfXAAoJEFv7XvVCELh0/FcP/28/dhefuPNQaBNSY59NTZTs snwb9vRlAzhDDm0XmWEMIaawFlNjV8shJD8dWvzSvynWHYQySfrStmDdfkpe5CSC lu9ceE6qhhZe+RkyDPM3PdxLhz29XVK+KvQcDcCeWp6nIHzXIOJL+Xk7v7FoU75S Vx8GjhVQd/aiHJQg96zlpdzkAsU000jG2E3Z2EH+gd4Uypl94wgqd0482LSSehiQ LVbhPt6C8NlX32kZ4yAD3W5cHRoyhg30x076X8XHZ16H6F2l801hhON5X32VmXdv vd/kJ7R9JKo4Uig1Y9hq3qpsRsO8aJaN2JOXMsGw2A+6eNFA2OPFLg3/sNKLgiLV N/CPqDlMVsotMDcXX4iBYSHW0Y+J7vyc5ezxE/rKWzBCBZSnK9Sb5UzcrDnOfJRO ABFv+ZtGxSQYVPcnICVdMr+3Kuk0FnKMm7z2ufYriRxDK573LQgNJQnjZ3Tc3JG+ PIVZun0IN/+1gZmQif57xIjW1OFDbDYbhMtYFYbK9zRd7PidIr5NHcYCkEY4whfP 2vhN4jbtYQZZY/hDAMLZVBKDJ42tOYG/8EaWZeMJ8y/pd+F8EvT7ceWzXwuhYm77 WiK4VsgFU7PR7ETi/DJL+ajmFEjpRJ8QOy3J5E/dq/eumkkzL/eBTPL7ydnTmD/u 9271J4DjQYPfjzVtVqdl =ecVW -----END PGP SIGNATURE-----

2 3

Re: [tor-relays] How to Run High Capacity Tor Relays
by Magnus Hedemark 22 Aug '15

22 Aug '15

I think it's unfair to characterize the Tor community as a Linux club, or religious about operating systems. There is a whole big world of operating systems out there, and most (not all) have a very POSIX flavor to them that makes it pretty easy to generalize advice on running the service. The work that I'm doing right now is around packaging Tor for OmniOS (and writing doc around using them together), which is pretty obscure and has no relationship to Linux. There's definitely software out there that assumes you're building it on Linux, running it on Linux, but Tor is definitely not one of them. Windows is the only really prominent OS that I can think of off the top of my head that has no significant POSIX flavor to it. Its heritage is more from DOS and VMS than anything. It's an odd bird for people who otherwise work in POSIX platforms all of the time. Be thankful Tor runs there at all. Supporting Windows on a cross-platform app is no small feat. Maybe instead of throwing shade at the EFF, take a stab at fixing the problem yourself? The EFF is not some multi-billion dollar software company, isn't staffed with an army of engineers and tech writers looking for something to do. And, if they were, I've got doubts that the cost/benefit analysis on supporting Windows as a relay platform would turn out in your favor. If you're really dedicated to running a big Tor relay, and can't be bothered to help improve the documentation for Windows relay operators, time to learn a new tool and maybe not be so religious about running Windows for all the things? I think I've got 5 different OS's that I'm managing right now. No big deal. That's the beauty of the other side of the Windows fence. Once you learn one, it's easy to learn the rest. -M Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------- Original Message -------- Subject: Re: [tor-relays] How to Run High Capacity Tor Relays Time (GMT): Jul 22 2015 12:14:56 From: ben(a)reefsolutions.com To: tor-relays(a)lists.torproject.org Robert: you're right. The group in general isn't very knowledge about Windows. I'm a Windows sysadmin and spent a long time deciphering the Tor documentation on windows and it's poor. Best info was another operator who posted on the mailing list months ago. I've reached out to the website maintainers and gotten radio silence on updating the Wiki for Windows. I've added other things to the wiki though (on exits). I'm a bit perplexed on the OS religiousness since we need more inclusive for Tor relays. We need a status of liberty, and the EFF's push isn't enough. Sigh.... -Ben -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of I Sent: Tuesday, July 21, 2015 8:29 PM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] How to Run High Capacity Tor Relays Moritz and all, I mean no offence to anyone since we're all in this for the greater good, but really approaching joining the Tor community is pretty hard if you are not a Linux wiz and know about servers or a number of other things. I have tried to look around the multitude of interconnecting links but a lot are out of sync slightly or are not clear because of presumed knowledge and understanding or are irrelevant because of evolution Wouldn't it be better to be clear and neat in the way Torservers guides are? Would someone presume the Torproject installation guide was not complete and know where to look? Robert > On 07/22/2015 01:34 AM, I wrote: >> https://www.torservers.net/wiki/setup/server has excellent guidance >> for setting-up relays seriously. >> Would those at Torproject think about linking to it from their >> installation guides? >> >> Robert > > https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines > links to it, as well as to > https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity . > Both these pages could use some overhaul, but they're not too bad. > > -- > Moritz Bartl _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 4

BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 06 Aug '15

06 Aug '15

FYI list https://trac.torproject.org/projects/tor/ticket/16696 Description At present both 'longclaw' and 'maatuska' have dropped out of the BW consensus ('longclaw' is restarting with new version, not sure about 'maatuska'). This has caused the BW consensus logic to revert to using relay self-measurement for BW weightings due to fewer than three BW authorities participating. The 10000 cap placed on self-measure values is causing super-fast relays serious demotion and slower relays corresponding promotion in the consensus weighting. Possibly this may result in network unbalance issues. Some adjustment of the logic seems in order.

10 12

Re: [tor-relays] what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Ended up reading rephist.c for awhile. Seems the up/down time is accumulated with downtime discounted %5 every 12 hours. So absolute worst-case age-out for 100% downtime would be something like .95 ^ 76 (35.5 days) to get down it to 2%. Since the outage is not as bad as that, the guard flag should show up sooner. Not interested enough to calculated the exact answer. Will just watch it.

1 0

what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Does anyone know how long it takes for the guard flag to come back after a multi-day relay downtime? Know that WTU (weighted time up) is 98%, and new-relay TK (time known) minimum is eight days. Reading rephist.c the the WTU is calculated from uptime history but rather then spend awhile to fully understand it seemed worth asking. Presently watching a relay that has been around six weeks, has been down four days recently and five total, has 14-day 100% uptime, Globe- calculated 1-month uptime of 85% and 3-month uptime of 90%. Had guard a couple of times but has not seen it return after the last outage.

1 0

my provider null routed my exit. advice?
by Christopher Yeager 31 Jul '15

31 Jul '15

Hello, I run a 100mb exit hosted at server.lu since sometime in late 2013. There have been a couple dozen abuse reports but normally they forward them to me to deal with and nothing much happens. However a week or so ago, while I was travelling, there was an abuse report that made them decide to file a ticket which then led to them suspending my IP as I 'ignored' it while I was gone. So now I'm trying to convince them to turn the system back on and they are pushing back, and after some back and forth they say they want me to run an exit policy consisting of ports 53, 80, and 443. I've been running the suggested reduced exit policy since day one and am very reluctant to pare it down further, and certainly not to just 3 ports. I wrote a short note explaining my point of view and I wonder if any of you would do me the courtesy of telling me if I am likely to convince them to let me leave the exit policy alone. I'm very willing to edit my response as required. I think it bears mentioning that I am several messages in and I did not get a good sense that whoever I am talking to understands Tor very well at all - I was repeatedly asked to find and block my customer, and told I must have logs if I provide a service, etc. I can show you the longer exchange if you think it might be helpful. Thanks in advance and here goes: --- Hello, We have nothing against Tor but IP is listed at 11 blacklists including Spamhaus ZEN. So we have to ask you block all ports except 80, 53 and 443 to prevent scan, spam and other infringing activity from your IP. Hope such proposal will be suitable for you. Regards, ROOT S.A. --- Hello again, I would rather not block any more ports that are already blocked. The system is already set up to use the reduced exit policy detailed at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which allows as many Internet services as possible while still blocking the majority of TCP ports. Currently, the policy allows approximately 65 ports. I am reluctant to further reduce the ports because there is vastly more to the internet than just the world wide web. Email, chat, remote desktop, cache, and vpn services are all valid uses of the network that would not be allowed by such a restrictive exit policy. I'm also afraid that it will not help much in getting this IP off the various blocklists that it is on, as 2/3rds of the abuse reports I've been sent were due to traffic on ports 80 or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related are simply reporting to the world that this system is a Tor node. The system is only in the Spamhaus Zen list due to its listing in the CBL for being "infected with, or is NATting for a machine infected with s_vawtrak" which is a Microsoft Windows virus that connected to their sinkhole IP on port 80. Being on blocklists is something that happens when you are running a Tor exit node and supporting Tor means putting up with them and explaining why Tor is worth supporting even though abuse is guaranteed to happen. Naturally if you require this change I will be forced to make it. I hope, however, that you can be persuaded that it is not helpful to Tor and will not solve the problem of abuse and blacklists even if it were. Thanks again. -- Thanks for getting this far. I await your replies with interest. :)

3 2

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Welcome. This event led to my discovering the Unmeasured=1 flag in the cached-*consensus files (was wondering where it was). That new BWauth is badly needed. See about 460 unmeasured relays and from an unscientific sample it seems like many of them are stuck-at-20 exit nodes--valuable resources that should be utilized. At 15:17 7/30/2015 -0500, you wrote: >On 30 July 2015 at 12:14, Tom Ritter <tom(a)ritter.vg> wrote: >> Thanks for the heads up! >> >> A fifth bwauth is expected to start >> voting "real soon now", and I'm >> not sure why maatuska didn't vote >> on bwauth data last vote, but I've >> pinged some folks so hopefully we >> can get this resolved quickly. > >Aaaand we're back! =) Sorry for the outage. > >Bandwidth scanner status > >maatuska 6890 Measured values in w lines >gabelmoo 6444 Measured values in w lines >moria1 6754 Measured values in w lines > >-tom

1 0

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Much of Tor traffic is from long-term circuits moving bulk data, so apparently it will take many hours or even days for rebalancing to fully take effect. Is not clear whether it will cause serious trouble or not. My thought is that one BWauth in a consensus is better than self-measure, as BWauths are trusted entities and a single rouge BWauth in some kind of attack taking out the rest would be dealt with via manual intervention or the closing down of Tor. Perhaps the self-measure cap of 10k should be raised as well. Was an anti-gaming mitigation from the pre- BWauth days and may have even preceded the arrival of super-fast relays. At 12:14 7/30/2015 -0500, you wrote: >Thanks for the heads up! > >A fifth bwauth is expected to start voting "real >soon now", and I'm not sure why maatuska didn't >vote on bwauth data last vote, but I've pinged >some folks so hopefully we can get this resolved >quickly. > >-tom > >On 30 July 2015 at 12:04, <starlight.2015q2(a)binnacle.cx> wrote: >> FYI list >> >> https://trac.torproject.org/projects/tor/ticket/16696 >> >> Description >> >> At present both 'longclaw' and 'maatuska' have >> dropped out of the BW consensus ('longclaw' >> is restarting with new version, not sure >> about 'maatuska'). >> >> This has caused the BW consensus logic to revert >> to using relay self-measurement for BW weightings >> due to fewer than three BW authorities participating. >> >> The 10000 cap placed on self-measure values >> is causing super-fast relays serious demotion >> and slower relays corresponding promotion >> in the consensus weighting. >> >> Possibly this may result in network >> unbalance issues. Some adjustment >> of the logic seems in order. >>

1 0