Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles oder https://chat.rc3.world/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles or https://chat.rc3.world/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






[Music]
[Music]
 good evening hello good evening hello welcome to Millie Bo and the evening the evening talks at mway uh on day three I hope you had a great day already and we'll have a much greater day even in the evening today with uh nice talks um the next the next talk will be held by the network team of the tour project and they will present us uh with a guided tour through tour networking health and
[Applause]
 performance thanks everybody for coming um we have collected a little group of people from the tour project here who's going to talk a bit about General Network status thing and particularly will focus on the health and the performance that we've been working a lot on in uh in the past few years so I'll just do a quick introduction of everybody I'm Alex I'm heading up tours Network team we're the team responsible for writing the SE tour implementation and the rust implementation that we'll be talking a little bit about called Arty um then we also have Yuga on stage Yuga is one of our bandwidth scanning experts and work together with G who is the Network Health Team lead um finally we have Gus who is uh heading up our community team and is uh doing a lot of the engagement with people in our community and the relay operating community and so forth so if we start out with talking a bit about some of the features we've been working on for uh the currently stable Tour release called 047 one of the things we built in that was congestion control tour had originally not had any sort of good mechanisms like we see in TCP with the with regards to congestion control and handling congestion in the network which led to um a higher variance in sort of error conditions when um when um when you were using tour and the the performance was uh not so good so what the team did was that we evaluated a number of different options for congestion control algorithm people who are into some of these TCP things will might not notice some of the names are similar they're very related from from sort of the general Network World um the3 uh system we looked at was called Westwood and Vegas and Nola um while the team was looking at it Google also came with a paper with a congestion control system called bbr but many of these systems suffered from some issues that led to these runaway congestion conditions which made them unsuitable for what we were trying to do we um we ended up uh spending a lot
 of time uh working in a simulator that we have called shadow where we tried to test the different algorithms for seeing how they were performing having an idea about which parameters we could tune in various conditions and see how things are doing these plots are a little bit difficult to understand they're CDF plots but uh the idea here is that the uh orange part of the curve is um is the 047 release and the blue part is the 046 release and um the left picture is a simulated instance where we try to behave like where client being in Germany and on the right hand side we see one in Hong Kong and what basically these things tell is that we see a higher amount of the traffic being um being performant for for the new system in um we are sort of moving towards this new release that are coming very soon uh where we have then decided to remove some of these algorithms because they're simply unused and Vegas is the only one currently that is left we will continue to tune on these things we will learn as as more clients are coming on as we do various upgrades in the network so we would likely have to tune different parameters and the entire system is made so that the directory authorities which is the notes that are sort of the trust anger in the tour system will be able to tune certain parameters based on various like ideas or experiments we want to try out so all of this sounds good and many people will sort of say okay is it then going to be super performant or how is it actually going to going to change things as some of you may know we have had a denial of service going on on the network for for quite a a while so uh I'm trying to show this using some fairly old plots um and then show it with some very current uh plots after the network has upgraded to to the 047 so if you look at this one this is uh the time to complete a 5 megabyte download to a public server over the tour Network as you can see the variance is very very high in this we have some error conditions wh
