FIXED - Eth2.0 Implementers Call #5 [10/11/2018]

ya know so it's hold on in forged slime write something like 0.01 seconds in the Python implementation on the PI and we already know Python is horribly slow and [Music] multiply G 2 and ok so it actually takes about the same time as about the same time as a yeah pls multiple key or not as blsr es a a multiplication of G 2 points so and for very and then pairings I definitely take but considerably longer than that so I only expected to maybe add a few percent will be interesting to get numbers though still mean me yeah yes I mean benchmarks for me like ah like that in Java takes 0.2 milli second wide piling takes ten milliseconds yeah that sounds about right do we want to move on to the other client updates and dig into this later if we want to sure all right cool yeah look um whose neck harmony hello we've been working on at the station logic and now somewhere at the middle of the progress both also there were several small fixes that reflects late expect change which started to appear pretty fast and one thing that worse to mention is that we have implemented a multi service multiple a better service that it carries as much validators as gvm could hold and this is a pretty useful thing in terms of testing or in benchmarking because when we will get to be less logic implement it we can like have a thousand holiday while later sent measure the time of of have a signature creation and proposing this time won't include network latency but basically a network latencies could be emulated so yeah pretty useful thing for benchmarking so that's it now side okay how about lodestar so we're almost done our implementation of simple serialize we're going to get testing soon and packaging it up into an NPM module so expect that with them before Def Con also we're going to start writing a simulation percent functions and the beacon chain spec to just get a deeper understanding of them before we continue implementing and that's it on our end in terms of updates cool thanks about parody so we're building or shots for implementation using the the substrate framework so so far we implemented the state transition and that's our calling to the current Tyson reference implementation at least two weeks ago so we also have some basic skeleton for the for the networking collection pool etc so far it looks good for us so I mean the the circus is meant to be a general blockchain framework and we indeed get some benefits using that we don't need to read need to rewrite our blocks in poor logic or the backend storage so that's why it's slightly faster and for next I think we might be focusing on implementing some of the features in subjects that might be potential blocker for for Jasper so there are basically two things we found the first is of course blackboard consensus we haven't browsed the flog twice group are implemented according to the shots per spec and second is support of beautiful start routes so we don't we don't need that yet no but we will need that once we get the validator the validator try or something like that so yeah there's basically for us credit to have anything to add no probably no no okay cool thank you how about lighthouse yep we've been focusing on the block processing and block pre-processing and keeping up with a lot of the spec changes we've also drafted the simple serialize spec and and built some Yambol tests for some shuffling and handily splitting that way that we have that we have active release those yet we've also been looking at doing the networking side of our clients so that's looking at gossips up in rust and we kind of started going down a path of implementing gossip soybean rust is going to be our next kind of little venture yeah that's about from us cool and prismatic yes we did our little hope of concept ammo release and which rebus will they allow a single validator and like a network simulator to advance a beacon chain based on C transitions and we relaxed a few of the constraints and some parameters to allow us to happen so that was that was a big milestone for us another thing that we're working on right now is we're working on getting DLS integrated so be doing all the signature aggregation stuff we're dealing with some issues with finding a good go library that has a permission license and also you know has everything we need for 1203 81 aside from that we're also implementing the fork choice rule at the moment where we're using basically the last finalized lot left justified slot and current block slot as as a way as weighting factors and a scoring rule in the meantime what we wait for settling on the immediate message ghosts or like LMD so just wondering from the research team are you guys leaving worn out away from immediate message codes still thinking it needs to think about this more but definitely a very definitely looking at latest message you know i also mean an implementation of latest message in the beacon in the beacon knows in the clock disparity folder of the research repo you're all just to like like that again it's surprisingly simpler than immediate immediate message ghost in certain ways I see oh thank you yeah aside from that that's mostly what we're working on just getting all the BLS stuff and we're going to be starting work on simple serialize as well very soon go number yeah so in terms of updates we were more focused on a low-level business than high-level achievements in the past two weeks still we have implemented the sparse metal mackerel trees in and benchmarks should be coming I hope in the next two weeks it was done by someone outside the stairs through bounties so the timeline is not decided yet first one thing we are concerned about it's about so one of the goal of stereos is to support all devices mobile and desktop for the last five years and currently Limpy - he requires UNIX domain circuit so that means that it only works on the latest Windows 10 and for example it won't work on Windows 8 or something so we are challenging the p2p team on that also we hardened simple serialize or suppose I realized a premonition with regard to alignment and made the yes tech makes all proposition about padding and hopefully if we gets the some kind of test format decided today we can start working on tester generator so that we can test all implementations another thing is that it was more for EVM a wine point 1.0 but we had some lessons why I like dealing with unsigned int and some ins in EVM 1.0 and I hope to give some constructive feedback when we reach the EDM 2.

