Hi everyone and welcome back to Plants and Lucia. My name is Lucia and this is Manny. Today we will talk about the beautiful ansurium and how to take care of it. Okay, coming up! Whether you're coming back or this is your first time in this channel, thank you so much for being with me and watching this video. This video is a remake out of popular demand because this plant is super beautiful and I made a video about it but it was a long time ago. So I wanted to make a new one with more information and hopefully it's useful. So let's get to it. Okay, so the ansurium plant is also commonly known as the Flamingo flower. This is because of the pink brights that it actually displays. Some people think they're these are flowers but actually these are leaves that actually are there to attract pollinators. And the flower is just a part in the center. So as you can see we don't have flowers right now in our ansurium but whenever it has flowers it can last for weeks and it is very beautiful. It is a very easy houseplant to grow so let's see how you can keep her happy at your house. So when we talk about humidity this is actually a tropical plant. So she usually likes moderate to high humidity. What I do to increase humidity levels with my plants is that I put them with other tropical plants because they tend to help each other with humidity. Another way to help with humidity is to put her with a humidity tray or close to a humidifier. In terms of temperature again because this is a tropical plant you want to put her in a place that is warm. So a room that is between 15 to 20 degrees celsius should be very good for her. When we talk about sunlight this plant likes bright indirect sunlight. So put her in a bright room but where she gets indirect sunlight. This means sunlight that is filtered somehow with a curtain or a place where she gets sunlight but it's not direct sunlight. So I would say not so close to a window especially if this is a south facing window. In terms of water you want to water moderately. So the way that I check with this plant if she needs water is with my finger. I put my finger inside the soil until the second knuckle and once I feel that the soil is dry then I water. I usually check the soil every week and during the growing season I usually water every week. In the winter the soil tends to take longer to dry out so I cut back on water. And of course the method that I use is my favorite method which is the bottom watering method. This method helps me get the water into the roots from below and once I'm done I make sure that the water drains down. So the soil is moist but not wet. I can tell you this method helps me so much to not overwater my plants. The way that I fertilize my plant is with an organic fertilizer. So any 1-1-1 organic fertilizer or 2-2-2 organic fertilizer is very good for her. And remember fertilize during the growing season. So here in Berlin for this plant it will be from spring to summer. In terms of body mix this plant is super adaptable so you can actually use an old-purpose house plant body mix. If you want to make your own I recommend that you use 7-part coconut foyer, 2-parts per light and 2-parts worm castings. Some of the most common problems with this plant include leaf tips turning brown. I actually had this problem with my plant because I had to put her away from other plants as they had some pests. The pests are gone but actually I have some tips of the leaves turning brown. So this came because because you have dry air around the plant or too much sunlight. In my case I think it is because there is too much dry air. So I'm gonna try to increase humidity now. Number two, too many leaves but no flowers. So one reason for this is that your plant is not getting enough sunlight. If this is a case just move to a brighter spot but remember not to put her in direct sunlight. Second reason is that the pot may be too big for your plants. This may be the case if there are more than 1-2 cm between the edge and the root pole. To solve this just repot your plant to a pot that is 1-2 sizes smaller. The third factor that may be causing lots of leaves but no flowers is that you are not fertilizing your plant. As I said before I usually fertilize my plant every 2 weeks during the growing season with an organic fertilizer. But of course make sure to check the instructions in the fertilizer that you get. Common problem number three, yellow leaves. This can be related to two reasons. First is that you are over watering your plants. So remember always let the soil dry in between waterings. And I recommend the bottom watering method to prevent over watering. The second reason for this may be that you are over feeding your plants. So giving her too much fertilizer. Organic fertilizers tend to be less concentrated. So with these it's easier to control that we don't over feed our plants. But of course it's up to you. Just make sure that you read the instructions when fertilizing your plant. If you feel that you overfed your plant you can stop fertilizing for a month or two. Okay my friends so these are some of the tips that have helped me keep this plant happy at our house. Make sure to always observe your plant because this also depends on where you are located. So this is a guidance but not a gospel. The most important thing is to observe your plant and see what works and what doesn't. Okay, do you have an answer by your house? How do you take care of it? Please make sure to comment below so we can all learn together. If you would like to be part of this community you're always welcome. So make sure to subscribe so we can see each other every week and talk about plants. And as always I will see you in the next video. Okay, ciao!