ere it took up to 50 seconds for for for sort of these requests to go through and most likely the user will have abandoned the web request that was happening there so after we deployed congestion control it now looks like this we're down to having sort of a 20 second boundary on this and it's starting to look a whole lot better and you will likely also experience this when you're using tour browser in your daily life uh because ideally the request should go through quickly right I believe there's a lot of you in this room uh or in this on this stage that uh is operating uh tour relays a massive thank you to to everybody who upgraded to 047 very very very quickly yes big round of applause for that it is so important that when we get releases out that they get deployed to the network because many of the releases that we make requires us to upgrade the network before we can start upgrading the clients so before we can start including these features in for example tour browser or other applications that uses tour then we need the network to be upgraded so huge thanks to everybody who is uh who's been doing this we um I think last week I've been camping for a while but last week we released the uh release candidate for the tour 048 just like with 047 which had the congestion control feature there's some pretty important features that I'll be talking about in a moment which uh which is coming out in this release so we really hope that people will be very very Snappy with upgrading uh quickly again so we can start testing these things out on the on the live Network so one of the big features that we are adding in 048 is very much related to this denial of service attacks that we've seen um the the nature of the denial of service attack is not so that there is one denial of service attacks we've likely seen many different kinds of attacks that's happening within the network but sort of because of the design and tour we can't really go in and say and pinpoint what exactly is
 happening but we know that some of the attacks is happening towards onion service traffic which means that it stays within the network and never goes out over the exit nodes so one thing we've implemented is that we have implemented a proof of work scheme um some of you know these from uh from blockchain projects and how they are uh burning down our planet um this uh this system is designed in a way so that by default it's not enabled but the onion service if it U sort of realizes that it's under attack on various Network condition seems bad it can enable it and slowly sort of increase the uh increase the sort of difficulty that is used for clients to to to connect we have uh chosen a scheme that we got uh help from from a country contributor called tivador great thanks to to them for working on this if you interested in sort of the technical details about how this scheme works we have this proposal called uh 327 which includes uh all the technical aspects for how to implement it and as of last week I believe uh we also have the documentation ready if you are operating onion services for how to uh how to use this feature and and testing it out in your production system um there is uh one slight catch with the with this uh proof of work scheme it uses quite a lot of memory which means that particularly for Apple's very closed iOS platform we are likely not going to be able to enable it um it's Guardian Project who's doing the Orbot for iOS and because of uh Apple's Network extension memory limits we are very unlikely to be able to support it there but the effect will likely be the same as if the feature was not there namely that if there is an error condition happening for the uh for the given onion service then decline will simply not be be able to reach it and this will just impact iOS users more if you know anybody who works for Apple then please ask them to bump this limit uh it has been bummed a few times but it's still a bit uh bit too low for us at least the 
uh the big feature that is going to come in 048 is a feature called conflux historically uh most people in here is probably aware of that uh when you have a torrent circuit you have a decline which connects to a guard node and you extend it to a middle node and then finally to an exit node where you then make your TCP flows out to the internet one of the um API features that we have now inside of tour from the congestion control system is that we can get information while the traffic is being sent and received on how congested the link is this allows us to utilize this conflux feature to create multiple legs into the network and um sort of rendevu at the exit node and then the client can learn which of these two paths through the network is the least congested and switch over to transmit and receive on that one so hopefully now that we have seen with the congestion control part that we have gotten the variance of errors and delays down then we hope with conflux we'll see sort of a greater performance when you're when you're downloading larger things and and using the Detro Network in general one of the um really nice thing was sort of uh this whole performance project we've been running in the network team for a while now has been sort of how the team has been working together and developing things we have historically used this tool called chopne it's sort of a little python thing where you can uh say give me a Tor Network with 400 notes and it then starts 400 tour instances on your computer and you can test things we also have a system called Shadow which is a like um a more powerful simulator where you can sort of simulate a whole tour Network and including having time change so we can for example simulate a Year's use of of the chor system over over like a couple of hours and we can even do it in our CI tool chain which has been uh really really awesome um one really nice thing with sort of how we work we work like many uh many research projects so we get grants
 to do our work we um often these denial of service conditions that happens have this impact that we need to drop everything we're currently doing of deliverables and switch over to doing uh like mitigating the attacks we fortunately now have a sponsor um where we can uh do some of this work on denial of service if something comes up and if we need to tune things or if we need to come up with new mitigation techniques for people who are sort of nerding out on our gitlab then these things are tracked as uh like gitlab has this label thing and we have a denial of service label and we also have a sponsor 112 So if people are interested in seeing what kind of things we are are planning you can go look there how many people in here have heard of uh Ry okay not so many um is our attempt uh hopefully it's going to be successful with trying to write a rust implementation of tour that will eventually replace the C implementation one of the issues that exist with the seor is it it's a very old application by now that has sort of evolved over time it the the architecture of it is not really fit for sort of the modern day world with how we do applications how we have mobile applications and so on so R will become a uh primarily an API for working with different kind of tour objects like our D Network documents and making circuits and these kind of things um and it will eventually allow you to both build a tour binary like you're used to having today where you can connect over a sock Port but it will also allow you to have a tour implementation embedded into your applications if you want to do certain things um and finally it will also of course support onion Services we um it it's it's not an a sort of an easy decision to to make that you want to rewrite like throw away so many years of of of work and then try to rewrite it in another language we uh do some assessment on our uh uh issues when we have issues that we consider that they have such severity that they would be consid