0 design about that and of focus for the following two weeks before pride it would be to create several benchmarks so that when at least everyone from stairs meets we can test the 2.0 on phones Reuters write Raspberry Pi and as some comparative points compared to or regular desktops and as a side note a bit of topic status has been moving away from slack to full whisper slash status desktop and we will be developing a whisper and Geetha bridge so to leave completely on the book chain right regarding the sparse Merkle tree is I don't know if people saw but I made a sample implementation for how to optimize them by basically layering but your expedition trees on top of them so you get the same kind of the same level of a database efficiency it in case I don't know that might be snap might be something that's uh other people Vitaliy where can I see it um I just did there oh is it there okay you Hey sorry my audio was messed up for a second um what was the question I was just talking using the patrician the question was where I could see it and the link has been posted just now into this chat thank you okay cool sorry I've been a little bit absent I'm giving up on YouTube for now and I'm recording locally cool now did I miss any client okay cool any updates from research I guess in general on this speck there has been as we've moved to maintaining it primarily in the github there's been a lot of rapid development a lot has focused on cleaning things up making things clearer making minor adjustments there have been some additions definitely but a lot of it has just been a lot of reorganization and renaming and making things cleaner for people that are reading the spec for the first time other than that what's going on research on the spec side one of the kind of bigger sites that's probably worth dedicating more it's more time to specifically is replacing like the possibility of replacing BM hash algorithm with some kind of merkel hashing enzyme aid and I mean a issue about on this I think it's issue number fifty-four so would be good to try to get a get more feedback or comments about this basically the idea is that instant that UUM and a kind of Merkel route but basically instead of hashing everything you kind of hash to the objects in a morgue Altria and the Merkle tree hashing is sort of done along the lines of these objects syntax tree itself because that makes things simpler in a bunch of ways and that's part of that we would probably merge the crystallize state and the active state yeah cool any other comments another more research update this beacon there was a nice little improvement here and all that was found so basically it's about housing randall against Oakland reveals so an orphan reveal is when someone makes reveals there Randall commitment but for some reason or another it doesn't go on chain you know it could be latency or it could be active censorship and the problem with that with often reveals is that when when the revealer is invited to reveal the next time everyone already knows what they're going to reveal so it's as if they they had already it's as if they had skipped their last lot so the simple solution is just to count the number of times that a revealer was invited to reveal but the no block proposal made it into the canonical chain and then when the revealer does eventually reveal then they reveal n plus one layers deep where n is the number of times that they didn't reveal on chain another nice piece of progress for the vdf is that foul coin has confirmed that they are collaborating with us on a 50/50 basis for you know on the financial side for the various studies so we have three studies and that we're looking to do and we're starting with analog performance study so basically seeing how much performance can be squeezed by designing custom custom cells at the the transistor level there's also been some progress on the state of the art of modular squaring so the team that we're discussions with reduced from seven nine seconds down to five point seven nanoseconds so that's a twenty percent improvement and they did that over the Chinese holidays I've also been spending some time thinking about how we would organize the circuit competition so we want to invite anyone in the whole world to basing some sort of circuit competition to find the fastest circuit you know there would be a large bouncy to a competition but one of the complications is in terms of which cell library do we use for benchmarking all the various circuits so generally the cell libraries are have a lot of IP protections and the vendors are not very keen to work with open source projects luckily I found so there's this 7 nanometre predictive PDK called ASAP seven which has been developed by academics and which is open source at least for academics so we're talking with them to have it to be able to use it for for everyone in our competition I mean the other nice thing about this library is that it's a FinFET library and we want to to design a a FinFET ASIC to have high performance in terms of the spec I guess I will gradually be spending more time on this back and just as a heads up I think the pace of change to this to the spec will will continue it will maybe even accelerate in the near future maybe all the way through the end of 2018 [Music] can you give some insight into that is that like radical changes to implementation or radical changes to the organization of the way that information is presented yeah so I mean I definitely agree with Alec that research has stabilized and although the key open questions have been thought through but there are you know lots of detail that needs to be written down and the existing detail also has to be tested there's also some not so insignificant changes for example what was talked about you know where we merge the crystal eye state and the active state that's a relatively large change one of the things that I've started doing is adding a to-do list in the spec itself I mean that to do is incomplete but it gives you an idea of the things to do I mean when you know outside of the content of the spec is just the presentation and the readability so one of the things I'd like to do when I have more free time is write something very similar to what I wrote maybe six months ago on if research for the what was called phase one where there's lots of clear definitions and you know everything is is very polished so I'm hoping that we'll get to that stage maybe in eighteen or early 2019 double-a Justin yes sorry about that I was just wondering you said there was some kind of increase in terms of the time it takes to do some swearing operation so does that mean that you're working this was starting with a specific fee noted mine and was there any kind of any kind of how to say if you reticle advances it's just an optimization that happened yeah so I don't have lots of visibility into how the the Chinese team improved the the latency I imagine it's all optimizations so you know one of the things that these Hardware multipliers have is these large reduction trees and you can try and be clever in the way you you organize the cells into what I called compressor modules and then how you arrange your compressor modules to reduce the critical path of the circuit and I imagine they did some and optimizations for that but I don't have that much visibility the specific group that we working in is it's just an RSA group so it's a two thousand bits modulus and we're just doing squaring and in that group so it's just mod modular squaring whether the modulus is fixed and it has size 2048 bits you okay cool anything else in research right now any update from you it wasn't Oh Kevin thank you oh sorry yeah and brother Charlie PvP Oh since I we merged the Python code Python lingo logics in PI via and POC Rico and things the cat DHT and other functionalities are done in the p2p demon so we're more actively testing lipedema and working on the Python bindings for it and we currently deployments scripting instable and terraformed on the way yeah and that's our update cool and I know shower has been hoarding a lot of the Python proof-of-concept stuff into IBM to start working on a more production Python implementation and I know she's a lot had ways they're kind of skipped that earlier with kind of date very cool Raoul from whippy-tippy couldn't be here but he has a handful updates in the agenda that he put there real quick the p2p daemon slash finding interface spec they've approved a merger nancial spectra would be to be daemon they've developed a go binding implementation that adheres the above spec I think it's in years evolution he'd loved any feedback asking about when the live the east to our teams are planning to start work on Python them and Java binding slow degrees Damon Olivia ballparks so they can line up support for ESU DHT support is now merged into the daemon we use the lead peach VIP ipfs we've shot peers by default but you can pass different settings and line options spec review and update some of us like each be folks are huddling up this week to review specs and bring it up to speed with implementations corresponding pgps extra go and Mike and Raul will be attending the to a meet-up October 29th and Prague if any of that was relevant to you check it out on the agenda and response row older cool next on the agenda testing we've made some efforts to define a general format for testing using Yoel it opened up a can of worms into how you actually structure those tests and where this test live in the format of those stuff it's something I definitely want to talk about in Prague because I think we'll have Dmitry there from testing and other people who have been in the weeds with the theory mono testing infrastructure but if people have comments and would like to discuss some of that today feel free to chime in right now yeah my opinion yeah echo yeah I think the best way forward is just to say well let's start with that on a small scope like simple serialized and see how it goes from there because other ones we were just talking without any physical well substantive stuff right yeah I think I think it's probably reasonable to use it for SSD and maybe like the shuffling algorithm and some of these little things not directly not like big chain test and stuff so in that in that sense I think I'm comfortable moving forward and then continuing a conversation and hopefully making some firm decisions in progress near Prague you you cool testing going once going twice any other comments okay Alexia's alternative tree storage structures from last time we didn't get a chance to talk about it Alexi would you like to talk about that today okay I kind of changed my intention slightly but I will tell you what I think now because I've done a lot of research since last meeting so I have actually quickly reviewed what the Chaddock posted in the I actually was aware of this optimization before I think I kind of do talk probably presented in June in whatever a meet-up but at least I thought I heard it there for the first time and I also thought about using the different types of tree for for actually for actually storing things in a database and this is where my current research is going so essentially I have this while working on turbo yes I'm trying to see where the basically sub optimality of the trade-offs go so that I am talking about the trade-off between update efficiency of the storage between accesses the efficiency of the accessing in storage and the the the storage efficiency in terms of size of the database so there's three things and I am starting to believe that we are very far from the optimal set of trade-offs in terms of how we do how we've done things so far and some of it will to do with the purchased choice of the with the choice of the the databases that we use and stuff like this but basically my idea currently I'm doing a proof of concept which I'm I'm hoping to finish in about three weeks but maybe in the next meeting working I can give you more data so that would be more convincing than the words but the main stages of this proof of concept so the idea is to create the sort of to fuse together the like some sort of B will not be tweet page but basically the bed database key value database with the temporal element so that you can store the history something that is a kind of lacking in Tobruk yes in terms of efficiency then with the native support for some sort of tree hashing algorithms and also with the easy easy ease of pruning so for that there's like four stages of these of this proof concept I'm currently on the stage two so the first stage is implement weight balance trees with tightest possible balance parameters and and made a recursive non recursive so that there's efficient bulk update so I've done this already and there are a couple of lessons I've learned but I'm not gonna do it right now so there's another stage to which I'm working now is that basically if you take the this binary search trees and then you start grouping that the sub trees like little fragments together is decided described in he's a article for the sort of you you group them together so that they fit in the page like four hundred forty four kilobyte page or something so for efficiency of storage and you then use some sort of split and merge split and merge operations in order to maintain this page size and so the the at the end of the stage I want to see how much as a storage efficiency I'm gonna get an efficiency when you mutate this we tape this page page tree and I will use the to pretend that I'm mutating aetherium State from the main net for example stage 3 is the maintaining the prune humble history of changes which basically introduces a temporal element to it so that not only I'm gonna store the the tree of current state but also the history but again the lesson I learned from the turbo gift is that when you store the history in such a way that the you record the updates relative to the past to the like a one block in the past for example so it's like I would I call forward Delta then it becomes really difficult to prune such a structure but if you start recording the updates the other way so that you always record the reverse diff from the car so they're there for your kind of your past records arose always reference in the future records so the pruning becomes a pretty much trivial and then obviously the efficiency of access or need to measure and I hope to finish the stage three you know about couple of weeks but maybe it's too ambitious it's just basically get some numbers around and the stage four which is the most interesting for this kind of call is that again similar to the italics idea is echo with embedding of the different tree hashing algorithm into the into the database so essentially you can use the patricia trees or sparse Merkle trees or AVL trees maybe and kind of in the same place as the WBT which is the weight balance trees at i'm using at the moment and so you can you try to record one hash poor page to assist kind of computing hashes which is again the current deter bagasse is lacking is that you can't go the fast sink or you can do that don't do light like line so when I've completed this proof of proof of concept I will know whether this whole set of ideas works or not and I hopefully could talk about it a bit more in details but yeah so my vision changes a bit and I think it's bit too early for for me to present the stuff because it's I want to see the numbers first but this is where I'm going you thank you yeah thank you um and to be clear if you're happy with the numbers what type of change would you be proposing okay so if I'm happy with our numbers one of the the outcome of the stage 4 which is the how you can essentially graphed the different types of tree onto the weight balance tree I would want to measure the overhead that you were gonna get so essentially the systems that will be based at night natively on this weight balance trees will be the most efficient by using the storage but the systems that will use different hashing algorithms will pay some overhead and so I hopefully will be able to tell what kind of level of overhead it's going to be and so if the overhead is let's say reasonably large so then I would suggest to consider by using the WBT trees instead of this forest Merkle trees because the main my I understand all these optimizations is you can do an SMT but my main complaint about sparse more poor trees with all this elegance and everything is that in order to maintain the Malon balance of the tree in adversarial settings you have to pre hash the keys you basically have to randomize the key otherwise if you don't do that your attacker basically will create like a really long sibling sibling kind of nodes which will always have a very long miracle proofs no very long I mean like 256 bits not bits but basically 256 things so if your keys are balanced or randomized then it's not a problem but as we see in like in the current aetherium we basically do it in double hashing or triple hashing of everything's like for example solidity is hashing the the keys of the Hat I hope the mappings and then you get these these mmm indices on storage gets hashed again before they insert into patricia tree and then you get another hash thing which actually happens over patricia tree so there's like but these particular things there's a triple hashing stuff i would like to have less hashing so for again for the performance resistor but again now hopefully have numbers later I'm not sure the key hashing is that big a deal given that in any of these three structures that but you needs to hash like a series number of times to do the tree updates in any case well the the tree hashing is basically it's not only to perform I understand it it's not like a biggest performance hit but at some point I had to optimize it away because it was going coming on top of my profiling but one of the things is creating inconvenience because you have to keep the preimage database and currently let's say in archive node in a serial preimage is about 16 gigs so if you want to like do it eration or anything like this you have to carry this pre image database with you right mm-hmm but let's let's kind of put it aside for a moment and we'll have more informed discussion when I have the numbers hopefully in a couple of weeks time okay the next thing on the agenda is just general z21 discussion there are a lot of things changed and added as we noted are there any questions or comments regarding everything right now also note that because we're using github for this there's a rich conversation going on via the issues and the PRS and would love more input there if you see something that's wrong or an issue please raise an issue and when there's PRS if it's something that you've been keeping your eye on or you understand or want to get some insight and feedback please don't hesitate to pop in but for now we have time to discuss anything if you want to one thing to ask about there will open the idea about three hash functions that Metallica is published I would like to propose to store big structures like what the data said in a tree but it seems to be a pretty avoid thing and since nobody has mentioned that before I know it is there any difficulties with that or just so we that we we mentioned it in the context of the as simple serialize rehashing that was the yeah the spec proposal that I had mentioned they here a few minutes ago I think it it was nobody that before yeah yeah but as I understand it's this is just a way of of making a hash from big structures now like do you mean stored well but what kind of tree structure are you thinking of here I'm thinking about just storing where they were set and they used in the miracle tree and maybe in patrician local tree maybe in sparse miracle tree it doesn't matter much and they used for example the public key is off in the tree the same structure like account states that are stored in gauge like what if the reason why we did things this way with indices is because the validator set is potentially large like it could go up to a few hundred megabytes and we wanted to be maximally easy to just store the whole thing in RAM so I basically I would be worried that having any more complex structure other than just a simple list for the weight is huge in efficiency will it be for this big structure in ROM is it really needed definitely but the entire thing definitely has to be in RAM because literally the entire validator set gets updated every time there's a recalculation so like first of olders like there's basically there's not that much benefit to a data structure that makes it easier to change small pieces at a time personally because we're teaching everything at once right okay then it's needed in RAM because every time you're pulling an ant a station you need to compute a group public key and from the validators and you don't know which validators you're going to have to have before you get the attestation okay good then I'm just wondering maybe we'll do it by myself one day just how much how big will be a footprint of all the stuff that we are going to hold in memory and anyway we will have to store all the structures in disk in case of restarts we need to load them from somewhere right so that's why trees are that that's why trees seem to be like good trade-off between storing on disk and accessing and the hessian okay hmm sorry are you saying that if you can demonstrate that you can store the Valladares efficiently in a tree such that it doesn't blow up too much eat up too much ram then it might be worth it I'm not sure actually because yep this is like this will be like when we are will have to dump the disk based what I did or said from time to time when it's changed and then when the app is starting load it from this to the realm right so this is what I am worried about a bit okay yep it's gonna be a huge structure that should be stored in disk in one time like maybe gigabyte or something like that hmm well if you dig into it any more and have more thoughts on it please share with us issues any other bt1 or I don't even know what version is anymore any other spec discussion questions thoughts so - sorry so to recap that we have just discussed we prefer to keep everything in memory right we need to be able to keep the crystallized state and memory in general and would any techniques that would make that infeasible would probably not be a road that we want to go down that said you're probably also taking you might be taking snapshots of the state maybe every cycle or so and storing them in your database so that at least since the last finalized state you could probably prune beyond that but there is you're storing the current in memory but you probably have references to snapshots of it in the database and you could potentially have multiple crystallized states right right you could have you could receive two conflicting blocks that cause the state transition one of which would be considered the head but the other maybe would be a close tie I mean a close second and in that case you would have two conflicting crystallize dates probably locally in your database that you would only prune later once you've finalized which direction the chain would go in do we have ideas on how much of the crystallites take updates in every round there is a maximum amount of validate or shuffling that can happen per cycle or every some multiple of cycles which is what Vitalik like three percent or ten percent I can't remember what was the three or ten this like it's like three percent of the routers that can shuffle is that is that what it is or I think more precisely 1 over 32 but same thing okay so that amount of the validates that can change on a roughly per cycle basis and then all of the different the shuffling which is being debated as to whether we should actually keep the shuffling in state the shuffling is going to change can change on the order of every cycle and all the other I guess all the other fields are a lot smaller but those can be changing on about every cycle so the full crystallites they changes every longer period there's no generational aspect that we can exploit the validator set because the Valladares that can only the volunteers that can only change every I think four cycles and only 1/32 of it can change at a time so you do have your validator set is essentially your largest component of the crystalloid state likely at any given point so you do have some generational things there all the other components are smaller components that those those can fully change and will fully change often even though it's true that the whole validator data structure will will change over a whole cycle don't we have bounds on how much king change per lot like 128 for example in which case wouldn't it make sense to try and all ties the costs on the slope by slot basis instead of doing a huge batch operation at the end which could be quite expensive for the shuffling of the VAT for bringing validator than in and out know for example like updating the balances and you know if someone made an attestation then maybe we can just reward them in the slot in which the attestation was made so they think the problem was that is that that would basically mean that we change one over 64 of the validators every time and the Merkel tree of but basically we would be doing something like six times more hashing than we're than we're doing right now because we would have to kind of update a bunch of work over extra merkel branches whereas currently would just reconstruct the entire tree or even currently we do hashing but like currently plus rehashing we would reconstruct the entire stream and yes it could be clear about the bulk of the validators stays stable but actually their balances almost although their balances would update every cycle so unless you pull the balances out into a separate data structure you miss I think some of your generational aspects there yeah got it you the devil is in the details any other shots on this stuff right now you cool I apologize for the technical difficulties and for my relative absence for the first half of this meeting um stay tuned in the spec Rico a lot going on there because I just finalized this location for our event I will be sending out details regarding the event that's of schedule and the proposed working groups shortly can I just ask one question if we are getting towards the end of the call yes might be appropriate moment a few sessions back someone brought up a question about aggregation of signatures and especially the question of whether including several times a given signature introduces any kind of security problems and I would just like to know whether it's a question of taste that would one would rather just prefer to have an aggregate signature which represents any given signature only once at most or if there's any how to say secured the reduction or whatever any kind of security problem with including any given signature multiple times I mean part of its I guess a better of taste but it's like if you started many better than Leah said of which keys are included can't be additional anymore and how's this for into some weird more complicated theater structure and exactly reduce efficiency ahead like increase in other ways so it might it might increase so the data necessary to untangle the aggregate signature but it might have to make the process of creating the aggregate signature significantly easier so I'm just wondering like is it a hard line no or should we be avoiding this or is there maybe a good compromise to be found I think go ahead I don't think there's any security implications I mean one possible compromise would be to replace the bid field with a two-bit field where everybody data has to bit and the signature could be included at most three times and that will keep the complexity and performance while low and high respectively right and the more bits you allow for a validator the more allowing to have for creating some multiple of complexity for calculating the group signature of the group public key I don't know I I would prefer to see a reasonable solution that doesn't have multiple aggregates multiple representations for aggregate but I build I agree that there might be some compromise there depending on the aggregation strategy offline and maybe some of the real-world results around that yeah and I definitely want to see real-world evidence first yeah of what kind um basically that like this allowing multiple multiple inclusions in his signature would and of substantially increase efficiency and so on you know or really increase efficiency in some concrete way okay right I'd like to keep it as a as an option you know adding multiple bits per validator in the bit field as an option depending on how what tests that results like rather than adding complexity at this point and I think we have some work still to define what that aggregation strategy is on the network and then so we do that again I don't want to add the complexity and the data structures well we're thinking about aggregation so we'll keep the posted as soon as we have anything we're sharing great and aggregation is one of those topics that I'd like to dig into in person at our Prague Meetup so you cool open conversation open floor any questions comments before we end this thing you cool thank you I recorded the call locally and I'm gonna try to get it up soon again my apologies for technical difficulties I'll try to let it happen next time question is one final question is do we want to meet on I believe it's the 25th of October it's that's four days before our in-person Meetup sorry between web 3 and Def Con you all think it would be worthwhile to meet them there are people available to meet a navy reactor would be nice to meet everyone oh you mean the coal you mean yeah I mean the call I mean sure behave I'm happy to do the coal so it just so I think we'll be in transit from Berlin to Prague on that day so it might be a little bit tricky for us you okay do a maybe and talk to send me all off line between now and 10 time mid next week and beside of radio called them it's I guess it's kind of the craziest time of the year like Christmas for aetherium all right cool let's end it I appreciate y'all gonna can't talk to y'all soon thank you very much thank you thanks