Okay, good morning everybody. I will start off with doing something that I don't normally do, which is explain a little bit about my day job, because that is kind of relevant for this presentation. So I work at Cisco Systems Norway and we make video conferencing equipment, anything from desktop systems to board rooms. And what makes those interesting is that people want to connect to a laptop for a presentation, to show a presentation. So we see Windows, Mac, Linux, laptops, AMD, Nvidia, Intel GPUs, HDMI and DisplayPort. So you get a wide variety of video sources that are connected to it. And you can also connect to Google, Chromecast, Apple TV, although the vast majority is presentation sources. So for those laptops, we are a display. We look like a display. So we have to prepare an EDID that works for all of these permutations and give a good result. On the other hand, we talk to TVs or PC monitors or an HDMI switch or what AV receiver. So we need to parse the EDID inside those displays and do the right thing. So EDIDs are really important for us. And we see a vast variety of both good and bad EDIDs. Now, if everything was perfect, I wouldn't be here and I would be out of a job. Luckily, EDIDs have all problems and pitfalls and complications. In other words, that's job security. So first, a little quick introduction. So that gives a bit of a background. Why am I interested in this and why I'm giving this presentation? Hopefully, everybody can take away something useful from this. First, explain the abbreviation. EDID extends the display identification data. It's basically typically an eProm inside the display. It doesn't have to be an eProm, but it quite often is. That stores the display capabilities. And the source would read it out and determine what it can send. There's no point in sending 4K P60 to a VGA monitor. It's pretty old. First version, 1994, probably based on earlier implementations that were unstandardized. So say 30 years. Originally VGA displays later extended to DVI, then HDMI and display ports.  And it had an HDMI to VGA adapter. And later, someone needed to use BC to HDMI adapter to talk to the change. So you have display port, HDMI, VGA. When you start dealing with those adapters, that's a whole...  How to read an EDID is specified in the Visa EDDC standard enhanced display data channel. It is basically an I2C communication channel, even over display ports. It's encoded over an AUX channel. But at the end in the display, it is still going over I2C. But you often see I2C and DDC interchangeably used. These eProms are specialized. It's not a standard eProm. Although I think if it's small enough, you could use it. But for bigger EDIDs, more than 256 bytes, you need a specialized eProm because you have some special extra I2C address. I'm not going into the details. I'm just saying these are typically custom eProms. As it doesn't have to be an eProm, quite often it's just a bit of memory in HDMI receiver that the display would write into at boot and that would then communicate over I2C. The current version that you will see is EDID 1.3. It's mandated by HDMI interfaces. I do not know why. I've never figured out why that is fixed at 1.3. If anybody knows, talk to me after the talk because I would like to know. The rest of the world typically uses either 1.3 or 1.4. Display port interfaces typically are based on 1.4. The differences between the two are really minor. Some flag, some bits have changed meaning. A few requirements in 1.3 that have been dropped in 1.4. It's not really small. Most EDIDs consist of 1 to 4 blocks. Each block is 128 bytes. The first block is called the EDID base block defined by VISA, the EDID standard, and there may be up to 255 extension blocks. Each extension block has an identifier and that maps to a standard that describes it. You typically only see CTA 861 extension blocks used mandated by HDMI and display ID which is defined by VISA. That's what you typically see for display ports. The reality is that typically, so in practice you can see different variations. I will go into that a little bit later. First, signaling. Actually reading out how does that work. You connect a laptop to a display. I'm sticking with HDMI mostly because I know it best and that is in practice what you will typically see in video conferencing equipment. Most often HDMI, but most of these things are also true for display ports. So you connect your laptop to the display. The laptop sends a 5 volt pin. Display sees that something gets connected. It will send back and hot plug the text pin with a high voltage. The laptop detects that and it sees that it is high and that means that it can safely read the EDID. That is, there is an EDID and it is not being modified at the moment. It is a stable contents. Then it reads the EDID over the DTC, aka IHBC lines, passes it, figures out what is a safe video resolution to use and then it can send the video to the display. Inside the display, I've shown it here as an EEPROM. That is where the EDID is coming from. Most cases the display will power hot plug detects and the EEPROM by itself using its own power. There are some cases where it is the 5 volt from the laptop that is actually powering the hot plug detects and the EEPROM. That allows a laptop to read the EDID even when the display is completely off. You don't see that all that often anymore. For example, we have been using an EDID emulator. This is just a little gadget. It's not a real display. It just emulates an EDID and that works in that way. I would say that about 98% of all the displays that we see powering themselves and there's a small percentage where it's using this loop idea. Hot plug detects has its own issues. First of all, the specs describes what it considers low and what it considers high. So 0 to 0.8 volts and it's low. You shouldn't read an EDID 2 to 5.3 volts and it's high. You can safely read an EDID and of course the obvious question is what do you do with the remaining voltages? They don't say. One problem with meeting rooms is you often have long HDMI cables. That means that the voltage can drop a lot. So usually if you want to support those long cables you put your thresholds in exactly that undefined area because it's always better to get a picture where possible than nothing. Interesting thing about long cables is manufacturers often make a lot of effort making sure that the video gets through but these voltage lines they don't pay enough attention. So you can have a long cable and if you just send the video it's fine but if you actually see measure the voltages then it might be that your laptop wouldn't even see the display because the voltage drops too much even though it could carry the video you don't see that there is something connected at all. Or you see it but you can't read the EDID because the EDC lines have the same issue with voltages. So it's an interesting thing if you buy long cables this can be an issue and it also depends on the laptop, the precise video source where does it put the threshold itself. So long cables, not all that easy. Another thing, if the whole plug detect pin goes low for more than 100 milliseconds it's supposed to re-read the EDID. It can be changed. It's surprising to me that quite often this does not happen. It's either assumed to, you know, it only reads the EDID at the first connection and doesn't expect it to change afterwards or it has some debouncing algorithm that is set to large. There's definitely something you need to take into account when you're writing, say, a DRM driver. This place often toggles the hotput detects when they switch inputs or go from on to stand by or vice versa. When you connect a cable or disconnect you can get pin bounce so you see the hotput detect toggling very quickly in a short time. So these are all things you need to take care of when you are writing software because these can all happen. So that's electrical. Let's now go to the meat of the story. So assuming that electrically you actually were able to read the EDID and now you're starting to parse. I'm using an example EDID. It is based on a 5k monitor but it's a Frankenstein EDID. So I removed some stuff that is not interesting and I added some things that are interesting so you won't find this anywhere in an actual database. But 5k monitors are a very nice example of a lot of the issues that you will encounter. So we start with the base block. All this is by the way output of an EDID decode utility. I will mention that at the end of the presentation. It parses an EDID and shows it in human readable form. So it starts off very simple. EDID 1.3. Vendor and product identification. I removed the guilty parties here. Actually not all that guilty. They were constrained by some of the issues relating to what they want to do. Basic parameters and features. So first thing, maximum image size. So that is supposed to be the size of your physical panel in centimeters. First of all it's the limitation of 255 centimeters and yes you get larger displays and no they can't store that in here. The exact size. The other issue is that quite often vendors they have a whole series. Basically the same hardware just panels in different sizes. And they don't bother to update the EDID between the different sizes. So you can't fully rely on this. It gives an indication only. Next up, color characteristics. We go straight into the deep here. Color characteristics, those are the colorimetry of the panel. So how does it represent red, green and blue? How exactly is what color space is it using? PCs on their desktop they normally default to sRGB which is standard color spaces. I'm not going, the whole color space topic that is the full presentation by itself. So you just have to believe me here. And as long as the color characteristics stated here are the same as sRGB then there is no problem. Everybody is in agreement. Problem occurs when it differs because when you are transmitting RGB over HDMI the lovely CTA 861 standard which is pretty big has a big table and there there's a small food note that tells you that when you are sending RGB over HDMI you are supposed to use the colorimetry from this base block. However, only MacBooks do this. Everybody else just sends sRGB. So if you try to calibrate a display on a Mac compared to a Windows or a Linux machine you will get different results. And the flip side on that is what does the display do? What does it expect? Does it expect to see the source using these specific color characteristics? Or does it expect it to send sRGB? And I have absolutely no idea. It's only this year when an amendment to CTA 861 was released where you could explicitly signal I'm sending sRGB or I'm sending default RGB using these default characteristics. Since it's so recent nobody is using this yet but I'm hoping that it will pick up because it's really annoying that it is undefined. One thing I forgot to mention at the start I'm on behalf of Cisco part of the CTA 861 workgroup for the past five years and I've been trying to improve the standard and actually this is one of the things I managed to get in. Also by the way one of the changes that went quickest everybody just agreed hey yeah this is undefined this is a mess, let's fix it. So next up in the EDID established timings this is a bit of archaeology remember 1994 this is one of the first things that were defined so you get lovely resolutions like 640 by 400 Yes you can use it but this is old stuff slightly later in time standard timings hey now we go up to some more decent resolutions beginning to look like something and then you get detailed timing descriptors now it becomes really interesting these are meets the normal stuff that people use usually the first detailed timing descriptor should match your preferred resolution and your native resolution as well notice however this is a 5k display that timing is not 5k why is that? because when this was designed they could not imagine a 5k display so the maximum width and height is 4095 so the best you can do as an EDID writer is to have at least something with the same aspect ratio that comes closest and that's what they did no fault of the EDID it's just a limitation of these old base blocks notice that the detailed timing descriptor also has an image size, physical size the chances that that matches the image size earlier in the base block is close to zero if there is an image size in the beginning then ignore this if there is no image size in the beginning it's undefined then you can use this but be careful you see here it says detailed timing descriptors but there is only one and after that you get other things so detailed timing descriptors are four in the base EDID but usually you will see only one or two being used as video timings and the others are this space is abused to represent other information about the display so you have one display range limits which gives you the minimum and maximum vertical and horizontal refresh rates and the maximum pixel clock so there can be many timings defined in the EDID and if you actually go through them all and figure out what the minimum and maximum ranges are and you match that with this this is usually wrong there are almost always one or more timings that have lower refresh rates or higher refresh rates unless you have some software to check this it's very hard to do this manually there is product name, product serial number and then the number of extension blocks that follow so that was the base EDID now for this 5K monitor the next one coming up is block one it's called a block map extension block map extension block terrible name basically an index in the extension blocks that follow now there are only four blocks so you have just two indices that means that you have wasted about 120 bytes of precious April memory on a pretty useless extension block it could have just read the whole EDID and look at the type of each extension block and figure it out so this comes from the EDID 1.3 standard that mandates this if you have more than two blocks the second block needs to be this specific extension block remember that ACMI requires 1.3 so if you want to have valid EDID for an ACMI interface with more than two blocks you are forced to put this into block one the second block since the beginning is very wasteful but because ACMI is stuck in 1.3 that's the only way you could do it nice complication some of the older transmitter hardware might read only two blocks of an EDID so they would get the base block and then this useless extension block and not be able to see the following blocks now to be honest it's pretty rare these days but it is something to keep into account when you write an EDID that not all hardware is able to read your full EDID so if it just reads the first block then they will make different decisions to one that's more modern and can read your whole EDID so put at least some decent values into your first block now ACMI clearly thought that this was silly as well so I think it was last year they came out with an amendment that added a special data block to the CTA extension block and if that's present then you could override the number of extension blocks so the first base block would still say I have only one extension block then it would read the CTA extension block and that would say no you don't have one extension block you have two extension blocks ignore the first one yeah you're all laughing that might be why I haven't seen this in any EDID yet so by the way when this EDID was made this didn't exist yet and I'm not aware I wonder if there are any implementations at the moment that would actually parse this so we go to the CTA 861 extension block notice here so there's a video data block with all the various resolutions that are being supported CTA defines video identification codes basically byte values every byte has a certain meaning but above that you see native detailed modes 1 that means that the first DTD in the EDID is supposed to be the native resolution now remember the first DTD didn't match the 5K resolution so this would indicate that 3840 by 1080 is the native resolution clearly it isn't for the first thing it also sets a native bit so now you have two native resolutions that conflict and neither of them actually match the actual native resolution ah yeah then you get some audio information hey there's two speakers left right lovely some color imagery what other color spaces and support and then you get the video capability data block that has a very important one RGB quantization selectable this is I said this is a Frankenstein EDID the original didn't have this I added this for illustrative purposes so RGB quantization is a bane of my life when you're sending red green blue out as a source you have two ways of doing it the first one is that zero is black and 255 is full brightness full range is black 235 is full brightness limited range consumer electronics equipment basically everything relating to TV uses limited range it goes all the way back to the old CRTs and original TVs long long horrible history PCs didn't care about that we can do full range from the start so of course you have more levels it's bending it's a good thing full range in my view but consumer electronics is limited to well limited range so when you're sending some so as long as consumer electronics is completely separate from IT worlds then there's no problem but these days you know every laptop has an HDMI output TVs can use each IT equipment as input and blu-ray as an input so the worlds have collided and now you have a problem CTA 861 standard said okay if you're sending a video timing consumer electronics timing so 720p 1080p 4K all the things you get when you put in a blu-ray disk basically then it's limited range by default if you get an IT timing 1920 by 1200 those types of things then it's full range the chances of anybody so both source and sync doing all the right things based on the defaults are pretty remote 50-50 at best and it gets even worse when you add all sorts of adapters in between PC monitors tend to behave differently from TVs they tend to assume full range TVs assume limited range different graphics drivers even on different OSs make different decisions so it's horrible basically I'm pretty sure this is wrong by the way I haven't tested it yet but I give it an 80% chance that this will display the colors will assume most likely full range while my laptop is sending limited range so I'm not the only one who saw that and in CTA 861 version H syncs are required to set the selectable RGB bits that means that they accept that the source can explicitly signal whether it's full range or limited range they can parse that and if you are a source and you detect that the EDID supports this you really should explicitly signal this in fact the recommendation is to always explicitly signal this what can go wrong it's at least will at least be as wrong as it already was and it's luck it's actually better so RGB quanta say I could make a whole presentation about this I'll keep it at that so next up you have a vendor specific data block this is defined by HDMI specification has a bunch of information and it has then a weird list of HDMI fix remember CTA defined a number of video identification codes when the first 4k displays came out and HDMI wanted to support it the CTA standard didn't have corresponding VIX now apparently instead of talking to the CTA guys and say hey we need this now we make our own so that's what they did there are only 4 for VIX that they defined these are basically 4k, P30, 25 and 24 let me come yes an interesting thing here so that's going back to the previous page if I signal one of those HDMI VIX what is the default RGB quantization range they didn't define it you go through the whole spec and they say nothing about RGB quantization range later on CTA added proper VIX for these timings and still later the HDMI specification said yes they are interchangeable so then it becomes clear since these are CE timings consumer electronics timings the default is limited range in the meantime there were lots of drivers that assumed full range so actually pretty sure that the Intel driver started out with full range and later had to switch to limited range it's all because they didn't define it and we had major problems figuring out what to do in our own products like this so these additional HDMI vendor specific blocks they indicated you have an HDMI interface but this gets tricky when you have HDMI to display port adapters or the other way around it's not clear at all whether they are supposed to remove these blocks or add these blocks I find the specifications for such adapters mostly non-existent and I think every interface standard just points to the one to figure it out and nothing actually happens for this for once this is the remainder of this extension block there's really nothing special here for once some HDR information some more detail timings and that's it now we get to the last extension block that is hey 5k amazing so the only extension block that can actually represent 5k that is display ID extension block so that is why this particular display has four blocks in total the base block and they're forced to use the block map then the cda and then the display ID block just to tell everybody that hey I support 5k notice though that it says preferred but it still says nothing about that this is the native resolution they could have done that display ID has support for that but for some reason it wasn't added here so even though you can figure out from this edid that it supports this it still doesn't say that it is the native resolution now we're a bit related to those adapters the same thing happens when you mix cta and display ID who has priority what should you do when there are conflicts not defined I try to bring it up now let me it's not defined there are several reasons why you might want to use both even on the display port interface cta is very handy you can represent lots of video timings in a quite concise manner it is very well understood you might have a display with both htmi and display port inputs you want to keep the edid as similar as possible so you want to reuse that information if you do make sure that there are no conflicts between the two they're all saying the same thing then it will work out well if you get conflicts then well what do you do to support these 5k displays we had to do quite tricky things in our parsers to figure out whether it's you want to make sure that it is not a broken edid you want to make sure yes it is really a good edid yes it is really a valid resolution that we want to support so I think this edid gave a lot of interesting has a lot of interesting issues let's now go to how do you how do you parse them and check them so I maintain an edid decode utility it goes all the way back to 2006 was maintained by Adam Jackson was part of the x11 one of the x11 utilities included with that by 2017 it had become quite outdated and we wanted to have a really good parser that we could use and also check edids they had already some conformity checks but by no means was very limited so it took over maintenance in 2018 and have been adding support for all the latest features and things and improving the conformity checks and it's not pretty good I won't say it's perfect especially on the conformity checks there are still some things that can be improved but you know there are so many standards and a lot of these requirements are small print but if you want to check an edid and see how well it is implemented this is a pretty good utility there's also a web page this will be updated daily with the latest version of edid decode you can just drag in an edid and it will parse it and give the results useful options for this edid decode utility minus c to the checking you will see warnings, failures occasionally it's a parse minus n will show the native resolutions according to the rules and the edid minus p will show the preferred timings based again on the rules now you have noticed in the previous outputs of this utility that all these timings come with split out in all the parameters so this utility knows about all these timings knows the exact precise video timings that they represent that means that it was very easy to also add some options to where you could just let it do the calculation I want the CVT timing with a certain resolution put in the parameters and the program will give you the exact timing you may remember so those that may have used it X11 also provides CVT utility in the GTF utility to do the calculations I've discovered that those are wrong in some cases this is all based on the actual standards it also has even the very latest timings, OVT optimized video timings that was introduced in CTA H61.6 so this is completely up to date as far as I know it so what will happen if you run this and check the preferred video timings for that 5K monitor so if you just parse block 0 you'll get that resolution you remember that was the first detailed timing so that's wrong if you parse block 0 in the CTA block you'll get the first DTD again and the first VIC with 1080p again no 5K only when you parse block 0 in the display ID block then you will get 5K so it depends on the parser what it understands and what it's doing what the result is that you get if you do the same for figuring out the native resolution then it's not there at all as I mentioned before it's just missing CTA added however support handling preferred resolutions and native resolutions native resolutions are very new came out in February this year preferred resolutions has been there a bit earlier it also added lots of support so this is a test EDID that I just manually crafted which basically has support for all the different ways you can implement timings and as you can see CTA now supports display ID timings as well you can use them there and those can go up to 5K it has optimized video timings that they have a resolution ID stating what the resolution is and then they have they can support various refresh rates and from there timings follow this is all part of the CTA standard you can read upon it there's a video format preference data block where you can list your preferred resolutions in order there are basically references to timings you defined before and finally there's a native video resolution data block that says which timing represents the native resolution and if you do the same thing with EDID decode for this one then you will actually get the right information so if you parse it with the CTA parser that understands the native video resolution data block you will get the proper native resolution and that is what you want but this is also new that before this is before this is all filtered through to actual drivers that parse this and display manufacturers that implements this we are probably several years further resources EDID decodes repository it's part of the linuxtv.org where we keep all the media subsystem tree and utilities the EDID, EDDC and display ID standards are freely available from Visa CTA 8.1 standard is freely available from the CTA.tech websites I have an email and that's it about EDID nicely on time and I have a few minutes for questions you are close by on one of the slides there was 12 bit or 14 bit color that defined for 5k monitor what is it about so how about fitting it into 8 bits that's let me see oh yeah this one supports 12 bits component deep color or whatever yeah that's deep color I haven't talked about this at all but that means effectively that the the bandwidth, the frequency will go up in order to accommodate that so if you look at here the maximum TMDS character rate at the bottom section of the megahertz that is the number of pixels that you pass through it's not the actual frequency so if you go with higher bit depth the actual frequency will go up as well but the number of pixels that you transfer remains the same and you have to of course the cable has to support that so if the cable doesn't support it you don't know so a properly implemented adapter so the display is a display port and you are sending it to HDMI so HDMI to display port converter so the adapter is supposed to add these HDMI vendor specific data blocks whether it does you don't know the good ones will, the bad ones won't oh limited range yes it started out in the analog world so you never had precise black and white levels it was just waveform and they just said this voltage is black and this voltage is white because it's analog you would get these overshoots so when you digitize this you might want to preserve those overshoots so that's why you have this extra headroom there are also interfaces STI some serial port variations to transfer video that are actually using bytes in the 0, 1, 2, 5, 4, 2, 5, 5 range to signal metadata so there too you want to stick to limited range this is all broadcast TV stuff but hey that was the world until for many many years so that's all reflected here come to me afterwards I don't want to yes but it's a yes but answer okay thank you yes too late I have to stop sorry thank you very much