ered security bugs and we could see at some point that 21 out of 34 of what we call troves they are bit like our internal cves where we have some different categories that we use uh would be highly unlikely to to happen if we were using more memory save languages such as rust another big component of this is that the network teamour is much more excited about rust than they are with with c and developer happiness is is fairly important as well if we look a bit at um the uh the road map for R um we are now at the point where we are working on onion Services we've just entered the year 2 funding for this um there's already stuff that uh if people want to try around around with having sort of a little rust Library where you can build onion Services then you can start trying it out today uh the goal is that when we are at the end of this year the browser team atour will be start uh to be able to play around with embedding Rd into the uh into the browser we are currently working on getting funding for building um relays and bridges and directory authorities and all these sort of things that are hosting the network but for now we are sort of focusing on the client side because the way tour is designed the client side is sort of the diff thing to build right now it's um almost the majority of the network team atour is is working on RD or Rd related deliverables we also have a little VPN project that we're experimenting with that uh that is also getting some attention we hope to uh very soon have sort of the entire team focusing on this we're currently three people out of 10 I think that is sort of left focusing on on seor what you will most likely see is that we will start limiting client features so only do the things that is needed to upgrade the network and then do the um do the client features primarily in um in in Rd itself one of the big things we want to work on soon is uh UDP for example UDP will have a network upgrade in the c tour implementation and then it will 
have feature support uh client feature support only existing in Rd we will of course continue to support c tour for until we're ready to replace it it would be crazy to do anything else if you're interested in tracking some of these uh engineering efforts that we're doing um I believe that U one of the nice thing we have with Rd is that it will probably be easier for for more people such as yourself to contribute uh the c tour code base was a bit difficult to get uh sort of wrap your head around when you're just diving into it we have an IRC channel tev on of on the ofc network and we also map it over to uh to Matrix as tev we have our gitlab uh account uh well our gitlab instance where you can attract Le engineering efforts and what we're doing and so on if any of you are interested in this you're also welcome to come and find me here at camp and and talk a bit about these things now I'm going to pass the mic to Yuka who's going to talk a bit about bandwidth
[Applause]
 scanning so bang with the scanner um we need them to monitor the T Network performance to better distribute the load across the network and to help to verify relays bandwidth because the relays themselves report the bandwidth they see that pass through them but uh there are no other relays to verify them to verify that so how it was um uh the scanner build two hop circuits between the relay that wants to measure and another relay that uh helped to measure this relay with double bandwidth um then download uh data through this circuit and write it in a file uh every hour the this file is read by the director authorities and they vote on the consensus way this is a graph of the number of Rel H measures by the bang with the scanner by each directory Authority in the last four days uh what is new now is that we have also a bridge scanner the bridge scanner was in a very similar way but it creates uh three hops circuit and this helps with the uh users to have a better experience because now instead of just Distributing the bridges that are available the bridge Authority is Distributing the bridges that which bang with thol bang with ratio is over a certain thol and this is a graph about the measur bridges in the last days uh the ones that were accepted over that ratio and the ones that are not oh um and then gecko is going to talk about more Network Health things thanks looks good thanks all right so you you heard already from Alex and Huga a lot about the performance angle of Network Health work but as you might know um there are many more things we have to consider um once we want to think about whether a network is in a healthy state or not so we have a project Alex has been mentioning already which we are currently focused on which is trying to defend more um effectively against malicious relays which is a um considerable issue for the torenberg for a long time you might have heard about this you can see the nitty cre details in the blog post I wrote um a while ago b
