# Ethereum Core Devs Meeting #11 [3/3/17]

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2017-10-09
- Duration: 1:24:02
- Topics: blockchain, smart contracts, distributed ledger
- Watch: https://streameth.org/watch/yt-EiXwg9vjGdY
- YouTube: https://www.youtube.com/watch?v=EiXwg9vjGdY

## Description

Agenda: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2011.md

## Transcript

good morning good morning he guys hello I cannot hear people do well oh what about now oh I see yeah I just don't think any was talking uh and I just updated the agenda by the way and I think I posted a link so yeah let me look at that do we know how many people show are planning to show up for this one um um no not exactly uh I know Christian is going to be oh Christian just joined okay so far yeah we have a good amount of people so far definitely enough to continue with the meeting there's uh parody gu uh ethereum J C++ uh python we just need some go people h oh and we also have a uh ethereum JS Martin beey representing LOL hi good morning Conrad hi is looks like I'm in the bat cave or something should probably turn on a light [Music] good morning Alex hey there how are you doing pretty good uh let's see I might go into the go Channel and see if anybody can join is anyone from going here that I missed uh Daniel's on now oh perfect okay hey Daniel me and Daniel are sitting next to each other oh cool okay and Jan's here from Ruby good morning Jan or wherever whatever time it is where you are all right so yeah if Daniel's here then uh I think we can start um let me see what's the first item my page closed it is oh uh Christian it's the uh EIP 211 so uh if you want to get started with that uh you can go ahead and um explain it and all that so I think we already talked about that last time although it was not an official IP if I remember correctly yeah it was yet it's again so another solution for the problem that it's hard to return dynamically sized data from call and the the the proposal would be to create a buffer that is similar to the call data buffer which um does not have a position in memory but it's a separate buffer and contains the Full returned B string and there are two op codes one of them is uh returning the size that which Returns the size of this buffer and which data copy which can be used in a similar way to call data copy to copy data from that b string into memory um there are I think there's there's one concern and this is the the problem that the memory of the col has to so it cannot be freed immediately after it return turned and this kind of this changes the the memory requirements a bit and um yeah I would so yeah um there was a proposal to um basically reset this buffer um whenever memory is resized and I didn't fully get why that can help so could someone explain that perhaps is Nick here I don't see him in here yet I'll send him the link to see if he can join I think I anyone have better insight into that yeah I think if y'all could pull up the page but uh Gavin I think it was Gavin who suggested it right yes and I think so gav is not here but I think I've seen also discussing thatan do you have any comments about that um hold on read through G here yeah he updated or about eight hours ago he added a comment too resist um Define any memory res in operation [Music] H so theoretically like calls are not necessarily resizing I don't know like I really don't like his suggestion because I feel like it would require us to add in a bunch of extra Hooks and in figure out like what what what resize memory and what didn't um certainly clears this buff so that's a but like there are other things like M store call data copy code copy and so forth where check if it resizes memory it's Dynamic so can you just remind me again what was wrong with like some of some of the earlier proposals so things like e 5 and8 where it only tried to like the when uh you did a call it would only fill up as much memory as it needed to instead of filling up the whole swice yeah the whole I mean the the the gas calculations were really complicated that was the main drawback for both proposals I would say is it just the fact that you'd have to add another gas check that's like in the middle of the up VM up execution and not just at the start or was there something else it's like I remember implementing I8 I in Python and all I did is I just moved over the one of the memory expansion uh check checks from the start of the code to the part of the code that actually allocates the memory at the end that it didn't seem more complex so one of the proposals has the drawback that uh the call up code can fail after so fail because ofas while it's already executing and the other version had the drawback that the call kind of has to reserve a bit of gas for the resizing the call as memory yeah oh right the problem with this one is that I feel like it's uh first of all kind of it increases the complexity of the object that has to be kind of passed around as computational state so along with uh memory and and stacking gas we also have we also have to worry about returner data but it can be generalized as multiple segments of memory right but like that's an even uh weirder yeah I don't see that as as a complication I mean return data is exactly the same object as call data or it's very similar and then we just have another one I think it's it's better to have uh more objects than more complicated noes um I don't know I mean I still don't so when trans ping this to wum I can handle it very nicely this way also so the another benefit of of this is that I know I imagine call as a kind of interface that might also work between two different kinds of virtual machines and if you specify it like that it's also so you don't have to specify the the so the memory can be an internal part of the rad machine if you basically pass on data and call data and turn data buff so the other thing that this kind of the other reason why this feels ugly at Le to me is that it kind of adds in technical debt because now for some weird reason every time a call finishes instead of copying data once you'd have to copy it twice or at least you'd have to kind of copy some point or twice or and and you only paid once is that the argument or well it's not it's not so much payment it's just about the fact that like this lots of extra weird stuff is happening some of which is is it ends up being kind of vestigal have to keep around uh you uh re explain that one so okay so after the if this gets implemented then there's going to be two ways to access the data of a call right one of them is going to be to access it from the default by a return data by array and the other one is going to be to access to do a return data copy and access it from there in like General having two kind of redundant ways of doing of doing something isn't really a nice programming practice sure that's because we have to retain backwards compatibility right well right even still though like I don't want if we follow that principle then like I'm worried the 30 years down the line we're going to have 50 of these in order to retain backwards compatibility and we can so we can say that return data is empty if the return area of the call is non empty exist which doesn't really simplify but at least there's only one way to do it at a certain time so you can't combine these two ways yeah mm uh so would this wait a minute mind so would it help at all to have implement or like little test implementations to see just how complicated it is or or would it be kind of not kind of pointless because we're still stuck on the idea of it potentially being complicated to maintain backwards compatibility uh down the line I can imagine what it would take to implement all three of these in Python and I still feel like 5 and eight are like two lines each and this will end up being like 10 or 10 to 15 or more yeah I mean 58 is it's another it's a small change to a rule that is already quite complicated and this is yeah and this one adds a new object to the to the state as we already said H okay so it sounds like this might not potentially be a good candidate for Metropolis due to some questions but uh if between now and the next allore Dev call there can um either be an alternative or people can uh come to agreement on it uh or I guess come around to the idea of implementing it I think this can be brought up again um but yeah I think we should continue the discussion on GitHub unless there's any more comments so yeah I mean I think this solving this whole problem is is is really important um I wouldn't say we we delay Metropolis because of that but um yeah yeah this doesn't yeah this doesn't seem kind of as important as other Metropolis cips but I I fly fully support continuing to various proposals cool sounds good any other comments Christian y all right sounds good so this one we will just continue um on GitHub so let's see the next one is the um robon spam attack so uh I am not up to date on everything so um if someone doesn't mind just kind of in a nutshell um just explaining what's going on there and if any um action is being taken um on the part of the devs to do anything cuz it's pretty unstable right now is what I've been Ing and additionally if it's actually if it's actually really needed for it to be stable for future uh testing for Metropolis or other things we're doing what is the current state of robon by the way is it still kind of fored or uh yeah so uh the current state basically is that so as far as I know par they just forked off their own version of robst so they roll back about 100,000 blocks and uh and started a a soft Fork from there um regarding the main chain it's kind of weird because at a certain point we converged on um on a stablish rockstand network and everything was starting to get back together and then all of a sudden uh yet again a huge gigantic heavy chain appeared so I'm guessing uh we have an actor who's actively trying to screw Roan so at point and the problem is that he actually so when he reached the blocks size of 9 billion and then when actually those 9 billion gas is used then it's a considerable memory burn on the notes so it actually can take about 2 GB of memory to just process a single block worth of basically due to the huge huge state so what we TR basically I'm not sure whether I agree with the parity approach in doing a softwork and placing a gas limit on top of basically they forked and placed the maximum gas limit on the blocks I'm not sure what that limit is nor where they where they from but so that's possibly um a solution that we can follow basically just release a new version of G or at least the develop version which uh which has basically bans the the current spam uh chains and just rting to some same state and then thinking on whatever the next best is which I'm assuming will be uh Ary do you have any comment on that well here right it's not like we're pushing it we haven't have not built it in the client yet I mean it's just a a file that users can use and revert to statement some of them data yeah so the the unfortunate thing uh from our perspective at least is that uh apparently parity apparently has uh the configurability to limit the the blog estimates via config fil to hard limit uh as far as I know other client has at least get does not have such a feature to the configurability feature to do to change protocol parameters at least this parameter so it means that we if you want to follow on this path we we do need to do some uh some development and releasing it's not something too hard but uh it's not something that we can just release in an hour so this um parameter that's configurable how is it normally decided is it just hardcoded or is it something that uh is adjusted by miners or users have to go in manually generally currently hard in the spe 4.7 million which is maximum walk so minus can still vary the G limit up to the max so I I was talking to Peter PR a little bit about that and and some people might might not like the idea of forcing basically a soft for the test couldn't we try to achieve the same thing with just increasing the difficulty on the test by getting people with GPU miners to mine on the death net and does make death net eer more difficult to get and maybe make the attack more yeah I think that's a good suggestion because I think the problem with trying to kind of push gas LS back into line by itself is that in order to make a gas an attack but the attacker has to have over 51% anyway and if the we down this 15 151% attack Avenue that and the attacker wants to keep screwing with us then the attacker we will just launch more traditional times 51% attacks over and over again so yeah it shouldn't be very hard to push the M it so M it enough to push out of the so so that the spam attack is just not feable anymore and also it replicates more the behavior of the main which is a good thing I think one of the problematic things is that um as so basically most of the clients have some sort of um reor protection so that you don't get to reor too large blocks or too too deeply uh basically gas Curr doesn't allow you to reor more than 60,000 blocks and I'm not sure whether I think well par has the limit that uh you basically cannot reor deeper than the pruning limit which is whatever I don't know a th000 blocks maybe so it's uh the problem is that in in order for us to to actually dump all this crap we need people to think from um from a previous point now for G I can do this so I'm what I'm working on is to so in G we have the concept of bad block so in a release we can add a bad block and then if a client sees that this chain contains that bad block it will just delete everything afterwards and start sinking from that point and uh and I'm currently working on a on a minor modification so that fasting can be resumed so that I can basically delete everything even if use user was passing and then it can the user can actually proceed in a decent way without having to manually mock around so I can do that I'm not sure whether for example par could do that yeah have the same mechis basically then I guess we could try to could try to push a a new chain that um we still would need to do um a manual release in order to force uh clients to basic to dump one of their chains okay so um Ary is there any strong conviction to maintain uh the fix the way you guys implemented it or would it be uh potential like a possibility to get in a chat with the rest of the um client devs and and see about this alternate way of coming uh to a consensus on which uh chain to dump and which block to continue on sure I mean it doesn't matter much we're fine with whatever makes sense M that particular block it was uh before the B of the attack has started it still has some State BL into it in there but not as much as was added in the following vs okay and this um Peter the approach you were talking about does it um How much would it actually uh make some transactions that have occurred invalid to the point where uh like test daps would lose some of their state and some of their uh changes that you know they've pushed to the network well consider that it's about 150,000 blocks so yeah I quite certain that it will criple stuff okay there is a a high enough probability that uh that the transactions are integrated on both chains but uh I'm almost certain that some deps will get screwed okay sounds good um or I mean it's not ideal obviously but um good that we have Clarity on that so um not sure if there's any way to avoid that except to I guess pick the most used chain or um Fork robsten which would be complicated in itself I'm guessing but one thing that so one thing that we can do is um we could uh try to stick with um stick the par chain because that they seem to have figured out a nice block number to Fork from and and maintain a decent semide decent chain so I'm fine with uh with continuing on that one um I think the question is how can we ensure that all clients end up somehow on that chain and also it would be nice to then figure out how to remove the block limit because I personally I'm not really and kind of feels weird that we have a block limit on that but still it in order to remove the block limit it would be nice to know how we can protect against um somebody trying to scoot again yeah I would imagine it would be more difficult to provide an incentive on the test net at least for that to happen I guess it wouldn't be impossible it would just be getting people to combat it with their mining Powers the only way I can think of um anyone else have thoughts on that vitalic so for example there's one guy um who's at the certain point he was running one of the biggest mining pools on ethereum uh he he actually offered me personally that uh if he can afford to sacrifice a few of his gpus to just try to push whatever chain you want on a oh okay well that's pretty cool then um yeah I I think that's a good idea then so let's um go ahead and take this this wouldn't be an EIP obviously uh we can take this into the allord devs channel on getter and um coordinate with all the clients and actually um uh Jan or um Anton or any other clients that are in here do you all have any opinions on this or is there going to be any issue uh implementing this on your side no I don't think so so one one possible solution is that U so one workable solution is still that we try to push uh push one chain that we pick as being the canonical chain and make it heavier than whatever else is out there and then all clients would automatically sync to that without having to do any modifications so that's also possible so I think if parity and G can agree and can somehow sync the same chain correctly then the remainder of the clients can automatically stink if chain becomes longer I think G and Par the important CH important clients to ensure that this thing correctly because both G and parity have have cashing power on the test n so if either of them picks a different chain then split yeah I would say the top the most used clients for that would be gu parody and ethereum J um just because I think Harmony might use that test net as the default um I'm not positive uh but yeah it sounds like cuz Anton said that it wouldn't be too hard for them to do something like that we can just coordinate this in the getter channel uh so any other comments on this okay great um I also saw in the last 24 hours uh this is item number three by the way uh there was some discussion about um miners not um or miners using the old recommendation for gas price uh can anyone give kind of a quick synopsis on that and uh what's been done um sure so basically the idea here is that there are um the um my so in general right now somewhere around e 20 Shannon or somewhere slightly above 20 Shannon and uh the some people are basically concerned because they expect that if uh the given that the price of ether has doubled over the last couple of weeks the eom gas price should go down to compensate so the transaction fees don't get too high um so the uh the challenge is though is that while the idea that gas be in of ether isio in the in in the current environment the situation is a bit more complicated because the basically the only reason why um that miners have right now to not include transaction isn't because of they want to have space for other transactions or the gas limit it's because they're a rate of increasing the the probability that their block is going to be at un right so like this this is something that a lot of miners started taking more seriously back during the DS attacks um and but the basic principle is that if your blocks that are larger and therefore more likely to not yet propagated in me about this and actually Peter prer from ether scan made a couple more regressions today and he discovered that uh the um C the kind or gas prices gas price where of the revenue they get from fees matches up with their with the cost that they have to pay for from The increased Uncle rate um the the equilibrium there is around 19 Shannon right sorry that's Peter presser from My3 chain statistics SL gas price I could actually paste this into the tsg chat room there it is okay so right now I think yeah so so there's if we want to have a uh or if we want the gas price to go lower then basic think aside from some constants would be to that to look at the way that [Music] has all it actually makes the miners much less willing to in transactions than the otherwise would be um Can people still hear me by the way yeah sometimes your connection gets a little bit slow but it just um it just it doesn't actually make you go away it just uh slows down uh your speaking for a second so you're still somewhat um okay sure all where where did the link go ah thank you yeah I just pasted the link but it doesn't seem like it's appeared in the chat yet got it now oh got it okay there it is yeah yeah so basically the challenge is that if you look at the average Blog the so the average openboard it's around 3.4 ETA ether but like if um uncle inclusion was perfectly efficient it would be all the way up to 4.375 and that would actually reduce the equilibrium gas price all the way back down to like six or eight Shannon so I remember that some developers started look like looked briefly at why this was happening and I think basically the problem ended up being that there's a bunch of situations where when clients receive new blocks they end up kind of not adjusting the not adjusting their work quickly enough so the old Uncle um or they basically don't add uncles in until a block a block after when they should when they should be adding uncles into the into the pool the pool of uncles that they're trying to create blocks with [Music] so like if but basically if we want Fe to go down then looking at looking at that would be one of the simplest or one of the easiest approaches aside from this the only other thing would be as I said a hard Fork to adjust some constants to try to incentivize miners to push more transactions on but I don't think it's at the we're at the stage where that's needed so the non hardfork solution would that just be I guess would that be considered a soft fork or just an education for Min Fork it's not even a fork it's a strategy changing the clients and in fact it's a strategy changing the clients that miners should support because it would give them more Revenue ah okay so it sounds like it's a duel changing uh the clients changing how they um yeah some of the stuff for their defaults and then uh having something that shows miners the um the fact that it's Optimum uh and part of what I was thinking is maybe uh I know that there's for the Bitcoin Community there's certain uh sites that show like the optimum uh gas or the optimum uh transaction fee in order to get your uh transaction on the network I wonder if there can be some kind of uh very basic like one page site that shows the optimum strategy for miners to make the most uh money at the time using a formula I link to it for two minutes ago oh great awesome no like the thing is like that's their Optimum gas price right the optimum Uncle inclusion strategy is something that would have to be coded into the clients it's not something that you can kind of set e got it okay that's different than yeah one of the parameters they can set okay um so yeah let's uh let's start with parody parody do you have any thoughts on that is that something that could be agreed upon and then changed well yeah sure we did a number of tations on that so as for the gas price so by default we have it tied to the either price USD but as far as I know major pools just don't use default they override specify price okay sounds good and then uh go team I not entirely sure what the change would entail we can change whatever so it's it should be fine if there's a clear thing what to change uh just to react a bit to the um RT's dollar approach I think the problem is uh one of the problems that I see in the network currently is that even if miners kind so the problem if miners override the defaults and apparently they they do then uh then if average nodes do run with defaults which are below what minor say then it might happen that the network starts to fill up with Spam transaction that does that just circulate over all over the place without actually any minor including it so that's uh that's my main issue with u with dynamically adjusting gas prices that somehow average nodes need to adjust to what miners do not to what the defaults are yeah the way one on this General topic I just wanted to uh make one suest actually ask maybe this already exists but if not make it a suggestion which is that aside from just being able to choose the gas price in terms of the number of way maybe make it possible to choose the gas price like either even like in web3.js as either a percentile or as a multiple of the a of the average that gets included or something similar the idea would be that that would just make it easier to pay more to get included quickly H is there anyone from web 3js in here that can comment on that I guess it would be Alex or Martin come here but he I think he was busy doing some other stuff I don't think the problem is including it fast I think the problem is uh that how can we lower the gas price without opening up the network to deny a service attack so basically we cannot lower it personally sorry for myself personally from a user experience experience standpoints inad of like that is something that people it is a functionality that people I think wants to have but uh you I I I do agree that like there is this other problem of how do we get miners to accept lower fees and then how do we get miners to accept low lower fees without um or how do we allow lower fees without making de situations worse um so on the third point my current instinct is that uh I think first of all regardless of whether fees are low or high like there's there there is a risk that attackers are going to be willing to just make full blocks and just fill up full blocks forever whether that's an attempt to make the blockchain not work well or whether it's an attempt to BL bloat the state and I think uh if I mean if it's hopefully know once we get or if we're comfortable that all of the anal service issues are fixed then theoretically like even if blocks are being 100% spammed the whole time like that's something that noes should theoretically be able to tolerate but in terms of State size growth I think that's in area where if we wants to mitigate it then we'd have to rebalance gas off code gas prices again so it sounds like there's not a quick fix necessarily but as long as the uh cost versus benefit is on the benefit side for you know enabling people to um I guess have more freedom to choose uh I think I think I'm following that correctly than that would or to choose the um gas price when they're actually sending their transaction uh that that can alleviate some of the um issues that people are having okay so on on that on that area it was r t Wasing and what I've seen is that oh Alex could you get closer to your mic hi sorry can you can you listen to me yep we can hear you now if you could start over Okay so uh I I run some statistics in this and over the last thousand blocks of all transactions were included over 75% of them were exactly 20 and less than 1% were free and only only and only above that they are they are so basically that means that most people even though that even though in M we include this slider even though in M we include the slider most people don't don't change it to make it larger and if you put it smaller Shon the transaction will never never be accepted so most people do not change the default slider okay I mean if it's not too pressing then that's fine but it's still a nice to have yeah I I definitely agree that the when the price Rises the the idea that the transaction cost should go down is something that most users expect okay so yeah that would be I guess the a suggestion for the web 3 team right for the web treat team sorry what why the web treat team oh okay maybe I'm not following this correctly but I thought it was the user being able to or I guess they already can adjust that and missed never mind yeah they can adjust as Miss but if you put it lower than 20 Shannon then your transaction will not be relayed and you will not be included in any okay so yeah if if everyone else doesn't think it's a pressing issue it doesn't need to be resolved today necessarily so any other comments so I do think it's a a semi pressing issue at least we don't have to solve it now but it would be nice to solve it rather in the short term than the long term the so basically if you can figure out how to prevent the nwork from being dosed offline I'm fine with whatever solution um Peter can you just clarify you're specifically concerning about does in terms of kind of shortterm impact so like pushing onc rates very high making it hard for notes to stay synced or are you talking thinking about more long-term dosses that try to blow up the state to make it really big over the course of a couple of months actually I wasn't talking about the blockchain I was talking about the networking stuff so okay okay I agree that's something that probably needs to be studed much more so um I think last Christmas I mean 2014 or 15 Christmas um there was an issue Network that we were proping every note was just sending around tens of thousands or hundreds of thousands of transac invalid transactions and it was actually slowing and we did fix that issue but uh but was kind of an eye eye opener that a lot of things can go really wrong if you allow on basically transaction if you allow transactions to circulate the network that will never ever be included so it's it's not something that we should lightly in add yeah so just to clarify the the the problem is that even though parody miners um if they use their defaults they'll mine uh you know they'll accept transactions at 10 Shannon with gas pric of 10 Channon um the gas nodes won't relay those transactions so effectively the um it's un you can't broadcast a a transaction with less than 20 Shannon because of guest relay policy so Peter uh is that something that uh sounds accurate for the way gu uh operates on default yeah yeah that's that's absolutely how it operates but that's also kind of my point that if uh if uh if you start circulating transactions that won't be included by any minor then you will Tri on the network okay so yeah unless there's any more commment it sounds like this needs more sounds like this needs more study so um uh for examp one thing that we could try to do is U So currently all approaches to tie the gas price to the dollar value uh although I really I really find that a horrible idea from a centralization point of view because it means you just pull an API of one of the exchanges and hope that it won't your entire network up so that's my biggest issue with it because you're kind of placing the whole fee Market in the hands of an exchange but if you can tie it in a more or less reasonable way to the dollar value then maybe at least miners but probably there will be some miners who won't manually change it so maybe they will at least I don't know maybe we can try to play around with it the problem is it's you won't see the negative effect soon and by the time you see the negative effects is too late to fix H oh AR on the parody client is there any um I guess like plan if the exchanges or whatever data sources manipulated is there multiple data sources that are pulling for that um uh US dollar price currently there's just more data source uh but it's checked for being same I think yeah and yeah you can always override it okay say is really um so if given that ether price is around uh $20 currently I would say that uh five between $5 and $100 everything would kind of look same so but it could really impact the network a lot H okay so there's a few different so yeah it sounds like there's a few different suggestions uh Peter if you could um just do just a summary write up of uh kind of what we talked about on the issue we can um circulate that for more discussion and see if we can't come up with a uh short to intermediate term solution um unless it's something more pressing uh I don't exactly have a grasp on how pressing or how tight it is to the price so yeah definitely I'll I'll try to summarize some stuff and at least voice my concern so that other people can also read through it and then we can figure out okay great yeah if you write that up and send it to me I'll uh circulate it on the appropriate channels for parody ethereum J uh Ruby all the other ones and maybe even Reddit if appropriate sure I think I whether I I already had something like got up after oh perfect okay um any other comments on that um yeah just add that the um the transaction relay policy is important to you know uh I think it's worth an EIP to specify you know the working layer the transaction relay policy because right now the the abstraction of um of transaction origin um you know the account abstraction uh it won't work if if guas nodes uh don't relay um transactions with with zero gas price H so is that something oh go ahead so uh let's suppose that we we start laying transactions with zero gas price and I start firing out um contract calls from u a million different accounts all at the same time since it's zero gas price it means that they are all valid what happens then in the network so that's one of the I guess spam dos vectors that you were referring to earlier yeah so the problem is that I so um I can basically turn out infinite number of transactions that are completely valid yet they will never ever be processed and I can the problem is that uh given zero gas price I can actually create new brand new transactions I can just create them as fast as I can and shove them into the network at different nodes and they will start propagating it and even if they drop some of them I don't care as long as they propagate something the network will will start getting sluggish okay that does sound like a concern okay so yeah um any other comments um otherwise it sounds like Peter's going to summarize all of this since it's an non non-trivial but you know can be solved issue oh Daniel your microphone [Applause] it prior so attacks can be mitigated by a prioritization of forwarding transactions and not necessarily some kind of policy that's my only comment uh uh so Daniel your microphone just went haywire and sounded like uh robot who is screaming for dear life uh if you could uh repeat what you said and just look at chat we'll tell you it or the chat in Google Hangouts we'll tell you if it does it again if you can adjust anything and it it might be a combination of your microphone volume uh input volume and uh your how close you are to it okay is it any better now oh it's perfect now so if you could just repeat what you said Okay so I said that my only comment was that H it is not necess the solution to these dos problems is not necessarily A Hard cut of policy of whether to forward transactions are not forward but it might also be sold by prioritization that if a node is having many transactions to choose from then it might choose which transactions to forward first that might also mitigate those attacks as described by Peter that was my only comment yeah that's uh true the the problems start happening when for example I would an attacker would try to propagate uh transactions that cost a lot of money yet they will not be included for some reason and they actually might uh prioritize out legitimate transactions so there's for example I'm a I create a transaction that requires 4 million gas but costs Little D Chanel and then a ton of subsequent transactions that are really uh really really expensive but since every each of them would consume a full block um or maybe I I create 10 blocks worth of transactions really cheaply and then a ton of really really expensive uh transactions and then everybody will be spinning around the expensive transactions where whereas they will won't get included anytime soon and the legitimate transactions get uh starve I'm sure it's it's possible to solve it I'm just saying that it's not uh not an obvious solution okay so yeah it could even potentially be a combination of the um some of the things you talked about and optimizing uh what gets re relayed um so yeah and I guess it's what I guess you have to also judge if these rules or these changes would even be followed or if they can be made in a way that you know everyone cooperates for the best interest of either themselves or the network uh so yeah this is an interesting problem um yeah any other comments on this okay so yeah uh the last item uh that's officially on the agenda uh and just by the way before we go into this fourth item is there any other ones that didn't make it on the agenda that someone wanted to cover uh after item four no okay so we're going to go ahead with the agenda item four which would be the Metropolis EIP um so from my perspective of where we're at with that there's going to be some there's some people who are formalizing them and PRS uh the EIP editor team has been going in and uh providing suggestions or uh getting them to conclusion um as far as uh making sure that they're syntactically correct by the EIP standard and that there isn't any glaring airs uh does anyone else have comments I know vitalic has written uh a good majority of them or maybe all of them so you can go ahead with your summary um I mean I don't H I don't think I have any serious new updates on any of theop my smok well um working with Christian on on finalizing some of the Privacy related ones going to be working with jessu on implementing them so that would be elliptic orves and pairings um aside from that I don't think I've had any new insights since the last call okay about a month ago I know um Martin Hol snd had brought up the um the issue of the difficulty bomb is there an update on that as far as the network changes that may have prolonged that or if there is something that needs to be planned in um what time frame practically speaking I think it all has to be prolonged um so I did the math and I it's uh I actually I can just redo the math right now hold on um this is just on what the ice stage is going to look like yeah cuz I feel like there should be somewhat of a at least a an Emergency mitigation strategy if needed uh at minimum but also just kind of thinking about if anything needs to be done okay there I'm going to ran my script with the latest data and it looks like at the end of March the block time is going to be around 14.6 seconds at the um end of June it's uh going to uh uh go up to what it'll be at about 20 20 to 21 seconds and at the end of August it'll be 32 seconds okay as far as yeah as far as mitigations go you know [Music] I for example is that in a difficult calculation function we would basically add a um add let's say if the block number is less than four million then use that if if it's the block numbers between four let's say four and six million then just use the number four million and if it's above six million then use the block number minus 2 million so we would just add a kind of artificial discontinuity okay and that and that's something that would hold up all the way until um the potential transfer from proof of work to proof of stake yes yes so an update on the transfer to provoke stake by the way is that with my latest kind of thinking and I mean if you want more details like I wrote a bunch of com medium posts and I'm going to keep writing more is that it does seem like we actually there actually might be a possibility of doing a kind of slow transition so where we would go switch from proof of work to proof of work with proof of stake running on top that doesn't really mean anything to hybrid proof of stake to kind of more fullprof of stake over time so like even though like I'm implementing 100% of that road map might take longer so like I could see it taking more than a hear I we would get to some of the earlier stages possibly ahead of schedule so that's just like information to think about yeah I've recently uh heard an interview with uh Rick Dudley I think that's how you say his name uh where he was mentioning the um I guess the certainty that there would be a a time in the transition process where proof of work and proof of stake would be running alongside each other um and also figuring out I guess have how the EVMS are going to uh I guess work beside each other or if there's complete compatibility um complete compatibility with evm one versus the evm 2 so yeah my question basically is the um uh for the p uh p and POS running alongside each other would that be something that uh is still a little bit unexplored or is it pretty much known that uh through these transitions that it's going to take months uh to kind of decouple the two so what do you mean by decoupling so running them at the same time at what okay so it's not going to be two blockchains right that's oh no not two blockchains uh two uh so proof of work and proof of stake at the same time Al right no problem yeah so the idea would basically be right that uh we could first implement the proof of stake part very conservatively so that the proof of stake would basically only find blocks after proof of work as like de facto finalize them anyway then over the course of a couple of months we would Implement clients that would favor the proof of stake for Choice rule then we would probably cut down the proof of work block reward increased um add a proof of stake valid dat reward then we would um Implement some hybrid proof of stake scheme that would let us kind of parameterize between proof of work and proof of stake on a zero to 100 scale and then we would just Implement Implement that and uh so the first part would not even be a hard Fork it would be like a very weird kind of soft Fork the um and the second part would be a hard Fork but it could be one that kind of eases into the new version over the course of maybe a 100 days or something okay so it's just more of a an issue of implementation and coordination once the research team I guess somewhat officially wraps up the uh process on uh how that can go okay sounds good yeah so by the way stage one is already being implemented in the form of python Diamond RPC oh okay so it uh is that something that's also in any other clients or just um oh implemented not actually theoretically can talk to any client with our PC oh I see um so my in would be to keep it pure python for now because it's still kind of in iteration mode but once it settles then it should probably be implemented into clients directly okay and the timeline for that is post Metropolis it sounds like yeah yeah for implementing it into a seven clian as post Metropolis for doing it in Python it will Happ it in parall we can keep doing it in parallel okay sounds good so um I guess if I were to create a summary on the Metropolis stuff uh EI are seeming to go well uh there is some discussion on them uh we're going to continue to monitor the PRS um and the editors are going to uh look to make sure those are moving along and don't get stalled as far as discussion and other things are concerned um and then uh oh finally is there when is the when is there a need to actually put a block number down for Metropolis it sounds like the last time we talked we uh or actually two meetings ago we were talking about uh making it a fairly conservative um fairly conservative number to allow a ton of time for testing and to uh have less rushed hard Fork uh in order to avoid any issues we've had previously unless unless I rushed hard for to actually do Metropolis yeah when you actually do Metropolis because um I mean Homestead wasn't rushed either but like some of the recent hard Forks there was a Cadence of you know having a hard Fork performed within a month just because of having to mitigate attacks and other things so I guess this one yeah oh you can go sorry I didn't quite all that yeah so I was just saying the Cadence of recent hard Forks has been rushed so Jeff um iterate or Jeff implied uh two meetings ago that we should be given plenty of time so is there any comments on um how much time that should be or if there is a need to actually set kind of a rough time uh in the next couple of weeks or something to make to decide on the block number or things like that so I don't think we should be deciding on the block number until the C+ plus client has created test and until all clients are the test um the thing that we can decide is delete time so the time between I recommend making a starting to to go longer for that so like maybe go up to something like three weeks okay yeah that sounds reasonable or 3 weeks pending any issues that may arise that would yeah yeah okay cool yep that sounds good any other comments on the Metropolis eips so I have a quite specific question about the account abstraction [Music] um is it the case that if if we have this special zero signature then the sender is set to uh minus one air quotes uh for all um yeah okay so anyone can spend uh money that might be there for example yes okay right sounds good any other comments on Metropolis um I think it'd be good to have a an idea of when we're shooting for you know to do the fork whether you know it's in August you know is it would it be okay to do it when blocks are uh block time is 30 seconds or would we prefer it closer to you know 15 or 20 seconds my personal preference would be um and would be end but so yeah and that kind of sounds like it's dependent on uh the implementations and the discussions over what's implementation longer than we obviously end up happening a bit longer or okay there can I guess I I agree with Casey that there needs to be um I guess some sort of at least assurance that there is a time frame we're shooting for in order for the network uh block time to not go up to an unsatisfactory level for the majority of the or a level that the majority of the community would think is an unsatisfactory level [Music] so one concern is that if the block times get too high then a lot of hash power might might switch to um you know a more profitable uh um I would argue that at this point ether is just like so far ahead of other C other cryptocurrencies in terms of uh dollars per second that I'd argue the number of people the number of risk of that is is is actually lower than the extents to which you make people happy by temporarily reducing the inflation rate okay um sounds good and I I guess actually did them that back when ether was at $5 I would have definitely suggested much more caution but and sorry back when ether was at five and zcash was at 50 but now that ether is at 19 and zcat is at is at 40 it's uh actually yeah the concern is that is f further away okay and if there is a change such that uh somehow we get back to the state you were like uh or the conditions not necessarily the price of $5 but other conditions in the cryptocurrency ecosystem uh would this be able to be the time frame adjusted and we feel safe enough uh to do it by would it still be kind of an shooting for end of June or would it need to be pushed up quicker for uh Casey's concerns I think end of June should be unobjectionable because look 20 seconds versus 14 point of point2 isn't that much but uh if once we start talking but 14.2 versus 30 like that's a different issue so if under those conditions yes we'd have to probably push Metropolis up ahead and kick out a future or two okay sounds good so yeah we can cross that bridge when we come to it it sounds like um and we'll just be monitoring that over the next few allore Dev calls um any other Metropolis related uh comments um what Christian I wanted to ask what has there been progress on implementing these in C++ and um when does it look like we're close to having tests for them um the blocker currently is integrating lips not properly impementation should be 100% finished so some tests perfect yeah in that case I'd recommend starting tests for everything except for the snark stuff and so so sorry uh no so the SN stuff is implemented the rest not yet or what was the question oh yeah I mean I was I was asking about the uh the all of the Metropolis features other than the snark stuff no no okay sorry yeah no we we started work on on the other stuff and the snark stuff snark stuff is most is okay got it thank you that's okay cool any other clients um wanting to comment on their progress on some of the implementation um AR I saw the parody team I think was in the process of uh at least doing initial implementations of 86 yeah that's right it's a work in progress so yeah mostly we're waiting on the tests that's the most pressing concern so concerning 86 um this current test INF structure allow for these tests because I mean when when when transactions come in Y block they should all be valid right so what I'm saying is we don't have test infrastructure to test the mining strategy right right and yeah we haven't imped that at all all right sounds good so we're waiting on test and then um that'll help with testing but it sounds like we're still at least finalizing some of the specs so that that can definitely happen in parallel yeah in general if we want to uh test mining strategy then one thing you could do is you could just put your Miner up on robon and on robon check you know if you create blocks then make sure that the uncle rewards that at least that for Uncle that you're including are at 4.375 okay so that can even be coordinated if we want beforehand if we just um figure out the robsten miners if they if we can just ask them to do that great well this is a strategy thing so it doesn't really need client coordination oh okay oh so yeah that that's right cool and then um yeah I think is there anything else Metropolis wise anybody had a comment on [Music] can't think of anything cool uh quick shout out to yoichi's uh work he just released a blog post on um formally I guess formally verifying some of the um uh or I guess it looked like it was putting it like graphically some of the things that uh are coming up for proof of stake and some of the stuff the research team has been doing yeah so that was uh theic version of Pasa and actually uh this week V Samia came to the building office and now V and I are doing something similar for v c and I think I mean we are now I'm explaining everything to these machines so now I think this helps explaining things to people as well so yeah clarifying lots of things awesome sounds good um yeah good job and uh F last point is that the EIP editors are uh currently meeting periodically to go through eips um again if anyone in here has an EIP especially one that is mid 2016 or older if you could go in and update them to say this is something that I still want to do or this can be closed or close it yourself that would be incred helpful cuz we are crunching through I think 156 or so eips that are in various States of uh abandonment or um just like some in progress stuff including stuff from 2015 so uh yeah if you could go in there and do that that'd be very helpful um and then we're also uh checking the PRS fairly frequently every few weeks to make sure that uh those kind of stay in line so um yeah I think other than that is there any other comments from anybody yes just one quick question uh on the last meeting we Robert proposed a semiformal EIP that we should dump the eore compile rpcn points and I think this kind of makes sense and most of the people agreed I think he also proposed an EIP Bas the link and more or less everybody said that it's a good idea so as far as I apparently already merged in uh PR to delete it we also have an open PR uh my question is if we're is this something that we're going to through with and if yes then probably we can just accept it as a accept thep or something unless someone objection so the most important thing to watch out here is to uh update the tutorials accordingly right yeah I would agree yeah so that's that's a valid point um yeah and would this then be handled by the uh group that makes the DAP Frameworks I guess as far as once you take it away so as Robert I think Robert also pointed out on the on the issue uh I mean the EIP proposal that the problem is that uh nobody really uses these end points Point anymore because for example many people want to select which version of s they want to compile with it's not possible to do that then some it's not really so I don't think people heavily depend on these kind of things maybe you can shout out on Reddit to just ask whether somebody's actually using it but it's actually it doesn't really make any sense to use uh e the underscore Compass solidity versus just using soulc directly okay so I hear a lot of uh yeah people coming in asking about how to use so that it doesn't work basically and I guess it's all beginners who are trying to follow the tutorials okay so updating the tutorials would need to be something that is um looked at and right now the uh tutorials or at least the ones that the foundation has more or less produced are pretty outdated themselves so that's a whole different issue uh but inside that we can kind of discuss um how to move forward with that in the best way actually that maybe I'm not sure whether you guys have a some tutorial page for solidity because I know that for example the go ethereum Wiki Pages Somebody Sometime two and a half years ago maybe Victor he wrote um some solidity tutorials that are horribly out ofd and in all honesty I don't really feel that tutorials should be in the go ethereum wiki page because they have nothing to do with go ethereum and honestly I don't think it's it's something that we as the go team would like to maintain but nonetheless people do find it and then people come nagging us that it's outdated and yeah it's it sucks that it's outdated but we don't want to maintain solidity TS nonetheless I I actually was not aware that there is a tutorial on the on the Keith Wiki I was maybe talking about the tutorials that are on the ethereum.org website M so I think that it would be a really nice thing if we could uh maybe have a more I wouldn't say organized approach but maybe an organized effort to to try and maybe create a tutorial page that uh that we can just link to and then at least we can maintain only a single place and not yeah ethd do.org was our initial attempt at that and that's kind of uh Fallen as a not a priority compared to some of the other stuff the maintainers were doing so I might do a shout out on Reddit to see if anyone wants to pick up on that and anyone here uh the ethd do.org there's a repository in the ethereum uh GitHub account that's called like Homestead docs that really needs to be updated uh to something more generic but um I hopefully we'll have time soon to do do that there's a few things more pressing uh cuz I was one of the main maintainers the other ones were Bob um summerwell and uh Victor Tron and I know Victor's been all in on Swarm and stuff lately so I know he can't maintain it so it's more of a uh an issue on that front of finding someone to maintain it and keep up with uh the changes so I'll I'll see if anyone in the community can take that on along with maybe someone who works on a core client just helping with their p of that and uh yeah so that's pretty much uh the deal with that and I I'll comment on the EIP uh to see uh how we can move that along uh as far as a plan and what type of EIP it should be cool is there any other comments great all right I think we're good here I'm going to upload this recording uh in the next few days I'm behind on uploading the recordings but uh that that should be fixed pretty soon I'll have 10 and 11 up so uh thanks everybody we'll have another meeting um I guess in two weeks uh which would be the third Friday of the month we're we're on a Cadence now of the first and third Fridays every month so uh thank you everybody uh have a good weekend byebye thank bye byebye