Hello, hello. Welcome to the day two of the 1.x meetings. So what we're going to do now is that we have about four different presentations. First will be Frederick, then there will be Casey, then there will be Remco. Then I will present, after that I will present very shortly the things that I've changed since yesterday, and after that we're going to have a breakout session. Okay, and then further in that we'll have individual time and more presentations. Good morning. So we had some good discussion on chain pruning in the relatively small group yesterday. I can't say that we got to any sort of implementation details or figured out exactly what to do or what an EAP or anything should look like, but we had a lot of discussion around what we need more feedback on and what we need to figure out before we can write an EAP, and a lot of this comes down to like community feedback and actually figuring out what users want and need. So I think the first point that we need to establish is what do people actually want? When we're talking about a pruned node, we can talk about it in different contexts, but essentially imagine it's a node that just has a full copy of the states and headers and nothing else. Who wants this? What is this for? You can imagine I use case like for myself where it's someone that wants to use dApps and use dApps regularly. They don't necessarily want to use a like client and pay the network cost of going out over the network for every request to this dApp. So they want the full copy of the states, but don't have 150 gigs free on their laptop. So it's sort of a thing in between a like client and a full node. And I can imagine that user and like I would be one of them myself, but how many of those users exists in the ecosystem? And it's really hard to tell. We've already pushed people to accept centralization and just use infura. Everything is fine. And can we really take this step back and bring those users back to care about data validity and other things like that? And it is something that I don't have the answer to. And I think we need more people saying that they actually want this before we should just dive head first into doing stuff. The second question is why run this over a like client? Do people care about those network costs? How hard is it? Maybe we should focus instead of focusing on building a prune node, we should focus on like client incentivization actually making like client the like client experience of first class experience that works really well. If we solve the incentivization problem that's also useful for you to and something that can further like both the current ecosystem and future. So that's another question of like where is the effort best spends given that we have limited resources? And the final question just here is this is almost a question to Hudson, who's not here right now, but the question is like how do we find out the answers to these questions? I don't really know. We need to like engage the community to find out what they actually want, what they actually need, what they would use. But if we assume that this is something desired, how do we build an MVP to prove these assumptions? So I think the first thing that is really easily implemented like I said yesterday is something that we can have like next week if we go on into is a feature flag on CLI to just say prune everything beyond end blocks. And I think there's a discussion here around if this behavior is default versus non default. And in Peter's proposal, I think he has written up most of his like write up an assumptions and sort of how this should work with the expectation that it's the default behavior. And I think going into default behavior is really dangerous and something we shouldn't do as an MVP.  Is it something that's solving a real problem? And we can talk about, you know, bringing this into a default behavior if we can see that it's necessary and have figure out this the solutions to the availability problems. With that comes then the question of like, do we actually need to ensure availability? So a lot of Peter's post goes into how do we ensure availability? You know, as soon like Bitcoin has this mode as an optional thing that you can run and they don't seem to have availability problems. I think it's relatively safe to assume that we won't have availability problems if this is just an optional non default feature that we ship. I think there's also much less of a coordination burden between clients if it's the non default behavior and a sort of quote unquote insignificant amount of users using it. But if a significant part of the network starts using it, then coordination becomes more important and we actually need to figure out like how do clients sync together and things like that. So I think my proposal here would be that we actually ship a pruned mode feature flag and just see if this is something that people want and people use. The last thing that we discussed was how do we like what is the best way to ensure availability into the future. Peter's sort of top suggestion was to put blocks and IPFS comes with a couple of additional problems like we're not actually storing IPFS hashes in the header. So to be able to look up blocks, we'd have to either introduce another hash or have some sort of gateway service that converts one hash to the other and it can be somewhat complicated to figure out. We can add another hash to the header either in protocol or out of protocol depending on implementation. And it's not that big of a deal but it's a little bit dirty. And yeah, it requires cross client coordination. So if we go with IPFS, we need to make sure that all clients have IPFS capability to be able to read from IPFS, etc. That adds another level of overhead. So I think something that we talked a little bit about was what level of availability is required, what's high probability of availability, and what incentive structures can we build around having availability. But I didn't hear any really great suggestions on actual incentive structures. So if anyone has ideas, still open to that. And finally, I think something we talked quite a lot about and especially related to the discussion of IPFS and where do we store things. There is this original proposal that Robert Parity made a couple years ago that we just shard up the history by identity key. And you can do that in an arbitrary way, but we currently don't have any discovery method of finding nodes that store this section of blocks. So we're sort of dependent on the discovery v5, which development of is not that active or fast. And so we need v5 to be in place and sort of deployed widely across nodes before we can use a mechanism that is inside the Ethereum network to distribute these blocks. But I think everyone in the circle sort of agree that this would be the best scenario because we keep everything in the Ethereum network where don't have external dependencies on things like IPFS. And it paves an easier path for sure for proper incentivization in the future. So yeah, there's an open question there of like how do we get discovery v5 shipped as fast as possible. But I don't think we need that to start experimenting. And I think we can build our MVP and have a feature flag that enables a pruned mode and basically say if a lot of people want this, a lot of people use this, then we can look into, you know, how do we ship discovery v5 faster or whatever else that's necessary to get higher probability of availability on the network. So those roughly what we discussed yesterday and I don't really think that we can have much more like productive discussion with just the people here today. My hope says that everyone kind of goes away and thinks about this a little bit. And especially we try to reach out to the community, try to see what people want and is this indeed something that is desired and people are asking for, then we can pretty easily build a prototype to serve that need. That's about it. Yeah, so discovery v5 is, I don't know exactly everything that's proposed in, so we're currently on the v4, like version four of the DevP2P discovery protocol. And so this is the next version of DevP2P discovery. It includes one important thing called node records, which is just a fixed length string that becomes available, like it has arbitrary content. And it becomes available in the DHT. So you can, once you've downloaded the DHT, you know which nodes have which section of the blocks. So you don't actually need to go around the network pinging everyone to see who has what. So question is, what would an incentive structure look like? I don't have any great suggestions. So basically, I mean, that the core premise is you get paid for storing a section of blocks or even you get paid for storing all of them.  And this sort of goes back to proof of storage and proof of like retrievability and proof of availability, which is like a lot of the stuff that Filecoin is working on. And we could probably lend some stuff from them, but borrow some stuff from them. Yeah, I agree. I think in Peter's proposal, there were some comments. There were some from Vitalik of like why why wouldn't we use this? And Peter's response is basically, well, they're not production ready. And yeah, I think the argument is like IPFS is something that exists now and we can put in next week if we wanted to. Like there's great bindings for go and there's like we have already have a bunch of stuff in Rust for the period client so we can get it done really quickly. And making so on production ready is a longer term project that we don't really have any estimates of how much effort that would actually take. But I would argue that we don't need to solve this problem right now. We can still introduce a prune mode and then we start working on that problem and solve it properly. Yeah. No, programming wise, we could do it quickly, but socially, I'm not sure. Yeah, it has so it was considered as well. It just has some additional problems, but we could come up with a standard for it relatively easily. But currently parodying get that different serialization. Well, I mean, there's always RLP. So could always do that. But I think so. Question is, can you incentivize both disk and bandwidth usage? And I think you can. No, but I've like Swarm and Filecoin and a couple others are working on incentivize storage. And that's a hard enough problem. I haven't actually even seen one anyone trying to approach incentivizing bandwidth. It's it's a lot harder. Yeah, it's maybe. Yeah. Yeah. So in in a like client's incentivization scheme, you would basically charge per requests and account for bandwidth in that request. Yeah. Okay. So the idea, can you hear me? Okay. With road mapping in reverse. Um, we know what we want to achieve. We know what the final product is, which is compiler engines for both the major clients, get them parody and preferably the engine for go would be written in pure go is the go team likes the code base, likes their code base to be all in pure go, not pulling in dependencies written in C plus class or Java or various languages pure go. And that would be ideal. So that's the ideal situation. What we have now is we have interpreters and every client is not very hard to write interpreter. You know, so one member of team Paul wrote the interpreter in Python for go. We're using an interpreter called wagon. Interpreters are easy, but compiler engine prototypes, there's the serious ones come from the browsers. So in Chrome, there's it's written in C plus plus. So there's a decent engine C plus plus. There's also good efforts for engines in rust because Mozilla is trying to rewrite basically Firefox in rust. So for parody, integrating the WebAssembly WebAssembly engine in rust is it's there's a lot of progress towards that. Yeah, I was joking this morning that if if Google was decided to rewrite Chrome and go, then it would probably solve all of our problems because we would have a decent WebAssembly engine written in pure go. But they don't seem to be doing that. So without having a good compiler engine in in go, then one workaround we could try is compiling the pre compiles using just a head of time compiler, whichever one works the best, and then deliver the binaries, you know, the .exe's to to the clients so that, you know, Gath would import an executable. They might not like this. Well, we already know they're gonna hate it. But this is one one approach short short of having a full engine, full compiler engine written in go. Maybe if this is viable, you know, Gath team could fight the bullet and we'd be able to have WebAssembly pre compiles before a WebAssembly engine is available. Short of that, we can use an interpreter. We can just start out with an interpreter. This was a proposal from alexi where rather than trying to jump straight to having awesome compiler engines, if we just start with integrating an interpreter engine, then other teams will be incentivized because they'll know, okay, well, WebAssembly is definitely an Ethereum. So if we work on a compiler engine for Ethereum, then, you know, we know it'll actually be used and adopted on, you know, on the main net or the 2.0, whichever. Without having even an interpreter based engine inside Ethereum clients, it's a big risk to start working on a compiler engine that, you know, may or may not ever get into Ethereum. So the downside is this, using a WebAssembly interpreter for pre compiles, it would only work for a few pre compiles. A lot of some pre compiles are prohibitively expensive, prohibitively slow when ran inside an interpreter. So like the snark pairing pre compiles are way too slow in an interpreter. Hash functions might be fast enough. Hopefully they'll be fast enough when ran inside an interpreter because, you know, it's kind of dependent on the input size. So for small input sizes, the pre compiles might be usable inside an interpreter engine. So even another workaround, even less ambitious is to simply use WebAssembly as a blueprint for pre compiles. So we'd just be analyzing this WebAssembly blob to generate a gas rule.  This is basically how the existing pre compiles are done. This, it doesn't, this doesn't help get introduced WebAssembly into, into the clients very much at all. It makes it maybe slightly easier to add new pre compiles. But still like one of our estimates is maybe if we only do this, then adding pre compiles, the, according to the way, the old way, we can maybe do like two new pre compiles in 2019 when there's probably demand for like five or seven new pre compiles that people want. But doing it this way is a lot of work for each one. So yeah, that's, I mean, that's it. These are three approaches that we're kind of working on all three at the same time, trying to prove which ones are viable and hopefully get us to the final goal. But, you know, eventually, yes. Well, we can probably, I mean, using an interpreter and, and a blueprint. But I mean, we could specify the, the changes for, for, you know, a bunch of pre compiles, but we're not confident that the testing that we could test them all thoroughly and that clients could implement them by, you know, say the end of 2019 only, only the interpreter using as, as the, as the engine. I mean, you can probably specify this by, by May, but it's not going to be usable for all the pre compiles that people want. So be patient. Yeah, I mean, we'll see if client maintainers want, you know, agree that it's a realistic time, timeline. Yeah, we're pretty close with the concepts as it is. Yeah. Yesterday, we talked a bit about the gas costs and how difficult it is to make the gas cost. All right, let's try that. So, so my question was yesterday we talked about how difficult it is to estimate gas and we identified a couple of scenarios. One is that it's constant gas. The other one is that you can cap it at an upper level. And the final one is that it's an undecidable problem depending on stuff. So my question is really, is there any pre-compiles that we can start with which, which, which are easy to do according to this increasing ladder of difficulty? You guys want to jump in here? Yeah. Things that are constant runtime. For example, if you know your elliptic curve, you know, multiplying to whatever points or whatever you're doing is constant runtime, then that's the gas rule. You charge them constant gas. So someone, some are have structure like hashing. They do it in blocks.  So that has sort of a simple structure. So yes, the pre-compiles we're looking at have the structure that we can analyze. Arbitrary code, hopeless. As you know, the halting problem. But as you mentioned, but yes, for what we're doing, we think we can have reasonable gas rules for the pre-compiles that people are interested in. I don't know. One more point. I just wanted to say, Casey said that the interpreters might be too slow for certain things like pairings. I think that might not be the case. I think we need more benchmarks for that kind of stuff. Yeah, just to re, repeat the, the upper bound gas rules don't help with that that's unrelated to pre-compiles that are simple enough to run inside the interpreter. If we could maybe do two new pre-compiles that are too complex to run fast inside the interpreter. And for those, we, yeah, we want to use the WebAssembly as a blueprint to generate the gas rules, but still doing more than two seems unrealistic with all the testing and, and implementation that clients would require to add those pre-compiles. Okay, so we are just, my previous question was about, so I just looking at the objectives, because I'm determined to kind of keep people on objectives today. So we established the sort of vaguely the initial set of changes for the May 2019. So the first, the second objective is establish framework for designing, evaluating and comparing the, the, the sort of the change proposals. So the question to you and to your, your team is that if somebody wants to sort of propose something for your, for your, you know, for eBasm introduction. So, so what are those going to be? Maybe you could write it down for something like this. So what are the things that they need to consider so that they don't have to, they don't throw like really unthought, unthought through the proposals at you. So what kind of, what are the steps that need to go through to, to describe, like, do you actually want people to come up with alternative things and sort of the framework that I'm talking about the framework. So, so what are the questions people need to answer? What are the things that they need to consider before they come to you and says, Hey, I've got the, I've got an idea. I've got an alternative proposal to what you're doing. Maybe something like that. I know it's might be way, I think the biggest one that people take for granted is client code bases like to keep their code bases pure. So saying, Well, why don't, why doesn't every client just use this, you know, C plus plus engine or something. So to the, so you might remember yesterday, I put up like a four questions, right, to you. So if we were to keep those questions and obviously added a third thing to the, so then another consideration you would add to that is the, is the client code. And they are sort of some of them being opinionated about what should go in and not. What are other things that you would, you would say are important? Um, off the top of my head, I'm nothing really comes to mind. Yeah. So if you have any ideas through today or tomorrow to add to the, because I think I'm going to start with the, the questions that I asked yesterday, I'm going to add what you're done today, and then we can add some more things about all the considerations that people have to think about if they want to, you know, to participate and give your alternative proposals. Okay, cool. I just wanted to add some comments on specifically this and then some of what you said about clients and, and code bases as well. So something we have to keep in mind with pre-compiles is that there are some pre-compiles that will never be anything but x86 assembly. Like it's just anything else is too slow. So it doesn't matter if it's wasn't compiled to assembly, like that's going to be too slow. So there are, there's like a certain class of pre-compiles that are assembly only that are like who hyper, you know, specific, optimized assembly code. Then there's like a second class that I think this fits really well for where it needs to be fast, but not extremely fast, where it needs to be compiled as a web assembly. And then there's a third class where it just needs to be faster than EVM. And there, if it's a really good interpreter and an interpreted web assembly might actually be faster than EVM because we have 32 bit math instead of 256 bit math. So if you're doing some sort of like relatively simple crypto, then a web assembly might like even if it's interpreted might actually be faster. Pairing is the first one. It's assembly. Yeah. So you think that the pairing whatever we do here, the pairing have to be in assembly, right, to be efficient enough. Yeah, I mean, for the ones that we already have, yes. But when like when we're adding new ones, you know, it will definitely be faster than EVM version. So it's sort of what about like if we if we think about this is the G minus two, but did you start with G is this the so if we think about G, right, was it G? Yeah, so if we have a very good, yeah, if we have like a compiler, maybe a head of time compiler or something, which can compile, let's say pairing code written in a web assembly into machine code, do you think it's going to be fast enough or not? Or does it have to be handcrafted assembly depends on what you mean by fast enough, but like, it's fast enough, I think. So maybe then done. What did you want to say something about it? Whereas the the WebAssembly version that we benchmarked comes up on which is maybe twice as fast as the native Fairview one, which is like 15 seconds. But, you know, whether we still haven't, the gas costs for that pairing are still calibrated to you know, like the 50 to 100 ms when we're trying to reduce them before but without a native Rust assembly, you know, what would be the implementation? Just a quick question. Does the pairing require a Kerala's multiply? And does WebAssembly actually have this instruction in the first place? Kerala's multiply is something you need for. Yeah, exactly. Exactly. So my question here is that, okay, so the do we need pairings to be super fast? Or can, is there use for pairings which are not as fast? Because we might maybe we, we don't need to have them 100 in assembly. Like, are they, can they still be useful enough? If we just do they're really useful as they are right now. Like that, that's why people are pushing to get like the parody implementation of 5x faster because the gas costs of pairings right now is no, no, this is a different thing. So there's a gas cost and there's the actual performance. Yeah, but the gas costs currently mirrors the actual performance. So to reduce the gas cost, we actually need to improve the performance. Okay, I would still, I would still like to separate these things because if, you know, if we can increase the gas limit or something to make those things useful. So then maybe it's, it's even, even because what it looks like what you're saying is that some of, for some of the pre compiles, the whole approach is probably kind of flawed, right? The whole approach to trying to, to do the pre compiles in evasem is flawed. I actually, before we sort of flow, throw the white flag on this, I want to say, I want to ask if, even if it's slower than hand crafted assembly, like by what mark, but what, what, by what factor, like 10 or so, could it still be useful for the real, real stuff or not? There are applications where you would need to do pairings infrequently. But I think the issue is if you price the gas costs relative to the worst performance, you're discouraging developers from using it. So it's, it's, it's probably not the best approach to take in the short term, just because it's not going to encourage use. But, but actually just following up on that. Maybe I'm misunderstanding if the, so all the clients already have an optimized pairing implementation, what is hard about calling that from, from the wasm interpreter? Not much. It's doable. It's just the whole point of the wasm thing is to remove the pre compiles or like in this scenario. So it would, you gain nothing. But as I think there is so we will always have this, like the super optimized, like pairing stuff, I don't think it's going like, like it will discourage use like even currently, it's uses limited because it's too expensive or like too slow. And I think that will remain the case for those. But there's a whole sea of other pre compiles that people want to add, like they want to add different hash functions, they want to add a ton of different stuff that is not that doesn't have to be hyper optimized crypto code. So there are definitely other types of pre compiles that don't need to be hand coded assembly. Yeah, so the just to clarify, so we, the one of the reasons why, why the wasm was included into the why we're trying to get it earlier than Ethereum 2.0 is because we see it as a meta feature. Whereas instead of develop core, like a client develop developers working on specific pre compiles, and it's really a lot of work. We basically deliver one engine which can implement any pre compiles. So that's like a, it's like optimization of our time, sort of instead of try to optimize things which might be used by, by the few contracts, we actually just got the whole class, solve the whole class of problems, probably not the most optimal way, but like a, which kind of we, we're going for the bread. This is the one pairing function we have now, it's you know, the BN curve. And then as soon as that was implemented and adopted, you know, by the time it was adopted, Zcash was already switching to, you know, the new curve. So anybody else have a question for now? I think Frederick made the best point where there's some class of problems that are reasonable for interpreters. There's some class of problems that are not reasonable for interpreters. There's some class that we can't even use with Ethereum now because we would need FPGAs or ASICs for. So there's sort of classes of problems. The interpreters give us access to some sort of problems like hashing, like blakes and certain things, but perhaps not other things. But this is sort of a process as we go, as we, as we improve, as we shift our gas prices from interpreters to compilers when our compiler infrastructure improves. We have to take a first step. This isn't going to just magically appear.  Everything isn't going to just appear. We have to take a first step. And that's the, that's the reason we want to start with interpreters to tell people, hey, look, you know, we have a need for compilers. We need to audit them. We need to, you know, we want them to perform. We want guarantees from them. Without doing this interpreter step, maybe there's no incentive to, to, to do the compiler. So I think that's the benefit of doing it. Yeah, I completely agree with that. And it's just a matter of time then. Yeah. Why is this not working? Found it. So I just want to have a brief meta discussion. So me and you and Greg are here from the perspective of DAP developers, which, which means that we're not as much in the know of the real problems that the core developers are having. But I think it's good to just step back a little bit from the specific implementations and look at the higher level problem that we're trying to solve here. Because I don't think there is a lot of clarity right now about what specifically is the, is the problem. We have a clear goal. We want to keep Ethereum 1x running. But one of the things I learned yesterday is that for sure, Ethereum pro performance is really, really complex. And for example, something like storage has nothing to do with actual on disk storage, but has the complex things. Them suddenly become more expensive. So it's a very crude signal that we have. And any sort of discrepancy between this gas cost and the actual resource consumption of the system that could, in theory, grow out of like without bounds over time will inevitably become a huge performance problem in the system. So we need to make sure that whatever the actual cost of something is and the gas cost of something is, it needs to stay within some finite bound of each other. Otherwise, this will inevitably lead to problems. So now that we sort of defined the problem space, the other thing we need to do is define the solution space. So what are our options? What are we willing to do? What are we not willing to do? Where are the trade-offs? How much pain are we willing to suffer in order to solve certain things? How urgent are things? So one thing I realized is that at least in some respects, nodes are not fully optimized yet. Probably in terms of the peer-to-peer network, there is a lot of optimizations that can still happen to avoid bandwidth consumption. So it might not be necessary to break the protocol in order to reduce bandwidth consumption because there are lower impact changes we can do in the wire format first. And we need to be a little bit careful here when we start breaking the protocol for things that are not heavily optimized yet in the nodes because we might end up breaking, making changes in the protocol that we need to carry forwards toward in the future that might end up actually not being necessary as we start developing the nodes more. So this is something I'm a little bit worried about. Fortunately, it seems that nodes in many critical areas are already heavily optimized and where they aren't. We should be able to estimate how much of an improvement we can expect from future development here and how much the impact of certain protocol changes would be here. Another goal that we have is to remain implementation agnostic. We kind of want to give all the nodes the freedom to implement things however they see fit. But this is directly at odds with having accurate gas costs and solving concrete performance problems because they are always dictated by a particular style of solution. So these two points in the solution space are actually a trade-off where we need to collectively agree on where we want to be between one and the other. Another question is what do we want to break in the protocol? So the protocol has a lot of things it has historically guaranteed by virtue of the yellow paper and it is obvious now that we're going to have a series of hard forks that are going to break some of the things that were specified in the yellow paper and it's entirely clear where do we draw the the lines here what what the boundaries of this are. What for example it seems that we are completely fine with destroying gas token like the storage proposal and some of the other changes are going to utterly destroy the token and don't think anyone has a serious problem with this because the assumption is that gas token is based on something you can't rely on. However we were kind of shocked when the assumption that you cannot do a storage for 2300 gas was broken and started breaking and it cost a big pennant. So this was an assumption between core developer resources and urgency. So this sort of defines the solution space and again I'll like to give the DAP developers perspective here. The main thing is how do I as a DAP developer know which things I can reasonably rely upon to be there for the future and which things I should consider. Yes this is what the protocol does now but this is likely to break soon because it was not meant to last forever. This this is not like we specified the current behavior really nicely in the yellow paper but what is not clear in the yellow paper is how this will evolve going forward and it would be nice to add this. Now big shops like let's say maker 0x you name it. Honestly break whatever you need to break. We can migrate. We have designed our systems to be upgradeable. We have developer resources. We have the skills in house to deeply understand the changes and if you just give us at least a path to a migration we will be able to find it implement it and take it. So don't worry too much about about us. What you should be worried about I presume is the medium scale developers and the individuals because they might not have the resources to implement migration parts or they might have locked themselves in the position where a migration part is really hard. Let's say for example that I'm an individual who thought it was fun to become an absolute 0x hodler and I locked all my 0x tokens into a contract that locks them for three years and now storage rent comes and this contract gets slowly drained what happens to my tokens is to a migration path here. So that's the sort of thing that I would assume is a bit more challenging. So yeah my key takeaways here are we need to define what our performance targets are for the system in order to define what the problem is that we're trying to solve and we should be documenting any invariance that the system currently gives and to what extent that developer should be depending on them. Thank you. Anybody has questions to Remco? Cool. Thank you very much. I'm going to just do so you probably saw this yesterday but I'm just going to highlight what I've changed since yesterday in my slide so it shouldn't take a long time based on the feedback that I had received including this one as well. So basically hello. So you probably remember I showed this yesterday so my kind of premise was that we had four main performance degradations that would be caused by the growing state size and so it's numbered one two three four but actually more than an hour for example which it could do then by the time the sink is complete the peers would have pruned the state that the new peer wants to sink and that clearly is getting worse with the sort of with the with increasing the state size. So what we want to do is that we want to do this emulation which to determine what that function is so we kind of think that this function has three arguments state size bound with and pruning threshold and so what is the success rate in this case and maybe we could try to see investigate the dependency there and so what happens when you when your state size start improving and so the next thing what we could do is that for other things for the number one two three although we have an idea of what the function is but we don't know the coefficients so for example you probably intuitively can think that the just simply reading the state is cheaper than sealing the block when you modify the state but how much cheaper is that so we again using some emulations we can we can put some really rough coefficients on these functions like and after that so once we've done it so we have a very rough sort of functions with the with the relative coefficients for each of this performance degradation and then after that we use we use simulation already when we have functions and then we try to simulate the events that we kind of want to predict when we're going to be hit by this problems and the problems could be new guest nodes mostly unable to do some snapshot sync or new priority nodes because they have a different syncing mechanism they probably will have who experienced this problem in different times at the different sides of the state so then another thing to look for is that when is the block processing going to be 10% of the interblock time when is it going to take half of the interblock time because all these things will start affecting more and more facets of the of the performance so that's kind of the the the plan so next thing I'm going to show you is is the additions that I've done to the to the state rent since yesterday okay so just scroll to the pieces have changed yes so here remember yesterday I was trying to explain you the low cups with the with this analogy so I think Andrea came up with a different analogy which I didn't put in the pictures but yesterday I used analogy where the contract is like a glass separated into the sections here we've got the six sections so basically this contract has six storage items and two of them are currently have lockups on them so the idea is that after the introduction of lockups all the contracts all the new contracts will always be full so in this example where you created the contract it's got no storage and then you have a S store which sets some values and it keeps growing and then you see that at some point when you simply change the value the storage size doesn't change and there's no lockups necessary so you could see that takes origin doesn't need to pay anything but when the subsequently the takes origin when subsequently you free element of the storage the excess lookup gets returned to the takes origin and in the case where we have a pre-existing contract so again this picture demonstrates that we start doing some changes which could be either adding a new item which needs to be needs to have a lockup with it or even if we just modify the item in the second transition we still have to put it put up the lockup although the the storage size doesn't change and then in the then we do another modification and then eventually we'll nullify so so in the second so in the last transition we reduce the storage size but we don't get anything back so a good question oh yeah yeah sure Fredric can you give him a phone with the microphone I wonder why are you deducting balance from TX origin instead of trying to use some opcode for that what so I mean new opcode yeah well the new opcode which will be it will be like some opcode that increases the lockups like pay rent and if the lockups are not enough the store will fail yeah the reason for that is because the reason the whole reason why the lockups were introduced is to provide the existing contract with the migration path so and of course if you need if you need to put a new opcode in it means that you can have to rewrite the contract so the we have no choice if you want to keep the existing contract for a while while they're migrating we have no choice than to modify the semantics of the current things and actually something came up this morning which I didn't put into the presentation yet we had this little chat and there's I want to explore a bit explain a bit more why do we need this migration path and then shortly the explanation is that if there are multiple contracts which have a synergetic relationship then like let's say three of them using each other then these three contract will have to upgrade kind of stepwise so the first one so the first contract rewrites its code but it keeps migrating the clients but in the meantime another contract which uses it has to use the old version and then they say okay we've done migrating now the contract number two can switch to the new version and then start migrating itself and so forth so this could be like a whole chain of migrations and we need that's why we need this mechanism to keep them alive while they're migrating because it cannot happen in one big bang cool thanks just a yeah let's discuss later but the explanation may not be enough for those kinds of situations okay so what else i changed here since last time okay so here is a another discussion we had how big should the lockup price be and at the moment one of the methods which we're thinking about is that we think about target storage size we could discover using simulations or there's something that I just mentioned at what sort of storage size we're going to everything is going to stop working then we also have some sort of target lockup so how much easier do we want to be locked up to completely reach that target storage size and we just divide one on another so if we for example take 500 million items which is about three times more than we have at the moment and which we say okay in order to completely filled us up we will we will require 10 million easter to be locked up then we arrive at the lockup price of 0.02 east per item which is quite expensive I would say and so what else did I add so I fixed this diagram from yesterday so in this diagram yesterday I had the potential modification to rent balance and balance but now in here I cleaned it up so it's now should be clear that the during the eviction check if the eviction check is not not successful then nothing gets modified so and another thing okay so here I clarified that the pay rent opcode actually has two arguments which is the target contract and the amount which means that you you can call it from the third party contract and to to top up somebody else's balance rent balance and the lastly again we had a discussion yesterday what if we get the constants wrong so in this proposal there are four four different constants that have to be introduced which is the account rent code rent storage rent for different aspects of this rent as well as the lockup price so if we realize that we have underpriced to overpriced rent then we could probably just change it via hard fork and that don't at the moment I don't see any major problems with that where but the lockup price is a bit different because we we currently have one simple counter that account accounts how many lockups do we have so if we decide to change the lockup price with a via hard fork what we will have to do we have to introduce the second counter into the each contract called lockup two and in this case the condition of like remember there was a condition that which determines whether the contract is full which means that it doesn't have to pay a storage rent so this condition would change from the simply storage size equals to lockups to something a bit more complicated but still manageable which includes two prices the old one and the new one which is basically say that we were tracking both of these things and if we need to do the third hard fork then of course we can make this formula a bit more complicated so but the basically yes so I say that this is the trade-off so obviously introducing the variable lockup is will eliminate this problem but it has other the the the variable lockup introduces even more complexity into this mechanism okay so that's it from or so these are the updates from yesterday that I had um any more presentations for now or should we just break do a breakout okay cool breakout so we can stop the live stream for now and we do the breakout