ut but having malicious relays on network is definitely not good for the health of the network overall so what we want to do is um um improving the the state of the uh of the art uh which is currently um yeah deployed and which we currently have as tools um but that's only one of the things which needs um improvements because as we have seen um over the years of fighting malicious relays just um setting on and on having more and more sophisticated tools to find and hunt down and and kick out malicious relay is not is not going to fly over the long run there's no way to win to win this arms race in that way um we have to have a um a kind of a social approach as well um a different tool in our tool chain for for for defending against just Rel is that way guess we talk um a bit about that what we have in in mind and what we plan in the next couple of of weeks and month um but that that's is an important thing to keep in mind there's no technical Only Solution against malicious relays in the uh in the tow Network and we are working on on that part getting this right um and the other important point when you're thinking about Network Health is that there are a lot of relays attack relay attacks which we have seen oh sorry which we have seen um over time over the years in in practice and in mentioned in papers we never found time to actually address those um in uh in our day-to-day Works um we got funding for that um I talk a bit later about what those attacks are we have in mind um Alex mentioned already one which is Dos one which is a really hard one um because we have seen um in the uh in this year DS attacks which were kind of four different DS attacks coming to the network at the same time and all four of them would have um needed totally different approaches to tackle them one Alex mentioned already the proof of work thing and there are other ones but we we want to make progress on those things as well in the uh in this upcoming work and the timeline for the project
 was um October 22 to October 24 that we are kind of in the middle of where we um um where we are where the work on on this part um we have actually to dig a bit deeper it's not just um fixing you know tools for detecting malicious relays or fixing those attacks we have to redo our Matrix pipeline as well the reason for that is um it's not as I said it's not really enough to have you know tools for detecting malicious relays and then kicking them out sometimes we have seen really persistent attackers in the network um doing attacks over month and and sometimes one or two years so and we need to detect those things earlier and and we need to do those uh detections by by not having only compressed tobl um of descriptors and consensuses and whatnot over over month and years as we have it now because that's really Compass arm to work with and slowing things down so what we want to do is um we want to redo our metrix pipeline uh in a way um as you can see on on this picture here so we have a a downloader um which is downloading all the the different descriptors and then macro descriptors and consensuses and it's it's writing things in an archive and at the same time it's putting things in a postrest uh ql database and then a Victoria metrix um piece which is is helping with a Time series and then we want to do a um restful API written in Rust where we can query stuff and having some shiny crana dashboards where you can easily see how things are going on this is um not just meant to be for our internal usage but of course at the first um time we will be the the ones dug footing our stuff but they we we plan to somehow expose this to uh to interested operators and The Wider Community as well can um dig through the data and uh come up with issues in the network we might not see and uh just play with stuff around at at some some point later we'll see how this goes um at the second um point we want to do um while we are working on this project in the metrix area is we want to
 build a small um service to annotate our um knowledge of the tour Network and this tool is called tag tour and it's basically like a relay search we have right now if you go to matrix. tour project.org there's a an option to to look at the uh state of your relays via relay search and what we want to do here is we um want to like to to add a little no or category to tour routers um where we can keep um State kind of state of tour routers uh which would for instance say hey maybe Gus knows the operator or maybe I am knowing the operator maybe R knows the operator and um and maybe you can annotate and say hey I've met this guy at at the camp or at the at dcon or whatever so we can see a bit um first how how many of The Operators we actually know because nobody is knowing this nowadays and then we can ask you know I know these these number of operators then we can think about hey how many uh of the of the capacity of the network do I actually know you know by operators this kind of stuff and and this allows us later on to build actually tools for our bed relay work on top of that gu we mentioned some of those um one one thing that got mentioned the past is we could say okay in order to minimize the risk for for our users we could just cap the um the the total amount of exit capacity a single operator can can run in the network right now it's not really a thing embedded in the code it's it's kind of um operators contacting us and saying hey I'm now running 10 % of the exit capacity is that okay or should I maybe do something else because it might be exposing too much risk to to your users and um but then we could think about building is a thing where we say okay maybe it's just allowed uh to for exit operators to run 5% of the exit capacity or maybe just 10 or whatever U but first of all we need to know how many of those folks we actually know to have a um an idea of um how many people we trust in the network by now so for the really attacks here are some of the things 
