 I made a couple of suggestions, so basically what we want to have is we want it to be possible to figure out what the gas cost of the whole thing is in O of one time and in O of one memory reads. So the suggestion I had for mod X was that we would take the bit length, or sorry, the byte, we would take the byte length, then we would look at just the first byte, and if the first byte has less than 8 bits, then we would kind of appropriately discount it. So one example would be that if you have three bytes and the first byte is 25, then the exponent length would be counted as 24. If it's three bytes and the first byte is let's say three, then the byte length would be counted as 18. Now if you have let's say 10 bytes and all of them are zero bytes except for the last, then the byte length would still be counted as a 9 times 8 or 72 because that's just the way the algorithm works, but you can argue basically why the hell are you throwing in a value with a we take zero bytes in the first place. So that basically is all I had to say on all those gas costs. So what would be the next step to actually determine? So to determine on the elliptic curve side, I'd say and possibly just I mean agree on preliminary gas costs for the purposes of testing, and then maybe or perhaps the other thing we could do is just have no I think the practical thing to do is that we agree on some preliminary gas costs for testing purposes, then we get to the point where we're passing the tests, and then we actually see how many milliseconds it takes C++ go and parity to run through some of the test cases, and we go from there to figure out what the final values are. At least that's one approach. On the mod X side, I think we would need to first of all figure out in principle what is the right like whether or not we're going for this bit length approach, and if so what approach are we taking in principle, and then the next step would be finalizing a very precise definition. So I did some performance measurements on the pairing function in C++, and it resulted in roughly 60,000 gas times the number of pairs plus 40,000 if we target 20,000 gas per millisecond. I'm not sure if that target is correct. Okay, so my next question is though is what numbers do a depth and parity get. So I would prefer to avoid finalizing the gas costs until we have enough numbers from all the clients to make sure that we're creating a reasonable gas per second for all of them. Yeah, we should wait for it to set in the constant, but it would be good to finalize that algorithm for mod X pretty early, I guess. Okay, so we'll do the same benchmark by next meeting. Yeah, so maybe all three sides do a benchmark, and also all three, so a depth C++ and parity should also figure out what four makes sense. So I think the most principled way to figure this out would be to just basically see what is the four now. So I guess that for elliptic curve, I mean, in general elliptic curve addition should be constant, I guess, and multiplication should also depend on the size of the skater, right? I would argue that there is not much benefit in making multiplication depends on the size of the skater because pretty much all multiplications have ever been counted in cryptography multiplied by random 256 bit numbers. And so I don't think we really lose much by just going straight to the worst case. Right, that's a full point, yeah. I mean, there's some use in, okay, it can kind of abuse multiplication to compute the inverse or something like that, but that would be a large scalar anyway. So maybe we'll put the numbers that Kristen have for now to start with something and to actually do some tests. And the next meeting or before the next meeting, if we get more benchmarks, we can adjust that. But I would go with the numbers that we have so far, last example. Okay. Sorry, is 20,000 gas per millisecond a reasonable number or what do the others think? So I recall that we arrived at 20,000 gas per millisecond because we looked at basically what are the most inefficient other op-codes that we had and we got something like 15 to 20 million gas per second in the worst case. Is that correct? So I think I did a comparison with other pre-compiled contracts and internally with Malmoth, I think. Yes. So maybe, yeah, in general, I think 20 million gas per second is definitely fine. Yeah, so I guess the other benchmark, it would be good if the other benchmarks could also check that with other pre-compiled contracts. So what thoughts do people have on the ModEx issue? I have a comment on that one because if anyone can hear me, the idea was there to accommodate the fact that we have 256-bit memory stores. So crafting the request is kind of optimized for 256-bit, but the content might be much less. So what if we only care the top must 256-bit and assume if, say, the exponent is like it has in bits, we assume that the bottom 700x bits must be set and we only consider top 256. So then it's only, you know, the exposure is limited. So basically the exact proposal I have, except that instead of looking at the top one byte, we look at the top 32 bytes. Yep. Yep, I'm okay with that. I mean this is a constant effort and can be priced in with the baseline gas constant. Vitalik, do you see what Hudson is writing in the trove? Yes, let Vitalik know the proceed to next item when done with gas. Yes, so basically the other concern I have is that I wanted to just basically kind of accentuate the fact that with the fact that the revert opcodes can return things, basically it was Joseph for BTC Relay pointed out that we actually are making a major economic change, or at least a significant economic change which in some ways does break BTC Relay's current model. Basically the problem is that BTC Relay worked and potentially a lot of other other applications might also work by charging some very small amount in exchange for reading some value from the contract state. So the idea is that this is like one way to do a paid oracle. And with the revert opcode what you can do is you can basically call to a contract, then from the contract make a call to BTC Relay or whatever other thing, get the response, then in the outer contract you would use the revert opcode and you would revert the response. And this way the payment that you would make in exchange for the response will be reverted, but you would still get the data out. And so this is something that's not possible to do easily now. So right now basically the easiest way to kind of cheat these contracts out of data is by basically asking for a merkle proof of the state and this is arguably much more expensive, whereas here all we have is just basically a tower of two calls and that's all you need to circumvent any kind of paywall. So I can add to that a bit, but yeah we discussed this a few weeks ago and that's why I opened that ticket against BTC Relay. But the thing is that even without return data you can always do the same thing with the revert and return one bit at a time. So you can do an oracle, you can query BTC Relay, is this header valid, is this transaction valid, gets it back. And if you don't, if all you want is to come back. Wait hold on, so how exactly does the one-bit oracle work? I think I... Oh I see you would revert and you would use the amount of gas that you revert with? I would either revert or I would not revert. Well but if you don't revert then the payment goes through. Yeah but you can revert in a different place. Right but if you revert any different... Oh I see so you could have like a tower of three, multiple calls again. And basically you would get back. Yeah so you can extract one bit of information that way and you can do it. Yeah so one way to do it today is the magic with what you mentioned. Another way is to actually use throw. You can do it the same way but it's much more complicated because especially with BTC Relay it's not constant how much it costs. So it will be easier to do that with something which is constant. There's a sample code in the chat for BTC Relay. Yeah right. Well revert, please, it doesn't... Cool thing for me. Using the floor you're cutting out. Sorry can anyone make sense? Andrea I think you're cutting out quite a lot. Yeah Andrea I think your audio is messed up. So I've never found the paying for oracles case particularly compelling simply because it is so it is entirely plausible to just fetch the data from the state and create, make a miracle proof. So that's only difficult so long as nobody's put up a miracle oracle. I've always I think the if oracles... So the arguments would be... Then they have to charge... So the arguments would be I think that even though a payment of 25 cents might not be defensible a payment of let's say 1 cent still would be defensible because the cost of either of these attacks would still go higher than 1 cent. And 1 cent might be all that you need in order to pay for the transaction fees of maintaining one of these systems. I just I don't think that it's a property that we should strive particularly hard to protect because doing so disables other useful use cases and ultimately once the data is posted to a public blockchain relying on artificial barriers and the VM to prevent people from reading it just seems like it seems like the wrong approach to take. Okay that's fair. If no if other people agree I'm fine with that. A question so essentially right now you can trick the BTC relay by making a throw and making a call into your same verification and then setting the result of the throw to see if it's verified or not and avoiding the payment right now. Yes but you basically have to know how much gas the BTC relay will consume and you would have to to set a low amount low enough amount of gas to be able to distinguish between natural failure and your explicit throw. So it's kind of difficult to do today. I see so I was reading the example by Alex to try and understand how it works and now I see why it does this gas calculation there. All right thanks. Hey guys can you hear me now? I think I fixed my audio. Yes. Oh excellent yay okay so was that it for that item? Yes okay and that was I'll go ahead. What was the decision on this item that we just don't want to put any different barriers? Yeah I think so. That's what it seemed like. Was there anyone who was like heavily opposed or would have an alternative? Okay cool and that covered that covered the revert opcode correct Vitalik. I was fixing my audio so only caught half of that. Yeah I think we're going ahead with revert as is. Great all right so the next one is Yoichi talking about EIP 96 so go ahead Yoichi. Yeah it's a triviality in EIP 96 256 blocks into Metropolis. Block hash instruction can change its internal working and then the same EIP also says the gas cost for block hash should change from 20 to 800 or something. My question is if this gas cost change should happen at the first block of the Metropolis or 256 blocks after that? Hold on should the gas price of block hash okay. There's a link in the agenda that actually discusses it and points out in the code I believe where where he's talking about if anyone needs to look at that. Yeah I'm looking at the snow so I think we did agree in one of the previous calls that we would to make a change to EIP 96 so that to restrict it so that technically you could argue that one way to implement EIP would be to not change the behavior of the block hash opcode at all. So does the gas cost increase? Oh I see him. Yeah it's a triviality. I'm checking in previous meeting notes right now to see if this was discussed but I definitely remember that too so I did we I think we said that I want to look at the notes before I make any comments. I'm pretty positive we said that block hash would continue to return only the 256 most recent hashes and if you want to dolder ones you'd have to call the new oracle contract and if that's the case yeah if that's the case it seems like we could change that back so the price won't change and the you know the channels you might change. Yes that's a reasonable choice and shall we go along that so the gas cost increases only 256 blocks after metropolis starts. Well I'm suggesting that we need an increase the gas cost at all because it will continue to operate as it used to and if you want to access older stuff you have to call the oracle contract. Yes yes that that's very just so one thing that one thing I'd say one thing I'd suggest is just as an as an experiment see if we can kind of but basically I want to see how long would it take to do basically a million rounds of calling the delegate calling the block hash contract over and over again just to see that if someone decides to implement a kind of history free implementation then you know would they incur any like extra difficulties there? Yeah fair enough. Is this 96 we're talking about? 96 yeah. Okay basically what I'm trying to make it possible to do is I'm trying to make it possible to make an implementation of the protocol that does not depend on any kind of history access that's not in the state and that doesn't require any kind of additional weird data structures in which case implementing the block hash opcode would be would be basically just either calling that contract or just reading its reading its storage once and now we could of course argue that those particular storage keys are going to end up being in the cache so it's not it's it's not like this is a particularly serious issue but I'm basically trying to wonder if 20 f520 gas is low enough for that kind of implementation or whether something slightly higher would make sense. I would propose to increase the glass cost and those clients which can use the old implementation they might be saving time by that but we should assume that every new client would implement it through the Oracle that's my proposal. Okay if we increase the gas cost can we just do it on the Metropolis block instead of 26 blocks after? Yeah I think that's more insensitive. Okay with all other cost changes yes. Yeah we didn't I don't have notes talking about this specific part of 96 but I posted the ones I did find if anyone wants to read those to kind of see what we talked about previously on that but it sounds like we came to a resolution on that. Yes I think I got an answer on my question so I'd ask a little bit to change his EIP text to clarify this point. I have to clarify that the gas cost has increased to uh I'm not asking about the amount I'm asking about which block should the cost change the Metropolis block then. Okay okay yes and that's enough. I have one question about the CIP so if we are going to deploy a bytecode to that contact why don't we charge the actually the gas cost of executing it? So there is actually about three different ways to implement this one of them is to execute the code one of them is to read that particular account storage. I'd also argue that a discount might be prudent because if someone tries to call this contract a whole bunch of times then it will just end up being in the cache but on the other hand though I could see how it would be kind of a very principled upper bound to calculate the exact cost and charge that so yeah I plan to do it but we didn't have time so far okay. Personally I'm not overly worried about a conservative price because I don't expect many contracts to call it and those that do probably won't call it much. Yeah I mean I think like 800 will be fine because like it's still it's basically one call anyway and no I can't imagine there being applications that'll be willing to that'll be afraid of paying a lot for block hashes but that's yeah like basically I don't really expect there to be applications that needs to kind of spam block hash reads enough for even if you're a substantial increase to be a substantial issue for them. Yeah my thought exactly. Okay. Next point is also about the same EIP. The next point is about the nonce of the system account. The system account is after metropolis supposed to call this block hash contract in the beginning of every block. Notice that it is a call and not a transaction right so transactions increment nonce calls don't. A call transaction would increment the nonce and the call from the EVM would not increment the nonce so I felt ambiguous. Correct so by call I mean a call from the EVM and that's how I usually use the word call but I'm happy to clarify that. So the nonce would not be implemented. Correct so the code pathway that you should use to implement the EP96 should be the same one that you would use in like the call up code. Okay cool yeah Andre and I had some disagreement over this so it's great to have an answer. Can we move to the next item that's a different EIP? Yes okay sounds good. The next point is about EIP 98 the intermediate state removal. When you read the EIP text literally the change starts one block after the metropolis hard fork block but I guess it's a typo so I guess that's changed to start at okay cool and that was yes it should be greater than or equal to you I can update that right now. Okay cool my last point is actually well maybe not pure triviality it's about the E211 return data copy when return data copy wants to copy more than returned what should happen currently the body of the text says between zeros that's the same as whole data copy but nick suggests exceptional holds I think both are reasonable I think at least we should gather opinions here and try to reach a consensus. My own view as I've stated in the EIP is that reading past the end of an array is almost always an error and therefore we should treat it as such and that's currently returning zeros as likely to lead to undetected bugs and I know there's no consistency but I think we should fix the issue where we can rather than introducing this into new opcodes. Okay yeah I don't see a real technical issue with Nick's suggestion apart from that we will have two very similar opcodes that behave differently more weight in implementation and testing and remembering DVM to spec but that's just meant to cost the other address spaces are well defined to be valid for all addresses and yeah we should be the same for consistency but I mean as I said I think consistency is a weaker argument than this is the wrong thing to do like we should be consistently wrong if we can avoid it. I think I copy also the because there is at least one contract currently on the blockchain that will fail if code copy sorry no it's called data copy throws an exception because it deliberately reads four bytes past the end. Oh okay so I think I commented on the issue but I can't find the comment anymore so it might be lost altogether. Nick so what is the what is the problem we're solving here? It is the problem of incorrect included input data right? Well it's anything where it tries to read data that doesn't exist silently which in zeroes is in my mind extremely likely to be undetected errors and very unlikely to be the intended behavior. But if the return data is fully specified to always be virtually infinite and contains zeroes then what is the error we're dealing with? But the the actual return data isn't infinite so like the the contract that returned the data specified a return length and if you then try and read past the length that was specified by the the returning contract that should be an error because the data doesn't exist. I mean so what I want to say is that when we compare this to the the error that sparked this discussion and the error was incorrectly encoded user input data then we have a different situation here because the data we're dealing with here is usually created by yeah we we don't have what error sparks the discussion. I'm arguing this in a vacuum I think purely that reading past the individual array should be an error because the data should be undefined and not just silently filled with zeroes. I can't think of a single situation where filling of zeroes is a good thing. I want to ask Greg what this means for even 1.5 because in even 1.5 it should be easy to detect potential exceptional faults before executing the contract by just scanning the code and I think introducing a new kind of exceptional fault might make this more difficult. Greg? Oh trying to find the unmute button. I agree with Nick that it's totally wrong that we treat it that way. I've been told it made the description mathematically simpler. I don't know if you have an opinion on that. I also agree I wouldn't want to extend the mistake beyond the domain it's currently in and yes if we insist that that all code is going to be validated before it's run we can we can catch things like this much more easily. And I think I think Martin's here I believe that would be true for Wasim also. But Greg wouldn't that be a new kind of runtime exception condition that cannot be validated before actually evaluating it? It didn't sound like it but I could well be misunderstanding. I don't think you want to have me take time to reread the heap and think about it more this very second. So because the the memory offsets are not constant and known to the validator of the contract you cannot check it before deploying the contract. There you are. The indexes are dynamic so you can compute them on the runtime. Okay but wait a second this discussion is not relevant because call data copy always copies to memory and there we anyway have a dynamic gas condition. So whether we run out of gas because we run out of gas because we have to enlarge memory or because we access return data beyond its length that doesn't matter much does it? We only have one throw instruction it has no data we don't distinguish why it throws. And you also I assume don't you don't think you can statically determine whether that throw instruction is reachable. You just assume that if there is one that it could potentially throw. We can determine whether any instruction is reachable. Really what if the condition is if this piece of bytecode evaluates to true then throw. Oh that sense of reachability. Yeah so I mean the same would seem to apply for called out of the copy you can't statically determine in all cases whether it can either happen but you can you can if it's impossible you can say so for certain but if it's possible you just have to say maybe. Exactly. And I think the same would go for called out copy passing into the array. So just to clarify when anyone says called out a copy we that person most likely says returned it. I also made the mistake before. Now I hear people with a truly different opinion and it's not reasonable to expect consensus in this call. So shall we agree to continue this discussion on the place being from the agenda. So actually I'm I'm indifferent. Is this something strongly for? Yeah. Arkady was arguing for consistency between different instructions. Yeah Arkady do you want to elaborate on that. Well yeah my point is that it just makes a simple definition of the protocol. Okay yeah I think that there are more people in favor of explicitly instead of filling the out of bounds array or the out of bounds error with zeros to actually just not let it happen and throw an error is why it sounded like the majority of people were for that am I wrong. I've never seen Prish and I got I'd be curious what Vitalik thinks as well. I'm fine either way of personally although one thing I will point out is that I remember there was resistance to doing things like one of the reasons why for example the division opcode in the EVM returns zero when you divide by zero instead of throwing is that we did not like at least some of us did not like the idea that you can have a parameter dependent throwing and like basically they like the idea that that opcode should only throw because of like actual out of gas and then anything that happens after the out of gas step it should is basically not throw under any circumstances and throwing on bad return call data would kind of conflict with that. I think that that confuses developers or at least when I'm developing like everyone I've talked to the thing they have the most problems with are the fact that throws don't act as a lot of modern programming languages would act when something is thrown it's not always just one single error it's usually gives a little more indication so if there's any interest and providing more information on throws in the future I think this would be a good first step personally. Well I think Resert will do that to some degree at least the throws generated by code rather than by the VM. Okay right. So it sounds like we're pretty much mostly in consensus that the behavior should be that it would explicitly throw an error rather than fill with zeroes am I accurate on that? I guess so. Cool all right yeah Yoichi is that in that point of discussion is there any other comments? Yes I asked exactly this point. Perfect okay the next one is Yoichi he has a proposal for freezing EIPs for to allow for testing for metropolis? Actually hold on just to go back on just to go back on that one point one thing I realized is that back back when we were discussing EIP 5 versus EIP 8 forces return data copy and so forth I recall one of the one other proposal being so the original problem that we were trying to solve is basically how do you deal with variable size return data and I remember one of the proposals being that you would so right now the way this works is that before making the call you would expand the memory for to cover the full range of the input and the full range of the output and one of the proposals was to switch to the full range of the input so expanding the full range of the input at the start and then expanding to the output but only expanding to as much output as what as was actually provided after the call was made and this was in some ways a very nice nice solution except that I remember that it ended up falling out of favor precisely because it introduced this or this idea that the an operation inside the VM might throw because of something because of the actual execution of the operation and not just because of because of initial gas computation issues and so if we're willing to abandon that principle perhaps we'd be willing to go right back to EIP 5 and EIP 8 but there's still a big difference here so the accessing return data beyond its length can be I mean there is there are even the other call proposal there the error condition would only be checked after the call leave return it which is a much later point in time than the point where you read the inputs for a return data call. So I guess though that the point is from just from the point of view from the point of view of kind of making a software abstraction I think the argument in favor of kind of purity is that you want to be able to break down every single VM execution into two parts where one part just does gas consumption and the other part does just like execution and only the first part can throw. But that's I mean if I do a M load at a very high memory point or if I do a call it a copy with a with a high endpoint that is the same thing it both depends on values on the stack. Oh okay I can see that. Oh do you have any other comments on that metallic? No that was the only comments I had. Okay yeah okay so I think it still stands that because some opinions have shifted or become less strong on the fact that we can you know throw for things other than just being out of gas airs that we can we that that is still the or the conclusion is still that on that EIP the behavior would be throwing an error rather than filling the zeros I guess. Yeah okay cool I think I think I followed all that. The next thing is Yoichi a proposal to freeze EIPs to allow for testing. We um Dmitri, Martin, Swende and I had a call on Monday discussing the testing for metropolis. There was an agenda there was a topic how how much of the tests have we covered we couldn't answer because the EIPs are still changing and some of the EIPs look stable but there's no indication that these stable looking EIPs will not change so we don't know how many of the EIPs will not change and we don't know how many test cases are ready. So my proposal is to introduce a notion of freezing a neep for metropolis and after a neep is frozen for metropolis basically it cannot change until metropolis if there is a severe problem EIPs can be dropped from metropolis or if the fix is very easy and everybody says well we have enough time to test this um this can this change can be made but this has to go through unanimous everybody agrees vote in the board of meeting and my question now at this point is shall we shall I try to write on the meta EIP about this process or shall we there's an opinion if there's an opinion shall we shall stay away from these kinds of formalities. I like the rigidity of your idea and the fact that it will allow for things to be a little more clear in the EIP repository which is still pretty messy the people maintaining it have just been busy with other things so I think that one thing is to yeah a meta EIP and this actually goes back to what Alex Bergzausy put as a meta EIP it hasn't been accepted yet but it's just basically a file that says here's the EIPs in metropolis and along with that we can amend that to have a column that states when an EIP has been finalized or no more changes will be accepted to that EIP except in the event like you said of an um extenuating circumstance potentially where there would be a bug found or maybe there's an EIP with a small or maybe an like a consequence that you discover while testing that it relies on a different EIP that's been finalized so I think that that's fine we should kind of you know be flexible as we move along in saying that you know depending on the size of it just try to have a lot more open communication between the dev teams when there is an issue to immediately get feedback so we don't have to rely on the actual audio all core dev call since it only happens every two weeks but otherwise I think it's a great plan I see I see and Alex has already made a comment in the group chat so I will try to write up something and show it to Alex Hudson and anybody interested and in the next meeting I'm coming with some more detailed draft yeah I think that'd be good and people can also close their EEPs their PRs or whatever or put a comment saying I'm done and then the editors will go in and you know approve it add it to the repository and then actually close the PR and any you know issues related to that it only reopen if necessary so are there any other comments on this plan anybody opposed or have an idea about it looks fine to me great all right awesome the next item is any subtleties we need to work out with regards to metropolis does anyone have anything on their mind as far as a subtlety or something that may have not may have not been discussed or we need to discuss I think metallic you wrote that as a topic did you have anything in mind I didn't have anything I think I might have had well though there's the one that I've been talking about for a while but that we actually I mean I guess technically it's part of the I think it might be part of the baby six that creating a contract fails if it already has if the destination address already has code but I was more thinking in minds like smaller things that have to do with like the way that non-synchromatic works or gas calculation or other boring details of that sort that sounds like it would be need to be defined in the eep and as implementation goes through I feel like people would ask those questions but yeah everyone should feel free to voice those concerns in both the eeps and all core dev chats I know you each he's been good about that when he's been applying them to the yellow paper so yeah if there if no one had anything for any quote subtleties yeah well one thing that is the point that Fabian raised about the origin of these new transactions is that something we need to talk about because the issue he raised is that the origin will basically hopefully use this for the new types of transactions and his proposal was to use the verified contract as origin so asking more generally is there a use for tx origin at some point it was banned because people deemed it being insecure so yeah people haven't really used it much in a while it doesn't that just mean the transaction where it originated from even if it hops through multiple other accounts the account of creation the actual transaction so I think the original motivating use case what was it was so that contracts could refund the transaction centers for gas payments but I would say with the eep and asix that's not really necessary because we can open up ways where any contracts down the chain could just pay for gas directly so there isn't a need to actually take it out of the system it would just be pretty much useful yeah yeah pretty much I think it's a bit of a means personally and I hope uh so as he removes it from you know access to it from future version it's just to bring like steams lee treating it as something useful so so martin did that somewhat answer your question yeah okay great um any other subtleties okay great um so as far as the time estimates and testing and release let's first just kind of go through the teams and see where everybody's at we'll start with yoichi since he's been doing some of the yellow paper stuff and I think what we've talked about today is kind of outlined where you're at basically I'm supposed to speak now do you hear us yeah okay we thought we were dropped from the internet um the yellow paper so I have created an PR request for every eep considered for metropolis I believe they are mostly up to date with the and yeah some predictions made about well that that was a great day um that's the yellow paper status I've been reading the metropolis changes in cpp srem go srem and parity and I'm halfway through it okay great I'm back on okay cool and then we'll go to um geth if there's someone here I think maybe pavel or so um okay that was uh yeah python I think that's everybody um c plus plus team or um Dmitry testing if y'all have updates because like actually it was fine to be working and we implemented the lips uh lip snacks and the tests are ready and go to just now test that with um what were you just saying I'm saying I'm saying that snark tests and they are working and you could check it against python okay great um have you checked python's tests against the c++ yet not yet um maybe uh anything stopping you from doing that I'm currently your chi has a clutch you could do that no but okay the night the night you'll do that what were you saying yoichi uh there's no blockers that was what I was trying to say okay great um and was there anything else uh either yoichi or Dmitry on the testing end um for I think I saw a new eep about standardizing the way that tests are formatted through jason is that correct oh yeah we have a consensus issue is that jason files format and how integers um encoded in jason files for tests so someone from bite and team um insists that integers should not be perfected by zero leading zeros and um and I think that's that's nonsense to prefix to add zero x prefix to contract hashes and other hashes so we have a quite of an issue there okay and you said that was between the python jason files that are submitted the issue is in how how the test tool reads the tests okay and I think we don't have a format for jason test files which everyone agrees okay um well what let's do this the eeps out there so um if anybody here who has who does submit those kind of test files could go in and comment and uh if no one if or if not enough people comment on it we can pull in some people who submit and see if we can come to consensus on that um hopefully soon so we can get those standardized for when we're submitting more for metropolis sound good um the next item let's see oh actually was yeah was that it for testing i'm currently working on statistical tests and uh it will take a while I see that uh static call eap is the most static one so there will be lots of tests for that eap okay sounds good um so the next thing would be time estimates for testing and release um so I think because of the price spike we're given a little bit more time and it's looking like because of the um the there's a lot more testing that has to go on because of so many eaps we might need to look to more of a July release is my opinion um Vitalik I know you've been thinking on that what's what's your opinion because yeah so I can just run the um uh ice age script again um with the latest numbers let me just do that right now just for for the fun of it um um okay um hold on damn ice age uh so the current difficulty has gone up to 4 to 8 but the block time has gone up to 15.73 the timestamp has gone up to 14952 and the block number has gone up to 3733126 okay so if we want to maintain a 20 second blocked uh keep the block time under 20 seconds then our deadline is July 14th and if we want to keep the uh block time under 30 seconds then our deadline is September 12th okay that gives us a good amount of time um so is anyone willing to and I think it sounds like from until we freeze these eaps we're not going to have a great estimate on testing would that be accurate uh Yoichi and Demetri? At least and once I start working on particular AAP um I sometimes find the issues when making tests and I need qualifications from the AAP so you see the questions about the AAPs and I pop up when we start working on tests okay yeah the feeling I'm getting is late June would be the absolute earliest for a release and that's if a lot of things go really well with testing um does anyone have any other opinions that's again just my opinion based on just kind of seeing an overview of all of this and they won't make it in July okay you're saying it should be later than July yeah okay sounds good so um what is the time you want to reserve for testing on the test net so the distance between test net hard fork and main net hard fork it's your oh Vitalik you cut out try talking again and other people here I can hear you now or at least I thought I could can you hear me now Vitalik yes I can hear you okay you're cutting out off and on but just try talking again I think we can hear you now I mean uh it must be there and that's getting crappy okay if you disconnect reconnect that's fine um until then was there any other comments on the timing and things like that uh other than Vitalik there was a mention of test net testing so the when would the test net fork happen and when would the main net happen which test net are we talking about my assumption is Robston unless we create a new one I'm not sure I've heard both things mentioned in the past few months I mean it has to be a test net where all clients can participate so it's what's under Robston I would say yeah does gethnot support uh coven so cp ethereum supports neither ah I see okay so yeah it would have it would need to be Robston then yeah we're seeing either Robston or ring kb I don't know how to pronounce it but yeah if cp ethereum can't then it has to be Robston yeah and I think it should be Robston because that more accurately reflects the basically what the current conditions are it's a proof of work test net uh that consistently gets attacked whereas you know coven and rink b are more controlled so that wouldn't reflect true conditions all right nothing nothing bad happens during the testing period like it happened like last week something happened to the test net again it was exactly we can also go ahead I was gonna say we can also do um uh a Robston reboot where we you know start from a either a snapshot and minimize or are compacted um genesis block or just a clean you know genesis block in order to yeah and perhaps impose a you know a hard cap on the on the gas limit to prevent any kind of attacks and um yeah so yeah just saying we don't have to you know um keep Robston going we can do a reboot or you know a refresh um in preparation for testing the the hard fork okay sounds good yeah so we have a lot of options it seems like and I think this is something that doesn't need to be decided today necessarily so does it make sense to increase the meeting frequency okay I'm back my phone is freaking out um can everyone hear me still yeah yeah I don't think it needs to be decided today because um uh yeah because it'll be months before at least uh beyond uh what was the estimate you gave to me tree you said um after July is when we'd be able to test or it was after July when we'd be able to launch not not able to launch you need more time for this oh I see I see what you're saying okay I thought you meant that the test wouldn't be done before July okay um okay so it sounds like we can't really get a block number down today um but between now and next meeting we're gonna have uh the freezing of some of the eeps and we're gonna potentially have a little more standardization with the uh okay and um also we can start looking at what it would take to do an alternative to just using what ropston is today and doing either a reboot or um some type of configuration change um kasey I think you have already looked because you were involved in um getting ropston back on its feet a few months ago would it be significant would it take significant changes to do some of the things you mentioned no not significant at all okay would it make uh sense to have a change freeze deadline and after deadline deadline nothing can be changed in any of the eeps and if something is not in a state we are happy with that it just dropped just iterating on on the which is freeze for this I think that's an okay idea except for the fact that some of these eeps were decided on um related to other eeps so I believe static call revert and a few of those other ones were all intertwined in a way that made them work together best if they were all implemented so for something like that I feel like that would be an issue am I uh incorrect in thinking that I think those those are actually fairly specified okay so yeah they might not be as interconnected uh the talent can you hear us now yes I can hear you now okay so uh kasey just while you were gone kasey brought up that uh we'd likely would need to use ropston because we would need to use a uh test method the clients can all support and additionally if we want we can because there's been a lot of ropston attacks lately we can do a reboot and configuration change to like limit you know gas uh or um uh what was it again kasey yeah hard cap on the on the gas limit as long as um so the hard cap would be tested only right and I mean it's a soft fork it was what uh you know parody tried to do um during the original attack but right we can enforce it as a soft fork just uh you know by um putting the majority pointing to mining power um at the at a miner that imposes the limit right yep so that that's probably the route will go and then uh dimitri stated that um we wouldn't be able to be releasing until august and until then we need to figure out the length of time that a test net would need to be on and uh so for instance like the test net needs to run for two weeks or six weeks or four weeks or what uh what what opinions did you have on the timing and uh anything like that metallic I am personally I'm inclined to say two weeks should be uh should be fine um the justification being that I am practically speaking for all the previous EMPs we've uh well two weeks is more is more lead time we've than we've ever had for a hard fork um and also like I'm not sure that any more time will help much especially given that it's like the bulk of these uh error catching is going to be done uh before everything even gets released uh yeah that that sounds like um a fair point uh with I guess with the caveat of that would be if there is an issue found the uh I guess it would be extended in that case correct okay that sounds reasonable so let's just say this um it definitely won't be the end of June and if things go right over the next few weeks we're going to have a number of things such as freezing EEPs and some testing improvements um additionally if there is um anybody on this call or who listens who is able to help with testing and wants to pitch in uh please reach out to myself Dmitri Oichi or Martin Hulswende and we can get you hooked up on that uh we can use all the help we can get in that area um so yeah if anyone can devote any kind of resources that that would help move things along uh for metropolis okay um I think that is pretty much the end of that so the conclusion to that bullet point would be that we don't have a date um and there's going to we're going to know a lot more the next meeting but it's definitely not going to be end of June and the testing time for uh the amount of time a testnet would be running before we actually launch would be at minimum two weeks um and we'll have more discussion on that next meeting okay um let's see the time uh we have a couple of minutes um so christian if you wanted to just get some feedback on your thing real quick that can be the last item all right um so um yeah depth developers often face the problem that they it's it's quite hard to see when the user interface needs to be updated and also wallet developers uh currently have no way to see whether an external account uh gets received and transfer via an internal call so um it might be beneficial to implement something like uh yeah a listener filter uh index data structure that is filled or triggered whenever an account is touched by anything uh inside a transaction um yeah our card is said that something like that is already implemented by parity and what are other client developers thoughts on that i've i've proposed this for go ethereum before um building bloom filters for all the accounts that were in some way touched by the quest so that you can narrow narrow it down um at the time it wasn't hugely popular because you'd still have to actually trace the calls in order to to determine what change or you know potentially uh check balance before and after the block but i still think it could be worth doing um i guess the other addiction was that would take a lot of space our cardy do you have an can you name a number about how much just space that that needs well i have to look it up but from the top of my head it's like additional 20 percent it was a database size oh and how big is the bloom filter in in blocks at the moment for topics it's 256 bytes all right so if we assume a similar size um we're talking about let's see about another nine gigs and gigs no sorry nine nicks but the same of bloom for a blockchain plus overhead um which you could probably expect an indexed database to be about the same again um more so even if we're using the transformed bloom filters that we're currently heading to yes so the size over it may not be significant okay so um the size wouldn't be significant for geth um any other clients have any comments well another objection is that uh the lay clients wouldn't be able to um you know execute these queries yes and ultimately this is either this is client-specific or we define an api forage in which case it's an RPC device rather than a consensus level so i don't think there's any reason to add this to consensus personally i mean you don't have to trust a response i mean so if an account was touched they can always verify by by rerunning the transaction and yeah it's it's very hard but a client could maliciously leave out a change so you don't detect it yeah that's what i want to see but sorry i mean it's so very useful even if it has that property i would say yeah i i think it's useful as a as a client-side optimization anyway i mean the idea is you you register a callback whenever your accounts are touched and when they are touched you just read their state again so and you can also read the state at regular intervals to avoid uh the the the attack of not being outside okay so is this already an eep question i don't know yet i i just didn't know if this was referencing an eep or if this was just an idea and we don't know i mean yeah we should focus on the top was anyway but i just wanted to get some some feedback okay sure no problem um cool so yeah feel free to epify that and uh the trademark that term and uh yeah i think that is the last agenda did anyone else have anything um or did anyone read anything neat in the troll box that they want to announce um something that we may not have not known i didn't understand anything in the troll box so i had no idea what they were saying all right cool well there's no other topics yeah i should invite uh anyone with ideas about address check sums um i'm working on an address check some uh format so uh yeah come talk to me yep i would like to talk okay let's do it cool all right uh anybody else right talk to you guys in the oh go ahead nick so i was i was just going to um ask the parity folks whether they were going to implement DNAs anytime soon it's um hard to do this good cool yeah all right all right uh thanks everybody talk to you all in two weeks bye bye