Crunch is a beautiful sound was written by Dr. Chandra. You can find it on the scp wiki and a link in the description below. It is under a creative commons share alike attribution 3.0 license. It appears the D-class has fouled up Crunchy's bi-weekly cleaning again. Oh and by Crunchy I mean 173. I've never really cared for the nickname the sculpture. I think Crunchy captures his essence much more effectively. I'm sorry, it's not his. I know I'm not supposed to anthropomorphise these things, but it's hard. When it's your job to understand something, I should not try to get inside its head. Take right now for instance, two D-class just had their necks snapped, the 3rds giving his all to the most important staring contest of his life. He's Amy ponding at blinking one eye at a time. I've been told that doesn't work, but Crunchy isn't moving. Why wouldn't it work after all? We don't know, because we don't know why Crunchy can only move when no one's looking. It really is some sort of quantum wave function, then the whole Amy pond thing should work. Of course it could have nothing to do with quantum wave functions. Maybe he's just shy. Besides, if Amy ponding doesn't work, then what would happen if someone with one eye looked at Crunchy? Actually we should test that. Out of all the D-class we have here, some of them have got to have only one eye and no one's ever sent them to 173 for testing. And did we stop using iPods on this? Was that back when we stopped cross-testing everything just because we could? Those were the days. Mr. Ponder still holding his own in there, he's backed up against the door and is screaming to be let out. I should open it, but I can't help but think that Crunchy might be faking. There's an access control vestibule of course, so even if he gets to the taunt won't do him any good, but I can't shake the feeling that he knows something I don't. Little scabs broken out of containment more than once after all. Sometimes I wonder why he does what he does. No one's ever seen him move. Or if they have, they don't live to tell about it. And all the video feeds of him are either static or blue screens of death unless there's someone with him. But we can still hear him scraping the walls of his cell. And why does he kill everyone on sight? Who does that? What does he get out of it? He doesn't eat the bodies or use them for anything. And if it was for pleasure, you'd think he'd take his time like the old man. Now he's just a monster with no rhyme or reason, just a boogie man to scare people.  You should probably see a doctor about that.  Answer me that. His file should probably be classified as ectoentropic, but it's not for some reason. I really wish we could find out where Crunchy comes from. It's probably nothing special. Just something a random artist whipped up in the garage or something. On the other hand, Crunchy's got a bit of an aura about him. I've heard people say he's the original before, but I don't know why. He's not the first SCP, at least I don't think he is. Then again everyone knows these numbers aren't chronological. Rumour has it that all the SCP-001 files are just misinformation. What if he is the first? It says he was transferred to Site-19 in 1993, but who knows how long we've had him? What if he's not just the first, maybe he's the source? What if he was the first anomaly and that single breach in the laws of physics was enough to allow the whole load of anomalous freaks and monsters and objects to flood into our reality? That is a strange thought. If 173 never existed then, would Herman Fuller's Circus never exist as well? Would all of the other Skips, Geo Eyes, or the Foundation never have existed without 173? I think I may have just blown my own mind. Well, I'll probably get in trouble if I don't let Mr. Pond out. I'm probably in trouble already, letting him scream for so long. The Ethics Committee has been really cracking down on D-Class abuse lately, but it's really just a budgetary thing. We can't burn through these guys like we used to. I'll just open the door to the inner vestibule and the feet just cut out. That's fine. I'll look at my file and see what I'm supposed to do next. It says if he starts acting weird, I'm supposed to contact my H-M-C-L supervisor?  Thank you very much for watching. If you enjoyed the video, hit the subscribe button and then hit the notification bell next to that so you're notified when I upload new videos. And then head on over to patreon.com forward slash D-Sumerian and pledge it at any level like everybody here on the screen already has, including Sinjeriki. It was pledged $100. It's nice to know that I'm not alone out here and I will see you all again on Tuesday.