we we could think about and we are actually thinking about you can find more details um in this gitlab Milestone where we have a detailed description of the things we want to work on and measuring those attacks there are really side Channel attacks we have seen in the past U where users um got de anonymized we want to investigate and finally fix taging attacks um where we try to to uh to uh manipulate the routes of the network users can use uh not we but attackers um can use and we try to defense against that and do Texs already got mentioned we have some some traffic analysis papers resistance papers seen in the past and we we want to implement the most um um promising things from them into these uh into the code we have and then there are bandwith inflation attacks uh you might recall um hook are talking about the bandwith scanner one of the ideas was at some point building a bandwidth scanner which is um actually not really only measuring the bandwidth um but detecting um once relays try to um claim they are able to relay more traffic than they actually are um because there might be people around saying oh I I just you know set up this relay and um and whenever a user is coming I just um give it a really crappy service um trying to to minimize the cost I have for running a relay but once the bandwidth scanner is coming and measuring my relay I really I show there as a really big bandwidth I have available and that's why I get um a higher consensus rate which means more users are picking my router in the in the circuit uh and this kind of of of cheating and attacking the network we want to avoid at some point and there are ways we can do that actually and uh we are working in in in this project uh moving forward in this direction so I think um that's it for me I pass the the mic to Gus for the final por hello uh so this is a t isit node that is hosted here in CC Camp thanks uh uh article 10 for her running this relay so so I'm going to talk a little bit about the 
work that the T Community team is doing uh first thing that we need to acknowledge is that um Tor as an organization we develop the the software and as you see uh Alex talking about the complex stuff about conflct congestion control algorith algorithms uh Geo and H got talking about Network Health but there is one very important component that is the community who's running the software like without relay operators we don't have tar Network or we don't have tar right so uh the idea of the of this um to mitigate the attacks against T the ideas to improve the Network Health um the community health uh of the tar Network so we talked before uh on building tools uh to fight bad relays like creating scanners and this kind of stuff this is one way to fight bad relays but the other way is also using the social approach so instead of running scanners this is also we are going to do but the idea is to have a community that we know so we can say oh this person that is running one 100 relays we know them and they are cool people uh so uh the idea is to make the community harder for infiltration uh so one quick question uh please hide your hand if you're running a thir node okay I can see some people uh so according to our specialist on Twitter call it x uh Brew the NSA control a significant amount of t as it nodes something like 90% I don't know how accurate is this I love the day I heard the they steps nothing is truly safe so according to this random person on the internet 90% of people here are paid or are part of NSA right and this is ridiculous so we can see part of the Network Health discussion on the Internet is very low like uh they people do randomly do claims about uh who is running T and just something that we want to change not about their reputation but also about um uh also about like uh knowing the community and showing the work that people are doing is also rewarding like people can when to be seeing like hey I'm contributing with the tar Network 10% of the exit
 capacity or uh 15% of theit capacity and this is very important you know uh so there are many adversaries against star but there are I I believe there are two extreme positions that are not helpful on this debate one is underestimating the problem like well everything's fine please don't remove my super sketch relays uh they are just happy relays so we have this kind of actitude and the other one is like a overestimation of the problem like oh the CIA is running the whole T Network so I'm going to use this other solution here instead of the T Network and this obvious uh doesn't uh a good solution right so uh one thing that we have been working uh to mitigate this problem of uh thrust on the T network is to create a process uh involving the relay operators um when hello hello is working hello okay so uh we have a a process uh involving the the T community so uh the idea is to have relay operators to submit proposals or ideas or comments or suggestions how we can improve the Tor Network and how we can improve the the health of the Tor Network uh we wrote very recently A A meta policy where you can understand how is the process how you can submit a proposal to to improve the Tor Network Health so some examples of proposals first thing uh first example a guideline for maximum consensus that Geo was talking here uh other thing was um allowing uh allow a limit total consensus as a fraction by by family so if you are running a family of asit no you can only run 10% of theit capacity no matter what if you add 100 more relays it will always be the same this is a proposal is not approved we are evaluating this kind of ideas um and also we have another proposal like um another example of proposal of how you can conduct open source investigation when you're hunting malal relays so one thing one problem that we sometimes we have people report uh that are relay is bad but when we ask them like okay how that relay is bad what they are doing uh the person doesn't explain how they 
came up with that result so if we cannot reproduce that thing we cannot say that's a bad relay right and uh and if you look on for example in in Twitter and social media and other places you can see like sometimes people saying crazy stuff about exit noes or relays saying like uh well this as it know is clearly malicious because you can see by the contact info and sometimes Rel operators are very uh funny people uh they sometimes create names of their associations as CIA about confidential integrity and authentication so uh sometimes people are very funny and and you users are not they don't think that's a funny thing so um this is um this is why we a guideline to have a to help people to do open source investigation so uh because door network is a public network we should expect that people are checking uh their relays right uh and see the the behavior of this relays uh another example of a proposal that was recently submitted from the community like uh we have a limit of uh how many relays you can run by ipv4 so before was true uh and the idea was you cannot run with one single ipv4 address you cannot run 1,000 relays So to avoid this kind of attack it was limit limited to two uh we bumped that number to four because some relay operators wrote a very nice proposal saying hey the ipv4 is very expensive and we have Hardware we have Capac we have bandwidth the only thing that we don't have and very expensive is to buy a pv4 so the idea was okay we can bump too far and see how the attackers are going to uh uh act what's the their behavior if everything's fine we can bump to eight so right now you can see that we have uh you can run eight relays per ipv4 um and that can that created a very interesting graphic here you can see that before this proposal we were like 100 uh 1,500 relets as it no sorry uh and now after this proposal was approved we have now almost 2,500 rels so this is how a policy made by the community and endorsed by and enforced by the T project just ho
w we can change the T Network right so sometimes we believe oh how we are going to increase the T netor capacity or how are we going to make uh more people to collaborate or make the T Network faster sometimes is a not an engineer thing but also a policy thing like a something that something that we can change on the T codes something we can change on the tar network uh so the next activities that we have here in the camp uh tomorrow we have the T Relay operator Meetup uh you don't need to be running relay to join just Meetup if you are interested on T if you have questions about t or is snowflake or other plugable transport that we didn't talk about that today well you are welcome to come and and ask about this is going to be on barnack Village at 4 pm and um you can also check this very cool project from article 10 on their Village I don't know how to pronounce German so I'm not going to direct to pronounce this um and you can check their exit noes on on and make questions like uh article 10 is one of the top one of the largest uh isit operate operators uh on the T Network so if you are think like oh NSA is running a bunch of relays actually it's probably article 10 nothing to hide that's the operator for Netherlands uh many other operators here in Germany so you have opportunity here to I believe meet 40% of the t Exit capacity so if you walk around and talk with people you are running the T Network and and uh and we have the uh another campaign happening uh with electronic front foundation called the Tor University challenge it's University but means education so if you have a school if you have a education project you can join this uh challenge the idea is to have more universities running vs uh and you can see in his website uh how many V how many universities are running rels and uh if you want to be part of the Tor Community like running relays there are other ways to contribute with the Tor project like uh doing trainings translation Etc but you can also jo
in as a operator uh we have a mailing list that's open and you can subscribe we have the T Forum uh is a very easy tool for newcomers to join and talk and ask questions uh we have Matrix and IRC to chat with us and we have monthly uh online meetups uh that are announced on the T relays mailing list um but if you cannot runn a relay you can also run a snowlake proxy again uh we have uh more than 100, 4 100 more than 141,000 proxies of of snowflake which is are very important right now for people in Iran to access the free and open internet and to runlake proxy is very easy you just need to install an add-on on your browser and you can help people and uh yeah and uh very curious that uh Germany is also the top largest country contributing with isake proxies so again thank you for running a bunch of isake proxies and I think that's it from me great great Round of Applause a great Round of Applause for this tour through to networking we now have a Open Mic you can queue up here for a few questions so if you have a few questions please to que up back around the back please not running through the camera hey thanks for talk um I really do see that the attacks on the network are a big problem and I find the uh extra layer of uh social layer of trust you want to implement interesting I can see a few problems with that um but I mainly wonder if it might be it if it might undermine the spirit of tour Spirit of anonymity if I have to identify as a Relay operator to you especially in a country where to operate to operating might be illegal thank you uh hello ah here okay yeah so this is a great question about um transparency and privacy uh the T Network requires user privacy and who operates the T Network we require transparency it doesn't mean that we require uh phone number identification legal names uh your passport number we don't require that we require like a nickname and some some way to contact you so we are not requiring your to disclose your legal identity to the T pr
oject or something like that so I think this is very important because um we wrote recently a document about that like the T Rel uh expectation for T relay operators uh which we say uh running a t relay requires transparency so if you cannot do that uh maybe running a relay is not the best way to contribute with the T Network Maybe is running a training maybe it's localizing t maybe it's teaching others about t so you don't expose yourself to the T Network because the T network is a public network so if you are at risk maybe you should not run a relay thank you for these insights uh into tour development thank you for being here and I think we can find you somewhere if we have further questions find them oh
[Applause]
[Music]
 yeah