As you well know, I've long been urging that Republicans and Democrats work together in a spirit of bipartisanship to tackle the many great challenges that are facing the country. I'm pleased to note this morning that on two fronts, we are making great progress, social security and jobs. Members of Congress have been working very responsibly in the past few weeks to reach agreement on a major social security bill, and I'm hopeful that I'll have a bill on my desk before Easter. A bipartisan coalition is also working very hard to produce a responsible jobs bill that will help to put Americans back to work. I strongly support those efforts, but I'm deeply disturbed by the possibility that the jobs bill will suddenly become a Christmas tree for special interest legislation. We must firmly oppose that effort. In the meantime, there are many other areas where we must also achieve bipartisanship on issues ranging from the budget to providing critical assistance for Central America and the Caribbean. And today I'm sending to the Congress legislation that is very special to me and certainly deserves strong bipartisan support in the Congress. This is a measure to address the problems of the hardcore unemployed. I know that Congress faces a long and imposing agenda this year, but we should take heart that America is finally climbing out of one of our most difficult recessions. Because we worked so hard over the past two years to lay a foundation for economic recovery, we are definitely on the mend. Now in order to assure a lasting recovery and a lasting peace, we owe it to the American people to make 1983 another year of great accomplishment in the Congress. And I'll bet that you have a few questions. Mr. President, on the jobs bill, on the threat of... Yeah, what was burning? The banking industry of having interest rates that are too high. What's going on? Is the banking industry threatening the economic recovery? Well, all I could say is that this intensive lobbying they've done has led to a great distortion of the situation. They've led many people to believe or to ignore the fact of how many millions of people would be exempt from any withholding, that this would not... As a matter of fact, virtually all senior citizens would be exempt. And I think that the banking industry would do a lot better to spend its time thinking about lowering interest rates than lobbying the way they are with regard to this legislation. Ellen? Would you veto any legislation where a casting type amendment is attached to the jobs bill, for example? You know, Helen, that I've always said that I resist saying in advance whether I will veto or not. There are always exceptions to rules, and this is an exception. Yes, I would veto such legislation. Mr. President, you talk of bipartisanship, but you seem to be a long way from any kind of bipartisan agreement when it comes to the question of aid for Central America. The Speaker called your version of the situation down there greatly overblown. But Mr. Saunders talked about blackmail and the idea that you had to get the money, or there'd have to be more advisers down there. What about that? And what about the idea that we could just keep on sending money down there as the other side escalated until we had ourselves another situation where we were in too deep to get out? Well, you know with regard to the Speaker, us Irish are given to oratory. Sometimes flamboyant. No, I think if you look at this situation honestly, here is a government that has been democratically elected in a country that has had a history back over the decades of military rule and no democracy. It is a government that has embarked on a land reform program that has moved up an election for the President to have it this year instead of next year that had in the last election a greater turnout than this country has ever been able to muster in spite of the fact that the voters were threatened with death by the guerrillas if they attempt to devote. They are improving their justice system with regard to arresting people that are continuing the violence that once was a pattern in that country. And I think that it is an obligation here to try and help as we have. Our economic help to that country has been two to one over military help and the military help has been limited to spare parts and supplies and so forth and individual trainers. We have had a couple of their battalions come to our country and trained and they are the best of the military down there now. There's a great need for training. There's no blackmail of any kind intended, but I would like to call attention also that in our international aid in many other trouble spots in the world it does seem peculiar that this is the only one where they seem to be raising objections and yet here is one that is a threat to the western hemisphere, to our own security in fact. If I can just follow up, sir, people are asking where does it end? Where it ends with is a recognition that the people of South Salvador given a chance at the ballot box have made it plain that they want order and peace and democracy. And this government there is making every effort to persuade the guerrillas to talk to offer amnesty, to persuade them to come in and participate in the democratic process and not try to shoot their way into a ruling position in government. And where I think it ends is with a political and an economic solution. We're trying to help them economically. The economy is being destroyed by the guerrillas. Every time we read a little note about a power failure because of they bombed some power plant or facility, every time they do away with bridges and highways and transportation and so forth in their guerrilla attacks, these leave people unemployed and industry stopped and so forth. And there has to be an end to that and a political solution to this problem and that's what we're aiming at. Mr. President, you said that Ann Burford did nothing wrong that she can leave EPA with her head held high. But there are allegations that she talked about admitted holding up the cleanup of one dump site because it might help California Governor Jerry Brown. There are also allegations that one of her top aides, James Burford, brother James Sanderson was involved in EPA decisions involving his legal clients. When you say that she did nothing wrong while the investigation of those charges is still outstanding, aren't you in effect saying that those practices are all right with you? No. I'm not saying anything of the kind. And I heard her last night on television make that statement about the site. And she said that possibly she made some remark to that effect. But it had nothing to do with the decision that was made. It was the decision was made on entirely different and practical grounds. And she also pointed out that with the election over, she still did not do those other reasons. Still has not made the decision on that particular site in California.  And I never would have asked for her resignation. She was doing a job. And we, this administration, can be very proud of our record in environmental protection. And believe me, it tops what we found when we came here. And the fact that she was able to do it with a reduced budget, well, I've asked everyone in our government to do things with a reduced budget. And with fewer employees if possible. That was what we came in here to do, to make government more efficient, to eliminate waste and extravagance. And she has revealed that she is far more concerned with the national welfare and is a far bigger person than those people who have been sniping at her and who have been going public with unfounded allegations, accusations, and charges. And she, from the very first, was willing to make every document available to them. It was myself, based on what I believe is, well, I've always described this as you aren't presidents. You are temporarily custodian of an institution, the presidency. And you don't have any right to do away with any the prerogatives of that institution. And one of those is executive privilege. And this is what was being attacked by the Congress. And at the same time, we were willing to make available almost 800,000 documents to them. And more recently, to give them access in a kind of controlled way to protect, because of possible litigation, those that were confidential and sensitive. But she was willing to give them all, which shows in my book she had nothing to hide. But I don't think that the people who were attacking were concerned about the environment. I don't think they were concerned about any possible wrongdoing. As a matter of fact, I think this administration and its policies were their target. And frankly, I wonder how they managed to look at themselves in the mirror in the morning. Mr. President, much of the sniping, though, came from inside the White House, from your staff, other people outside who were orchestrated to do it. Governor Keene of New Jersey was not discouraged from coming down here and asking her to resign. How do you react to that? I mean, you didn't put a stop to that. No, I don't know of anything of that kind. I know that you were all citing these unnamed White House sources that thought that she would resign. And I will admit, there must be people. I still would like to find them out and identify them. There must have been people, or they're probably the same people that said that about everyone else who was attacked in some way in our administration, all of whom have been cleared completely. And yet the same charges were made. Oh, it might be a political embarrassment. Well, I'm not that easily politically embarrassed when I know and have faith in the individual. I am not going to yield to the first attack and run for cover and throw somebody off the sleigh. Mr. President, but the Republican polls now show that your policies are perceived by the public, your environmental policies, as being more favorable to polluters than to the public. Are you going to change any of your environmental policies now that Mrs. Berkwood has gone? That's all they've heard. But no one has given any evidence that that is true. I'd like to call your attention to the fact that in eight years as governor, California not only led every state in the union, we led the federal government in environmental protection. We were the forerunners of the whole movement. And how this idea has come, I sometimes suspect that the lobbyists for the environmental interests feel that they have to keep their constituents stirred up or they might not have jobs anymore. Do you think the slowness in getting the superfund into action on a number of sites has contributed to that perception? And the fact that you've been quoted in the past is talking about environmental extremism? Well, there is environmental extremism. I don't think they'll be happy until the White House looks like a bird's nest. May I, Helen, once, may I address there was a young lady here who I missed over. Thank you, Mr. President. Back to El Salvador for a minute. The Civil War there has been going on for three years. With the aid that you're now proposing, do you feel that you have any idea when the conflict will stop, when it will be under control, or is the United States prepared to make an open-ended commitment? I can't give you a date when a thing of this kind will end. Every effort is being made, as I say, to persuade them to come in and join in a peaceful solution to the problems. This is also a regional problem. And the other countries, their neighbors, Costa Rica, Honduras, Guatemala, Panama, others are holding meetings to see what they regionally can do about this. Now, we're not participating in those. We will be an interested observer. We certainly encourage that kind of thing. But these are other countries that have adopted democracy. Costa Rica, I don't know of any country that they don't even have an army. They are the most democratic country that you can imagine. Honduras has ended a long tradition of military rule and has a democratic form of government. And they all want to help because they recognize that this is an outside threat, really, to the security of the Western Hemisphere. And I hope that it'll be a short time. I hope that these appeals and offers of amnesty will bring some of those people down from the hills. But I also have to recognize, not be naive, that these people up there in the hills are not just discontented peasants who have managed to get at their hands on a military weapon. These are trained and highly equipped military forces, trained and equipped and backed by outsiders, by way, mainly of Cuba, through Nicaragua. And so I think that we have to stay with this. And I don't see why there is so much opposition to it. We have no intention of sending combat forces, nor have we ever been asked for combat forces. And there's no intention of ascending the advisor teams to be with combat units or anything. We're talking about simply giving their military some of the fundamental training to enable them to do the job. The Soviets have expelled a spy. Ellen said thank you. Can you just tell us about the Soviets expelling the spy? And was he spying? And what is your reaction? I don't know anything further than any of you know about that. Thank you very much. All right, thank you all very much. Next time when I come, can I start about halfway back? Because I think that the people in the back of the room don't get called on enough. All right, next time in, I'll start back there. Maybe I'll be on a raffle. Unless all of you in the front row suddenly turn on the back row. No deal. We're hardy into that.