Address Space Extension Working Group #2

Transcript

how do we wanna i mean do we wanna continue to kind of go over the issues document of course we kind of already went through most of it yesterday we can kind of just finish that and then do kind of branch off from that or what we didn't yeah i think we in detail we only went through like four or five points and then rushed through a few um but you know i think the bigger discussion points are uh we're left open okay sorry yes it felt like more like a like first exploration call right maybe clarifying some of the the core like baseline

questions um but not anything related to the implementation right yeah then let's just pick off where we left left off yesterday and pick up where we left off so um who who shared their screen yesterday was it micah was it you who i i forgot i think it was micah it wasn't me it was me would you be willing and able to do that again today sure awesome i think i'll actually have like a better overview exactly of which point we discussed in what detail so if you just want to

take it from from the end kick ass off look nice yeah i just need to exit the full screen stuff zoom dead okay yeah so we skipped a point 2b so that's right in the middle there right the collision resistance yeah so just yeah an issue with the translation map is

if you try to i mean basically fit in like uh you know a long address into a short one in the translation map i mean one of the main goals of the long addresses is just to increase collision resistance and the second goal is to maybe have a field for an epoch um but yeah i guess outer space extension was proposed maybe initially really through the state expiry as a dependency but then there's also an argument made that it should stand on its own just to increase collision resistance in in

ethereum but the translation map itself has this problem that it definitely increases i mean address phase extension increases collision resistance within long addresses but if your translation maps your decreased collision resistance within the short addresses because you keep adding more short addresses which are part of the translation map um right and i guess this is a bigger problem if you have a um [Music] a long-term uh translation table with maybe if you have like an ephemeral table maybe the the issue is is a bit different

i mean it seems like it's an issue nonetheless right like if you have a i don't know some defy smart contract what a smart smart contract that is deployed on the new and new outer space and everything behaves well but then it also interacts with some old die token or whatever and it has a balance in there and then all of a sudden you can deploy a different attacker contract that of course if you were the person that found the kind of the birthday tag collision and and so kind of like also deployed this honeypot honeypot first contract and then you can just deploy your attacker contract later and clear out the balance of that other contract in in an old token or something um that seems like a really unfortunate situation

um and it seems like it would be possible like even even easier in a sense with the ephemeral table because there you wouldn't even be able to detect it because you keep no track of all conversions whereas in the if you have like a permanent persistent kind of table then at least once the the honeypot address is in there you can be certain that you can't override it in a sense i guess it also depends on how the like the ephemeral version works and i guess this problem also depends on how the compressed address is is calculated um how do you mean that

so if you look at the um how to to grind for the collision um spread of what i don't remember what's the eip number um you know as part of the having a address um which is a contract address but also has an eoa key oh you mean reject transactions from tenders would send us with the code yeah there's a link to document there um explaining at least the um the current best practice to try to grind for that and that that also depends on i mean you can make it more

hard to do that depending on how you know one of the the addresses you're grinding is as is created if so this problem i'm talking outside of the justice extension just for the regular keys and contracts this problem was much less pronounced with alt create because you also had the nonce and you couldn't just infinitely increase the nonce so you would have needed to to create new sender addresses so it just involved more hashing which makes made it really infeasible but with create 2 you just need to you don't need to do hashing twice you don't need a new

sender you just need to bump the salt so basically announce um in the same way depending on you know if you have like a double hash in the compressed addresses then um then it's it's it's at least with the technique described in the ips it's not feasible to to create a collision at least today wait how's that not just a 2x slow down for like two hashes instead of one or am i misconceptualizing something here uh but i don't think so indeed it was a pair yeah in the eip i don't think

it's it's just a linear process they're using some other trick to to build up um i don't fully remember but you know it's a it's much more optimized than just running multiple hashes that's yes okay um okay so we can try and make it more collision resistant at least sorry i might could go ahead i have two questions one why is the 80-bit collision resistance instead of 160 this might be i think that's simple because of this birth attack thingy where basically you can you don't like it it's 160 bit if you try to kind of like find

like a collision with my address where basically you pick one that that's really kind of like you you want to attack and then then it's 162 to find the collision for that but if you just want to find like a random collision between any two addresses then you can basically come from both ends at the same time kind of like a birthday situation where yeah so that's my understanding at least okay i mean if if cryptographers say so i will believe and believe them uh i'm just surprised that it drops the click resistance that i have and the in the linked document in the eip there's a description of of that basically if you control what address you are i mean if you're in

total control in generating this collision and you're not trying to create a collision to an existing address um then then that's the case but you're just creating a collision to any existing address that's still close to 160. and this takes into account the fact that you can't realistically store all of the things you've generated along the way yeah i think so if you actually generate like keys until you find a collision you're going to run out of memory long before you run out of cpu power yes

yes so there's a fancy cycle finding algorithm um so you don't actually have to store things you just have a system where you start at one address you then randomly jump to an another address and if you've ever found a collision the whole thing will come around in a cycle and you'll end up and you then detect this cycle and eventually you like then look around the cycle and find the two okay so fancy math and algorithms gets around that problem basically yeah i accept that so and then but we do have a good understanding how easy it would be to make a translation

map like easily make a translation map resistant enough so that it'll kind of like give buy us many more years of collision resistance without making it like very inefficient to use normally for normal kind of usage inside the evm well i'm not a cryptographer but it seems like if i mean just a really simple option seems to be like using just a double hash for the compressed address that would make it significantly harder but yeah i guess proper input from a cryptographer would would be the best

approach here right and also of course important to note i think yesterday we talked briefly about how if we could kind of make compressed addresses be easily distinguishable from just normal legacy short addresses with like an extra prefix or whatever and that would kind of like of course completely give up on collision resistance because they would have to to well not completely at least but it would make collision resistance like in a significantly bigger problem because we would have to give up on several more of the of the bytes of the 20 bytes so then it's maybe 17 bytes or something um of an extra compressed hash yeah does the does the translation map actually reduce

collision resistance at all or does it just leave us in the same spot with regards glitch resistance i think it makes it worse actually because well it has a potential at least two because um on normal mainnet right now uh you really only have a problem with counterfactual contracts so like once something is deployed um you're safe basically and i think we kind of lose this property potentially this kind of depends on the the specifics of how we do translation mapping and everything but you're assuming that we go forward with the uap that doesn't allow um trenton jackson's from

a account that or from an address that has contract deployed yeah i would be very certain that we have that in place before this ever becomes a problem again but yeah yeah without that of course you're right okay sorry so you were saying that the this makes it easier basically like well definitely it just it depends on no no it doesn't make it easier to find collision it makes it easier it could make it easier to to exploit that depends on on the translation map specifically used and also yeah it just introduces a new way to

to do that so you can you can create a collision in the translation table compared to so the whole problem with the translation table is okay there are multiple facets to this but just one facet is that from legacy accounts um if i mean obviously the the what you mentioned is there's no way to distinguish whether an address is a legacy or a compressed address and then from a legacy account perspective if something is in the translation table they can only access the the the translated version of that account

if something is not in the translation table they can only access you know whatever that short address refers to and they have no means to to see if that that is an actual account or that that's supposed to be a compressed address or not etc and and then that's the the i guess from the the the new account perspective we may be able to introduce like ways that the new account can access both of all of these different accounts but the legacy accounts once something is in a translation table they cannot

and they made a transaction before that and created an account that way once it is in the translation table they won't be able to ever access it and that's why also this translation table introduces like another surface for the the collisions because one may be able to create a collision in the translation table um even for an another existing address uh a legacy address and and in that way they would um make legacy contracts interact with like a given address uh with contract x why um the the new namespace would interact with a different contract

looking at the same address right so basically instead of only having to worry about collisions with between two legacy addresses now we also have collisions between a legacy address and h translation map entry and the collisions between two translational entries so these are kind of like now three different types of collisions instead of one and um it's at least somewhat tricky i think to to get get all that right in order to make it as as kind of unexploitable as possible ideally it kind of like it i mean there's as you were saying there's just no way around it that at the end of the day this is like only 80 bit collision resistance we can make some of the hashing kind of like be a bit more kind of make it a bit

harder something but like this won't be resistant forever like at some point within the next decade or so or maybe whatever like it will be feasible to at least that's my understanding to cause kind of collisions somewhere so it's currently feasible to cause collisions it's just extremely expensive um i i really think i've told my head but it's going to be like several months of bitcoin mining versus the worth computation just to generate one collision but it is technically feasible today if you have like almost state actor level of money

right okay and then also like today well as soon as we have the cfp it only affects kind of contractual contracts and so yeah if you have a couple hundred million dollars to spend you can do it today um this this number like as we were discussing this this number could go up for the translation map if we kind of design it in a way that cryptographers are happy that it at least makes it somewhat harder but i think at the end of the day it's like we i think there's only so much you can do it's only 80 bit like this and there's no way around it at least in my understanding um so while we can make it more expensive is it like a one-time protection that will just continue to drop in price over time and so um if we want this to be kind of future compatible for

a long time uh i don't think we can like completely prevent that just just as we like we will continue to have legacy addresses and those will continue to be more like susceptible to collisions so like if you continue to use counterfactual addresses in the legacy space at some point you'll be easily attackable and if you continue to interact with the kind of legacy world at some point you'll be easily attackable with kind of collisions here as well and the question is just what's the scope like if we can make can we make it for example that it's also only like a problem for kind of actual uh kind of contracts is it only like a problem for legacy contracts is it a problem for all new contracts that interact with legacy

contracts like basically just trying to really understand the exact threat model here i think is also important it seems that the best we can do is to at least ensure that the the i guess the attack surface described in in this other um eip uh we avoid that attack surface uh with the translation map and whether it's like with double hashing where you know whatever other means it seems that at least avoiding that problem is possible but if any other technique would come around to to create a collision or just you know the sheer

competition power increase or storage uh increase you know where the next years i i guess you cannot really make any any fight against that today so the best i guess what we can do is just make sure that the problem described in the ip cannot be replicated here so while we could double hash triple hash quadruple hash keep in mind that increase will increase the gas cost of putting things into and verifying things in this translation map um so it's not a free trade like it's not just like we can just hash it 72 times like we can't just do that like if we want this to actually be usable um i'm pretty hesitant to double the gas

cost of this getting things into the translation map um i mean it's important to know right like two hashing isn't the double cost because most of the cost of adding something digitization table would just be like adding a storage entry um so the like that kind of like vastly outnumbers the cost of the hash do we do this hashtag anywhere else like or do we do we have to do that conversion any other time other than when we're adding to the translation map table no you just need to do once in order to insert it but that insertion can be triggered by different top codes or transactions but once since it's inserted it's it's there and you don't

need to do it again wait but don't like you have to do the conversion every time like say i'm i i inside of a new contract but when i'm already in the translation table and now i call into a legacy contract like because the mapping is only the other way around i feel like my address will probably still be manually converted again so every time i call into a legacy contract yeah my address will be converted yeah but once if you call in from a uh like a long address into a legacy contract then the translation table is populated by that entry what is it nobody or is every time you start with a long and you

want to even if you're already in the translation map if you start with a long you need to find the short which means you've got to do the derivation again and then you look up and see oh where are you in the transaction apps you pay for the nest load and you pay for the cost of actually doing conversion but like two hashes is is really just like 12 gas so it's it's insignificant compared to full gas or okay yeah it's a single word what we need to do no it's not no it's it's pretty low yes i i i feel like there can be i mean that's the point of where we would have to also kind of like talk to cryptographers just to make sure like how what's the minimum effort we

would have to do to make it more resistant and if it's really like one additional hash i think that shouldn't be an issue if there are other things that would be required and it makes it more expensive then at some point this this could be a trade-off that's just not worth it um yeah the problem is that like all of these sorts of techniques you're effectively doubling the cost of using the translation map to double the cost of like attacking the translation map which like ultimately doesn't like achieve that much because you want to use cryptographic techniques where the cost of use is really low but attacks are really expensive so i'm not going to be massively gaining anything here that was my question in the beginning because my understanding

in the beginning was that there's a linear relationship between increasing the cost increasing like first of all attackers and and for ourselves and like but the way i understood alex was that with like a double hash it would completely make this this specific implementation of a birthday attack impossible and that would be different thing right and so i i don't know how that would be like why or but i i just don't have the answer doesn't it just get us from 81 bits effectively in terms of cost yeah that would be my understanding and then it seems like it's just not worth it because you you only have a linear kind of level here but if it if it gets us like if it completely removes this 88-bit type vector at all then of course it would be worth it i i i i'm just not like my naive

understanding would have been that like birthday takes always half the kind of the like bit not half like this look like logarithmically half basically so it's like could get us from 160 to 80 basically um but if of course that's not the case and this 80 thing is just like a specific result of the way we do it today and we can trivially change it and this complete kind of approach doesn't work anymore then i'm on board so it is just that the um birthday attack um square roots the cost of doing the attack or equivalently halves the number of bits of security you have against a collision attack um just to put this in like perspective

so we know what numbers we're talking about um the entire bitcoin blockchain in like its history of like difficulty has performed um 2 to the 90 um shah hashes in order to do the proof of work and this attack requires two to the 80 shah hashes so you do need a lot of money right like that yeah no no that makes sense and so i mean i feel like probably makes mix institute from all this like quickly move on from here but basically the point is like it's kind of an open question

is there an easy way to make to make kind of like collision like finding collisions much more much harder uh if if this and it's supposed to do then like all the better but like if it isn't and then we just basically have to deal with the fact that this table won't be like is in practice collision resistance today because we don't have kind of state level actors who spent years trying to cause one collision on ethereum but might like 10 years from now be feasible for a very motivated and only moderately resourceful attacker i'm very uneducated on the cryptography side of things

but my gut says that we should move forward with the counted uh address extension and with the knowledge that we only have 80 bits of collision resistance for specifically for legacy contracts and we just actively encourage people to move to the new system for their own security like just get people off of legacy contracts as quickly as we can i think that's our best bet so i also would say we should focus on trying to kind of like decrease the amount of damage you can do with the collision because that's like i feel like there's a lot that can be done just design it in a way where like similar to how today you can only exploit contractual contracts and that's kind of fine and so make it

so that in this new system also like the damage you can do to the legacy world is as as limited as possible um for can i yeah i think the thing here is that you like fundamentally can't beat um eip 3607 protections like if you are dealing with the count factual contracts like fundamentally and you're using um 160 bit addresses regardless of whether they're compressed and they like go to translation map or whatever you just you just can't win this attack can't be performed i think the design goal we have to keep in mind and make sure we achieve is that we need to not open attack

vectors um against collisions involving non-counterfactual contracts so if i have a 160 160-bit address that refers to a contract that has been deployed on ethereum um that reference must be valid eve and must point to that contract even if that contract has a collision and it could point to a different account and it's very easy to see that there could be translation map um attacks where um for example um i create a contract that has a collision um i create a legacy contract who

where there's where i also have a long address whose compressed address clashes with that legacy contract i deploy the legacy contract at some adren at the address people start interacting with the contract do stuff with it i then deploy the long address contract and the long address then creates an entry in the translation table doesn't check whether there's already a legacy account at that address sticks that in the translation table then future people trying to interrupt the contract are instead interacting with the new log address contract and i've effectively covered the legacy contract

yeah but they're they're problems here so and and those i think mostly like there's several there's some kind of like details to to get to get right so for example what about a long contract that has already been deployed but is not yet in the translation table because it hasn't yet interacted with the legacy world and then tooling for users might kind of somewhat carelessly already allow them to to send funds or something to the compressed address tokens or something because they assume that it will be converted sooner or later or something so so this would be like just a kind of like a nuance that we have to be careful about but then the more important point i think here is that this is really hard to get right once we introduce state expiry right because if a address that collides with the

compressed address has it already expired we don't know that it existed so then all of a sudden uh either we have to be fine with collisions where one of the party of the collision is just expired where we say yeah like if you don't want to be target of collision and you live in the short address space then you just have to make sure you always kind of keep in the active trees like you have to just use your account once a year like otherwise you could be like no no don't do your own account but like because if your own account like that could be the type of birthday attack but like if you use like an another if you basically have funds with a legacy address or something of some sort then you just have to make sure you use that once a year because otherwise

it could have been set up as a collision thingy and then once it expires they can create that collision and they can't be a check because it expired it's not part of the active state the other alternative would be to like require an exclusion witness every time you add something to the table but of course that's just not feasible because then yeah i mean self-evidently not feasible the does this problem go away if we just disallow creation of legacy accounts once this launches i don't think that's that's related at all well we're talking about these attack fighters we're talking about is someone creating a legacy contract that collides with something in the translation map right

right but you can do that with an existing deployer contract like if you already have a deploy contract on the chain today we can't break that contract and so we would have to continue to do to allow deploying new neutral countries but there are also multiple parts to this collision i mean we well the bigger risk is um creating collision for i guess based between a legacy address and a compressed address but uh we also have this other part where you could um try to grind two long addresses which result in the same compressed hash or compressed address right

can we just disallow that but the question is what does it mean disallowing that yeah so basically what you would have to do is like every time you try to add something to a translation table but it already is in there with a different entry you basically you would have to um you you'd have to completely throw which which could be fine i think i think that's the best way to go like the chance of someone running into this on accident is basically zero if i understand correctly the only time you'll run into this collision is if you're actually actively an active attacker i'm totally fine with just hard throwing on you and just being like nope whatever you're trying to do you cannot do it i don't care what it was right but you just mean specifically the trend

the translation map and not in general because in general you cannot disallow addresses this is right yes only this would be just specifically for as soon as you try to get added to the translation map if there's something already in that spot like so there's already a short address a compressed address sorry in the spot you're trying to add to we just hard fail on you like it just doesn't work but also that comes that comes with problem of its own right i can i can find a collision between two potential contracts that i can then deploy on like long long contracts and then um the first one is basically some honeypot or whatever that that has some functional some payout functionality that

runs through the legacy uni swap right so if you want to withdraw your funds it calls into the legacy uni swap and then it converts whatever and then it sends it out to you and that's the only way to get your funds out but otherwise it doesn't touch the legacy world and so it is it's not yet in the translation table and then you deposit funds because you audited the code and it looks looks nice and then before it ever touches legacy world it gets added to the transaction table i then deploy the other one that has the same compressed address interact with the legacy world get added to the table and then whenever you then later on want to actually do the withdrawal and for the first time ever touch the legacy world now the the the the withdrawal always throws because it can't get into the translation map

anymore which is of course you can prevent that by making sure you only deposit once you once it's added to the sensation map or you could even have it like access list thing where you can just already add it to the translation map before you need it just to make sure it's in there these kind of things but it's really hard to get that right of course from a ux perspective right that your tooling always ensures that happens it's it's like we don't want to only find a solution that works in theory like it has to also work in practice and i'm i'm a little bit worried that this is really hard to get to to consistently get right in practice yeah i'm back i'm then back to um just tell people to get off of legacy contracts as fast as possible

yeah i mean that's right i think that's that would be the the main goal to have incentives right so that people move on to the new space it's just for two reasons one to just keep this translation small and also i mean that's the way people are going to have more collision resistance and and that's the only way they could have something like epochs so it's really just a matter of uh how can we incentivize people to move and you will lose all of your money if you don't move

yeah i think it's it's kind of hard to to incentivize them though because um the i guess the main benefit of d5 is the composability which is really biting us back in this case um because you cannot really easily move like the the lower building blocks over unless the the upper you know anything building on those uh have the capability to work within i mean the new space right we see the level of stuff upgrading all the time like uniswap has done two upgrades already and they're basically a little level yeah every contract uses swaps like they

on every but lots of other d5 things refer to uniswab directly tie ended in a swap like hook and dina swap call you in a swab like that's a very common pattern yeah i mean it's just for basically the upgrade but yeah but i mean more like all the tokens and all the the different pools um you know there are a lot of interdependencies there yeah i mean i i agree i mean it's not trivial but like over the course of a year or two if we tell people hey you know this isn't enough security we need to you need to get off of this start working on that i think the dfi ecosystem will figure it out like the the low level stuff but do you think the security

just you know using security as a reason uh when when then somebody can argue that it takes um maybe like eight years of uh computing power spend on bitcoin to do this which which may make sense you know if if enough money is locked up but do you think the like the security aspect like we it doesn't have to be quick with it to happen quickly like the whole point of this is that 10 years from now maybe it will be kind of like feasible for non-state actors to do this kind of attack so within the next 10 years everything should have migrated over hopefully but i'm really optimistic about that i'm

not so optimistic about one year like the moment address attention goes live it'll not like not all projects will be migrated over within a week and not all projects will migrate over within year and probably not even all of them within two or three years but the point is we have this nice that's why i like our solution has to be really kind of seamless to kind of like like forward compatible right where basically you can start migrating over some things and point them to the legacy world and they just continue to work because if it's really like a big problem from the get-go to interact with the legacy world that's just a non-starter because then everything will continue to live in the legacy world for compatibility but if it's really seamless to just deploy your new uni swap b4 in the new world and then

like the upgraded i don't know usdc token is is in the new world and then they uploaded next token and like over time all of it just more and more of it moves over to the to the new world and so um the nice thing is that with state experience kind of like we have a gradual ramp up of incentive to move right because the legacy contracts will become more more and more expensive to use at least if they occasionally right you really misunderstood what i said because uh i mean if this interaction between the two different sides of the i guess the accounts if that is not seamless then it's just not going to happen it has to be seamless uh otherwise yeah

but i think my main question is do you think just saying that oh because of security you have to you should migrate you think that's enough i don't think that's enough but then on what on what timeline it's not enough within a year but like even like a three-year timeline i don't think it's enough and my question is you know whether um what is more incentive um okay i mean state state expiry is a different question and when does that happen and when it does happen i mean that definitely puts a bigger incentive on it um but before that i wonder which is a bigger incentive to um get penalized in terms of gas if you

stay in the legacy space or or rather get like gas benefits if you if you go to the new side i don't i don't think we should be like opinionated on that at all like the ethereum kind of pricing should always just kind of correspond to whatever well they're big shows as prices for all of these features so i think that's anything opinionated yeah i think what alex is getting out quick and wrong here is that if we require the translation to be like 72 hashes or whatever it means that this will be expensive but more secure and so that would incentivize people to leave because hey i can get no the opposite actually if it's more expensive then it means it's more

expensive to have new contracts that interact with the legacy world so what people will do is they will continue to deploy like exclusively in the legacy world because that's where all the things they want to attack with live for now and so we have to make it the other at the other end like really really cheap so that like people the point is i think it will it's obvious that no one will continue to deploy things in the legacy book unless we add unfortunate incentives otherwise so like in the default case all the new things will be deployed right all the utility versions will be compiled well first of all people don't use recent solid versions they're always like through two three major uh releases behind

and auditors and auditors like strongly suggest to use something like zero five at the most um because they claim that newer versions are more buggy um so yes but there's really auditors that are recommending 0.5 yeah oh my god there's so many security enhancements in like the newer releases like checked math for example yeah nobody recommends zero eight that's just that's just too much it takes like two years um to to right so maybe next year but maybe like zero six yeah and then that seems fine so so far i feel like with the just

coming back to state expert for a second here i think it's important to note like we will only go ahead with the expedited address space extension once we have like the full state xp kind of based on it in place like there's no need to rush address space extension unless we need it for state experts so the moment ago space extension would hit mainnet i would feel very confident that the old state like the the american patricia tree would expire with it within a year from that point so within a year from the address space extension we would start having actual incentives pricing wise for people to migrate um at the same time i feel like with a lot of these concerns around like collision resistance

um we only have to make sure people might migrate on a 10-year timeline because that is kind of like where concerns become realistic we don't really like it it doesn't matter that much that it happens within a year or two that's just not um that's just not the type model here i think you're talking about entirely different things um so since there is no way to reject legacy addresses from being created um at least any any well we haven't discussed that but there doesn't seem to be an easy way to to reject legacy addresses to be created maybe after the expiry of this but but right now it isn't

and because if we did the pre the contract prefix thing am i incorrect but alex's other vip i don't figure what it's called yeah but the the problem with the you know there are the ton of like balances which exists as uh only in tokens and not in the state yeah counterfactual contracts basically that happened i mean i'm not just controversial just people having a token but no conflictual eoase basically so sorry i was saying like can't we

prevent people from deploying contracts that are at legacy addresses starting at some point i thought that was a thing we could do yeah but that's like compatibility like that that actively kind of like breaks things so we don't want to do it maybe just take a step back so assuming we cannot prevent you know for the next two years let's just assume you know before state expiry we cannot prevent new legacy addresses from being created and then we already also introduced this new long address address space and if you want to interact with me like

a long address and legacy address you need the translation map right um but you still have the ability to keep creating legacy addresses what is the incentive for people to start using the new name space and not just keep using the legacy space if they keep using the legacy space now if they keep using the legacy space they never go to a translation table so they don't really have any pricing difference or anything well no but like that that's exactly where state experience comes in slightly like it will be as soon as we are one year from the state from the space extension point and i think that's only fair also because it gives people some time to kind of start yes to start migrating or whatever but once once we at that point all new new creations um on the legacy side

will have to come with witnesses and i think witnesses will just be really expensive especially in the beginning um so that that's a strong incentive to no longer like there won't be an incentive within for the first year basically well there's already an incentive because if you deploy in the legacy space it'll expire as soon as we reach period two whereas if you deploy when we end up like the so just for terminology here so the moment kind of like address space extension would go live that would be part of this hard fork where we also moved to period one and so if you continue to deploy in the legacy space you continue to deploy a period zero addresses because in the legacy space there is no period one address but if you deploy on the period one side

you deploy period one addresses period one contracts that you would apply will have free access to storage not free but like witness free access to storage guaranteed for two years or like for basically for for one year plus whereas the uh on the legacy side it's one year less basically like the the contract that you deploy on the on the long side will be future proof for one more year for like witness free storage access and i think that's a huge incentive it's only it's only one win this year though isn't it so no no no no no it's one witness per storage slot per year but i specifically said if you don't have

state expiry and before state expiring right and there's just zero incentive before right but that's why i'm saying we should just not we we won't do address space extent at least not this kind of expedited version of it if we don't do state statics very together with it this proposal will not hit mainnet within the next three years so what do you mean by exploited well like the the point was that people were like saying we kind of have to do just add a space extension because of hash collision issues and so that is a medium turn concern so we have to do it within next five years and it is also really helpful for state

experience and said experience we ideally want to do next year so if we want to do state experience with aerospace extension aerospace attention will have to get mainnet kind of basically next year i mean end of next year early kind of 2023 would also be okay but yeah this kind of timeline so we will only end up doing address space attention on this kind of very quick timeline of like one year one and a half years if we actually have state experience and we are going to going ahead with state expert there's just no we there's no world in which we go through all the castle with state addresses attention anytime soon just to protect counterfactual contracts from the collision collisions it's just not a thing to begin did the only

reason that i care about address space extension is for the state experience like the collision thing is an interesting like theoretical problem and i i agree that eventually it will be a real problem and we should solve it but state xp3 is definitely my number one driver for why i care about this at all well is there anyone who yeah who is in before the the collision question what was that is there anyone who is in um who who is interested in address-based extension because of the collision issue at least on this call i don't think so everybody is motivated by the state expiry

dependency i kind of suspect that is by far the dominant uh concern within but also there's a bit of a selection effect here because uh the invites could went out to this statelessness call group and so that there's by nature people are interested in that experiences there could be the cryptography out there that just is the way of the state of this effort and so on i think it's also the fact that state is a real problem for ethereum today like this is a theoretical problem for five years from now but we have a serious state problem today that we need to solve as soon as possible and so that's just it's very motivating like today's like deal with tomorrow's problems tomorrow

deal with today's problem right um that's why i'm like i still think that it's a good thing like also like i like the way your team kind of did this proposal to keep the proposal separate from state x3 because i agree that um it's always better to develop develop these things as modules as possible but for for the purpose of thinking through the implications i think it makes sense to to do that in a tightly coupled way together with state x3 because that's just like the reality of it so like develop develop it independently but for for like thinking through the implications and the incentives and behavior of people in office i think it makes sense to do that in a context that

assumes state experience well we definitely hope to explore and specify this independently because there's just so many changes otherwise and even this seemingly small part has so many i guess questions or new properties to discuss um but yeah i mean the incentive structure is is basically non-existent unless you bring in uh state expiry right but i think that's fine then even then to be argue against myself

sort of um i don't actually think the incentives for state expert are that strong one storage plot slot witness per year is well sword witnesses might be a little bit spendy um supposedly with vertical trees they get relatively cheap and i'm not convinced that's going to be enough for people to care like like i don't think that is actually a strong incentive i don't think that matters because i think that we can just like our job is to solve problems for ethereum and think about ethereum's long-term health and you know we can do only so much to protect users but we need to solve stateless and in order to solve stateless we need to address a space extension in order to solve the collision problem

we need address space extension so we have to implement address space extension we don't need an address base extension to solve you know statelessness though i mean it's just ac i don't know if you saw the post site i mean there's definitely a way that you can have metadata in the state try or have a separate try that's not expired these are like definitely alternatives uh we should have a call about that separately um i'm not super convinced that those are actually pragmatically viable compared to the current situation like we have to decide between address space extension problems and those

problems i feel like the addresses based extension problems are simpler in the chat because matt and i had like oh man i like the write-up on that please like three days ago and i commented on that a little bit and um i tend to agree that like i definitely agree that address-based extension is the cleanest way to do it the clean only from the point of view of the state experience of course inside of it there are a lot of messy problems but like from the aesthetics point of view it's the cleanest approach but i disagree that it's the only feasible approach um so there definitely others as well so it's like we don't have to kind of like do at a specific tension no matter what against all kind of resistances sure so i guess yeah let me let me rephrase i think that

unless someone can propose a solution to to be here the 80-bit collision resistance issue i don't think that not being able to solve that should stop us from moving forward with address space extension like i do not see this as a blocker yes it would be great if we could do better i have not heard anybody suggest any great alternatives like maybe talk to a cryptographer and see if we can do multiple hashing rounds or something we can investigate that um maybe that'll pan out maybe it won't but i don't think that should stop us from moving forward like with everything else like we should i don't see dropping this because of that this is not a blocker in my opinion also i don't even understand they could quite understand why it would even be an issue if no one migrates like basically the whole point is that

we do static like two things one we say we have this concern of the security and like it's up to users to to kind of decide if the security is worth the hassle of migrating or whatever and if they decide that they don't care then i mean that's up to them and also at the same time with state expertise we only want to make sure that it can continue to stay efficient and cheap to interact with ethereum and if people want to do that then they well they have to go through the hassle of migrating if they prefer to have more expensive but kind of like more expensive transactions but everything stays as it is today that's up to them that's fine as well i feel like we should be completely unopinionated we should just introduce a mechanism that starts making it feasible again to be a minor without

storing an incredible amount of state and so that's our job and then how people choose to interact with what trade-offs i i really don't care i don't want to nudge them in any direction that's that's up to them yeah i agree like we can give users the information and the tools to protect themselves and they can willfully choose to ignore them like they always do and i'm okay with that like we tell people all the time like the auditors might not we tell people all the time don't do these things some people still do them and you know bad things happen or bad things will happen that's their choice but as long as we inform them and we give them the tools to protect themselves like i feel like that's that's kind of

the limit of what our expectation should be our expectations of us should be right so i just feel like we should make address business engine the best way possible and then yeah so sorry alex so yeah i mean yeah it seems we spent the entire call on this point to be but um yeah i think it was very useful to you to explore all these different collision potential collisions which could happen at least uh i guess now everybody has a better understanding of the this this question um but yeah i think because i could say like another five

ten minutes as yesterday but um if we do that i wonder should we i don't think we can discuss anything under point three um so like the transaction access list that's that's a bigger topic but if you want to discuss um something before we hang up i think we could discuss like this uh point four a like easy recover um or i mean the ip3074 but yeah it's practically the same question um yeah i mean specifically 30 74 i think this should be less of a concern because that's still actively being developed and so whatever we kind of if if we start having a concrete

vision for a state like added space extension we sd3074 authors would make sure it'll it's forward compatible with that so so i wouldn't i wouldn't worry too much about the 3074 side of things more more about the easy recovery but to me i do yeah i do worry about the 30 74 because you know if 3074 goes in um like maybe late this year and it makes no preparation to to be compatible with other space extension then maybe we run into a case where it may be just um maybe too hard or like maybe there may be just really bad ways

to to make it compatible or maybe we will need to introduce yet another yeah so then like when we rephrase that what i'm saying is not like yeah so basically i think it's important to raise this and i don't think we have really thought about it much yet as like with the erp but so basically what i'm taking away from this is like a task for us make sure that it's forward compatible with other space extension and don't move ahead with the ap before we are sure of that and then we will do that we will ensure that i mean for one of course 3074 is very far from insured to reach minute anyway but like we will make sure it won't reach mainnet in a potentially not forward compatible form to address space extension so like point taken basically and it's it's not like

that that that price extra effort we haven't yet put that in but uh we will make sure that i mean i want to i want to bring added space attention to my name as soon as possible i i will not like on my watch there won't be an erp that adds complications to that so um yeah my call wasn't wasn't just to to to to make the point for you guys to work on it uh i think it would be a useful and interesting discussion to be had you know under these calls um 3074 is just still not like they're still kind of it's still changing form kind of over time as people can fit feedback and so i feel like

that it's not yet part of mainnet yeah but the main point of it is i mean that's why the order is like this that we have ec recovered and then 3074. because 3074 basically does it is the easy recovery itself right so whatever right um if we explore this topic under ec recovered and we have a better understanding and maybe that understanding can be applied to 3074. right and and also it's important to know that like there were versions of 3074 that included giving the odd up call the address that is expected as the signer so like basically explicitly just basically instead of only returning it from the opcode just

already passing it in and then throwing if the signature does not match that and that version would be compatible because you could just give it a period aware address and then it only checks the hash bit of it and so but but then it knows which one to actually set the authorization for depending on that and so so there's a few different ways to make it work um but yeah on the maybe of course to to to start with ac recover a bit because like also there's like for for before we talk even about easy recover just like i think we talked about the variable last time the transaction format where legacy transaction formats basically would have to what they would have to do is just assume period zero basically or like the even even the the legacy accounts and just

send from there but for new for like a new transaction type um you would basically what you'd have to do is you'd also have to specify the period right so you you'd basically um give it the signature and the period and then it would be recovered as a signature from that period i assume you'd also have to sign over the period i'm not sure um yeah it seems like you'd have to also that that that would have to be one of the fields that's signed um yeah but it's again a very like state expiry specific view of it why is that the case because you only have periods in state expired right but if we want to like if we

already block three bytes or four whites image over i think three right in the in the long addresses for a period number even if it's set to zero first then we should have a transaction type that is forward compatible with earth time at which this is not set to zero at all times so i'm just saying yeah i mean in our respect we don't block it for period it just reserved four bytes right because the proposal is decoupled um but can we just talk about easy recover um yes please we're going to say what a transaction guys what what what is the problem with this first one why can't we just do this like why doesn't this just work

which work so anyway the the the main problem with dc recover is the first bullet point you mean the first question there uh yeah sorry the first question like why can't we just do that just uh have the precompile return along to new things and short told i don't think these are kind of like you know we can or we cannot do them i think we can do all of these but the question is which is like a more pragmatic approach and so the first the first one sounds the best to me just got wise is there some reason that i'm missing that makes the others sound compelling at all yes well if you do have state expiry

with epochs then then you would need to account for that anyway exactly so that's why i feel like the so so i mean again i understand why you want to keep them separate in design but at least to to make it forward compatible in some point in the future there might be more than two addresses not not right now basically a signature with address space attention would instead of one could resolve to two addresses but in the future it could be instead of two it could be three four five six seven whatever so we want to have a solution that is just that this compatible in the world where it's n instead of two and so um to me that seems to indicate that we just need a new ec recovery anyway that takes in some extra input and like for me in my

aesthetics mindset that would be the period number to resolve the address for but that could be whatever extra information if we end up also with a area type two and other step three or whatever um there could be other information as well but like for now in my mind that is the period number so why not how does that work why not just require the why yeah why keep it as a easy recovery as opposed to a check whether the signature corresponds to a given address so you basically mean you you give the up code a address and it only returns true false yeah well the problem is that would

i mean i think that kind of makes sense from like a ease of use and security perspective but the problem is that right now you can be very efficiently just only passing a signature into a contract and it does all the things that has to do with that and then in the future you would always have to also externally pass in the address and so that's just like 32 more bytes of call data you always have to pass along in addition to the signature if we okay with that tradeoff i think it's a practical choice so my only concern with the epoch is that i mean that isn't like fully future compatible either because the address format the new address format is not like based around epochs it's based around the diversion byte

and different versions may introduce like entirely different formats which we may not foresee right right the nice thing is we'll have to include at least the those reserved bytes so the four bytes instead of all 32 though you can just pass in the four and it's no wait i wonder what those are just well the four work with version one right exactly that's what i'm saying i feel like what you should do is you should just pass in basically a version number plus whatever payload that version needs and that for for a version two over h3 that could even be the full address that it expects to return or something and then it only does a check but it should like i feel like an op opcode that's perfectly future compatible

if it doesn't take in the full address and that only only does it check what it should do is it should take in a version number plus plus payload and then for version one the payload should would be period number um of course well at least initially that would basically be hardcoded to zero um because that like other periods just don't exist but like once we do static spring it'll be the period number is am i understanding correctly alex that the um first byte determines all of the subsequent bytes it just so happens that version one um only has the first four reserved yeah but like you could have version 10 that

the bytes don't mean signature at all yeah yeah but there's also like an entirely different option instead of easy recovery returning an address it could just return a public key and then you can generate whatever format you want out of it so how do they how does this work at all with legacy contracts like there are legacy contracts that call the current ec recover with the current um parameters and they need to continue to continue to work and so if you have have signature um i guess we just map it to the compressed address always is that correct the problem is that doesn't work because

you don't like from a signature you you can't see if it came from a long account because there's no such thing as a signature from account it's just a signature from a private key and the private key has corresponding legacy accounts and corresponding long accounts so you could just can't there's no way to resolve a resolve a single signature of the old format to one of your multiple accounts so you can't all what easy recovery does it just returns a public key and we decided that we format that public key to be an address right but the problem is it doesn't like you

you can do that with a new op code you can do that with the new op code basically you change the behavior but like easy recover for existing contact at least would have to return continue to return this 20 byte like shortened version of the of the public key right you can't make the behavior of this thing you see your cover at least when called from the right i'm not not suggesting to to change the current one or for legacy context anyway but i think we're talking about two different things here are we like we focus on one or the other either easy recover and how that works with legacy contracts or ec recover and how that works with new contracts i think those are two totally separate questions which one do we want to talk about for

legacy ones the the current pre-compile address um well you definitely cannot change what it returns but the second question is whether you can change uh whether you can extend the input to influence what it returns and legacy contracts because they're already deployed but legacy accounts are real continue b to be deployable right so you can deploy you byte code uh sure what i'm saying like there are many contracts out there that use the pc recover today and they have code already deployed domain net and those need to not break right what you could do is you mean

add optional longer call data that you send to it that just exists whether you can extend the input or not and i haven't extended the input yeah we definitely cannot extend the input because there are contracts that exist you cannot change those contracts they are immutable no but extended there now to clarify extending the input doesn't mean that now you require more bytes always it just requires that you may accept more bytes and treat those more bytes somehow sure right sure but we have it still has the whole system still has to work when a new account is using a legacy contract that does not pass additional bytes through to user recover so like everything needs to work with like

it does that's not true like if an epoch 10 account might just not be able to use legacy contract functionality that requires signatures okay so it's right there that goes against one of the precepts or the assertions we said earlier which is things need to transition smoothly people need to be able to create new accounts and they should still work with legacy contracts like this is a pretty big deal to say new accounts will not work with legacy contracts that accept signatures because there's a lot of okay then let's talk about this because i don't think we have a way of fixing this sorry just sir peter go ahead so like can i point out that if you look like on the really broad spectrum

of like what's actually planned for ethereum um i think like um ec recover that returns an address is just going to get more and more conceptually broken because to start with you can only easily recover if the address you want to easy recover to is an ela if the thing that you might want to easily recover to as a contract there's no you can never like produce the private key that ec recovers that contract as i understand it the long-term plan is simply that that we're going to get rid of eoas entirely and everything is going to be a smart contract and we're going to have this whole account abstraction system and at that point like ec recover will

become in a world where eoas don't exist ec recover is like completely useless so i'm like a lot of people are getting confused about well the fact that changing how addresses work is gonna break easy recover but i'm like are we sure that easy recovery isn't in the long term going to get broken and if so does it matter that ec recover doesn't work with long addresses so i think you have a point um but at the same time though i think you understand underestimate how willing people are to kind of have hacky backward compatibility solutions so even if we were to move completely away from uas tomorrow and replace them to unchain implement implementations of contracts that do the same thing basically

we would have a hacky kind of like patch for ec recover that would what it would do is it would just kind of like recover the private key and then convert that into an address and then just continue to send that like maybe call into that address to see if the implementation changed so it doesn't want to accept uh like that type of private key anymore or something but still return that so so so even in a world where these are smart contracts they would there would be this special backward compatible ec recover while we would move to a new form that would be more active where you actually send the address and then it calls the address and lets it do some signature check or whatever so i think in the long term we'll definitely have to move to an

upgrade anyway that takes in the desired address and so that that actually now talking about that that makes me more more kind of open to the to alex's proposal of like a new ec recover that actually takes in the address that it expects instead of only some kind of hints of that address so actually i think that makes more sense now not thinking about it that's more forward compatible with the kind obstruction but the existing ec recover the the more we can keep that not broken the better and as michael was just saying like it's actually that that was one aspect that i just wasn't aware of it is really hard like you'd have to do some really weird address like um basically access list trickery in order to make easy recover compatible with

this new world of multiple accounts on-chain accounts with the same private key um or same public key even right so um this is actually so it's independent i feel like there is that we have to talk about how to design easier recovery too and then now i think i'm not born with alex of like taking in the expected address i think that's a really good idea and but the other one is how can we make easy recover be maximally useful continued for legacy contracts and then i think it's like a really hard challenge how can we make it work with long address uas so i feel like that's what we should focus here so i just before we before we go too far away from

that i do want to clarify something with peter um i don't is the plan that with the transition to everybody's a contract does does that actually mean that ewa is or sorry there is not a private key that maps to the address that is your contract like i think there are some proposals for account attraction where your code for your account would live at the same address as your eoa recovers to so you could assign things from a contract account no no no well some somewhat so but basically by default existing kind of like ua style contracts we would also of course set the if

you're an object format maybe or something like that so so you instead of having one code you basically have like a signature verification code and a kind of like with these kind of bits right and then like basically the signature verification code by default would indeed continue to do the the check against the private key that maps to the public like that has the corresponding public key that maps to the address but you could override that right so you can upgrade your ua to no longer returned like basically no longer validates it just that way and so you could end up with like an ua that was upgraded and so it now no longer is able to sign things from that private key now maybe it does some other things and some

multi-sig or whatever so by default yes but not forever i think and this is just to counter peter's point i think that that means that the vast majority of people will switch means contracts will be created that allow for signatures that they want to recover but even account abstraction contracts they may like to use ec recover to do the internal verification and easy recovery is not can not only be used with actual accounts it can be used with any kind of signatures and i'm sure that there is someone who

is using it in such a way in fact i used it in such a way like in 2015. uh it certainly is possible and 0x both do that don't they i don't actually care if you have an account they just need to make sure your signatures are valid yeah um and just going back to the very beginning i'm not sure how we really drifted away into all of these different directions but uh i think one one thing mike you said and i tried to present one position on that okay maybe let's just clarify that easy recover for legacy account it it still has to be able to to function

the same way it does today but there's one question can we extend the current ec recover pre-compile in so that it accepts more bytes as an input and if it does accept more bytes as an input uh can can it safely interpret any bytes after currently it takes i think like four words as an input so can we say that any other data after those four words could be you know like new flags or any kind of configuration to have a different behavior and i checked a i haven't checked every single client

um but there doesn't seem to be a validation uh on the input so it it seems that they they can accept longer inputs today um i think yeah but i think we only have specific rules on on some of the the newer like beyond one two eight or the proposed bls pre-compiles uh to have uh an error condition if there's more data than expected but we don't have that for easy recovery um but i i don't think this helps here at all because whatever added benefits you get from that you also get

from like an easy recover to opcode instead because it's only useful for new contracts that are aware of those existing contracts they will continue to send the short input to it and so they'll like it doesn't help them that now easyrecover can do more things because they can't use them and so and new contracts if they use this extended easy recovery or if they use an ec recover too instead that's kind of like it doesn't matter for them and so i still had a few words to say is that so we don't have a condition which rejects uh any input which is longer um which means i don't think we can actually extend it because

currently there may be contracts which send more data out of any kind of bad programming reason and if he would accept or treat those bytes after 128 in a different way that may be breaking um but to reflect to what you're saying that they they cannot uh the the other i guess long-term discussion regarding pre-comprises people are just afraid or annoyed or just don't like ending new pre-compiles and that's the only reason why uh why anybody could consider extending the existing dc recovery as opposed to

introducing a new one i suspect you'll get more pushback from the core devs on changing the behavior of ec recover than you will from adding a new precompile i think that was alex points basically like because people will be reluctant for easy recover two looking into 10 weeks that easy recover right now it looks like this might not be possible because if there was no validation then there could be could be kind of incompatible existing behavior okay i understand that but but i feel like we all agree basically like to try and let's find because we're getting close today and probably like trying trying to kind of summarize that specific point we all agree that in the future world basically there would have to be an easy recover like pre-compile

be that easy recover itself or another new one that takes in more extended information be that the period number be that the expected address whatever kind of like that's cbd and then does its thing basically um so so like the and the exact details like extending the existing one doing new one like yeah that's basically that that would have to be worked out at the same time my vote is easier too and if someone pushes back on that we can fight him a little bit and if they really push back hard we can fall back to chain updating ec recover one so i guess now we can come back to the

the first first question on there which mikey you said can i why cannot we just do that first question was should the pre-compile just behave differently based on what is the the caller address for data yeah i'm convinced on that we don't like that's none i'm convinced we shouldn't do that great yeah i just wanted to go through these like different options um to clear us to us seems anyway to have a new pre-compile which which has clear and new rules i just really wanted to to validate that um yeah i wonder if one on you know on subsequent calls we can

be maybe a bit more focused on any of these questions because i think we just really started to really discuss like 15 different aspects of this and not you know getting going like point by point it took maybe longer to arrive at the end i think i i suspect the the problem might be that will help in future cause if we resolve is making sure we're on the same page for what our goals of these calls are um my personal goal which maybe doesn't align with you guys is to become convinced that address space extension is something we can do reasonably like we can actually get this on chain and right now

my biggest blocker is what i just realized with ec recover that new addresses will not work with any is the existing contracts that do easier cover like that's about all the things on here everything else i'm kind of convinced yeah there's solutions like these are solvable problems um that one feels like it might block this whole project to me that you always get i don't know if you guys have similar goals or not with these calls so what you're saying is that with keeping ec recovery intact uh you will always get back a legacy address um even if somehow through some ux errors somebody signed

uh like a a message or it doesn't need to be a transaction but you know some kind of a message uh and sent to a legacy address but they used like a new long address to do that right i don't i don't think it's it's like another ux issue the issue is is that someone uses a contract where the ecu recovery is used sometimes and sometimes like message.sender is used and if those two things don't map to the same thing then you have a problem because the user you know deposited some money with from message sender and then they try to get the money out using ac recover and they recover a different address because the one they deposited with was

a compressed um long address that's from new epic and the one they recovered recovers the legacy one and they don't match so you don't get the same address and therefore their funds are stuck right i do i agree with that assessment so um yeah can i point out that this is already a risk if you say use a gnosis safe and send an account to some money deposit some money with say a smart contract like nosy safe into an account and then they'll later discover the way to get it out is to use ec recover

yes that's fair but i think we have the same problem in reverse as well so like you put the money in using easy recovery and you can't get it out the other way right but that's a good point so the way i described is already a problem the however if you invert it i think that is a new problem because you wouldn't be able to get the money in the first place this is safe i don't think that's so so i feel like there's two things here like i don't think we have to worry that much about stock funds the problem is it just completely makes these kind of systems incompatible with wrong addresses and so people would just not ever move to long address uas like if i want to continue to be able to interact with legacy accounts contracts and some of them like even i don't know die or

whatever right i can their functions that accept the signature and validate them and do something with it and some smart some some some defile systems you depend on that so there's no other way to interact with the system other than what via these signatures and i just completely cannot use like i'm sure they all of these systems would have protections in place they would just say sorry you're trying to integrate from long ua that just doesn't work with our system you're out of luck but that that's not so i'm not and maybe the odd one would let you through and then the funds are stuck but i don't think the big problem is the stock funds the big problem is just that that introduced we would like our design goal was make it be fully backward compatible and that's just not like quad compatible like this

is a type of today legacy kind of functionality that you cannot use and cannot interact with as soon as you have a long eoa and so this is something we have to find fix for basically and i mean that you can you can trivially find fixes right but like i'm not sure they are good enough so for example what you could do is you could have a just hit in your transaction type that adds basically hints right so like you you basically said you you had include a mapping off and it could even be signed by the key so like you'd have to include a signed mapping of like please my private my public key please map that to a long address with period number

whatever and then whenever easy recover as part of the transaction is hit with a signature like that then it uses this mapping to determine which one to return this would work but of course it looks really messy and who knows what kind of implications this has but this is the type of solution i would want to look into here because i'm in a single boat with mica i feel like maybe like kind of expectation wise for these calls like my primary expectations for now i feel like and we in the stage we are right now because it's not like we have to make address space extension work it's like we have to decide if we want to use address space extension for state expiry and otherwise address space extension will probably go back to the dormant state of let's solve this five years from now

and so my primary goal is figure out how feasible outer space extension is so if it's worth continued focus and i hope i really my my hunch is the answer is yes let's do it but i feel like basically specifying exactly how easy recovery 2 works is less important than figuring out is easy recover like an insurmountable kind of problem anyway and and so yeah that's why i feel like these kind of questions are the first ones to answer i think you really i think you were simplified that so if we wouldn't have discussed like easy recovery you know we wouldn't have arrived at at this

at least not today that this is yet another one of those ux issues agreed i i wasn't aware of this like before like 20 minutes from now i wasn't aware of this problem so like the only reason i'm aware of it now is that you kind of had this point in this document yeah so i think the points that docu i think what i'm trying i was trying to get at at least um with my goals for these meetings is that for a number of these points like you have questions on here but it's not a question of can we do it it's just a question of which solution do we choose and i don't care at the moment at this stage i don't care which solution we choose i just want to know that there is a solution and so for example for the ec recover

one whether we do a um you know ec recover two or extend easter recovery or all that doesn't matter to me like there is a solution we can move on like that's why i keep kind of pushing us away from focusing on like the minutia of like some of the specific bullet points because i feel like the bullet point already just says hey here's the answer like here's a here's a solution to the problem and then at that point like i'm ready to go i'm ready to move on i mean i get the impression that maybe not everybody here is on the same page like i think we might be that's why we're kind of running into conflict with how we progress is because i think some people um maybe want to kind of

figure out the specifics of how do we solve each of these problems specifically and that i just like i said i don't care about that right now just to reflect on easy recovery specifically uh i think the goal was exactly what we did figure out whether we can change the current one to have different behavior based on maybe the sender or the inputs and if um and if he can then what does that mean if we cannot what does that mean but the the goal wasn't to uh you know whichever we choose to to fully specify everything but just to discuss you know whether we can change it or we cannot change it and what are the implications in each of those cases

and that's what exactly what we did and i think it was really useful yeah yeah i agree actually but that's what i was trying to say just like i feel like it's unfortunate if people come away from this was like saying oh we didn't get anything done because we jumped too much in topics i think some some of that is true we jumped a little bit much but at the same time i still think it's i'm kind of at least subjective we have the feeling that we move closer and closer to the answer is this feasible at all like should we go ahead with outer space extension and um by going and i think i i still think that this document is like really like perfect like for for exactly this purpose of like triggering all these discussions yeah but i i think it's actually

productive even if it maybe doesn't look like it i don't know i i just wanted to kind of like um counter this kind of this this impression of that that we're not being proud of but yeah and yeah it just felt like in the beginning you know when we spent so much time in the collisions um but that was also useful um but to reflect on on the the transaction uh idea i think we had a similar idea either to the transactions or um maybe to some kind of a option in the translation map but um yeah i guess we should have listed the

the question whether [Music] accounts like private keys should be able to and how should they be able to i guess interact with the network with each of their personas and the persona is in whatever addresses they can resolve to i like the idea of anywhere in the system where you are so basically whoever signs a transaction or maybe signs a payload that's embedded in the transaction that signer can dictate how all the various functions like what the various functions will return so the ec recovers is an easy example

and this is what basically asgard was getting at where some whoever has the private key that's signing over this data um that's opaque to ethereum because the contracts all that knows about it but we can have that same private key sign a thing that says anywhere in this transaction if something tries to ec recover my private key or sorry somebody tries these to recover to my address and the signature lets us know what address that is i want you to explicitly return this value like and where this value is one of like your um legacy or your you know epic one or your epic two or whatever so that way we can basically give the control to the signer um and and you know it will take some ux

work but no one will get stuck funds and people can continue to use interact with new addresses with old contracts yeah probably the only uh okay breaking up that to two parts so part one i think is clear cut it should pose no issue that a transaction from an eoa it can decide which persona it wants to interact with s so like any of the the like the legacy address or whether any addresses in any given epoch um there doesn't seem to be at least right now any risk with that

but the second part is is the compressed address whether they should be able to you know use the compressed address as a persona as well and that's the one which you may need to solve some of these us ux issues i think that is some somewhat different right that basically was the question of like should they be allowed to send transactions from their compressed like like they basically look like they come from the compressed address um yeah suspicion is no but like maybe there are reasons to to allow this and but i feel like that is somewhat separate from the cc recover question though right but it's not about easy recovery just just in general

how they can it's transactions like it's not easy to in general it'd be nice if we can just blankly say you know when you sign a transaction you can specify as part of that transaction the data you sign over that this is the address that i'm going to be interacting with this transaction from like whether it's your you know your epic one epic two or your like personas was a good word for it um i would like to i know everybody's trying to get out of here so maybe in the next meeting i would like to explore more why we can't just treat their compressed address as yet another persona that they can act as like why is that problematic i think you went over it before but you don't have

to go over it again now yeah i think that that sounds like a good agenda and i have a related question to that so a few more points i want to add to the document and i was wondering should i just edit to this document so it's kind of like a living document or do we consider it like kind of locked in so that we can i think progress like living document personally keeping this as the canonical source of all the known issues and then maybe even as we as we come to consensus within our working group as to which

solution we like for some of these we can maybe also note that in this document and we'd still keep the other options and everything but like if we decide you know amongst ourselves that hey we think this is the best option it'd be nice if we added that on here yeah maybe for the maybe for decisions we can have like a separate chapter just saying it or whatever um or inline i'm not sure but just for extending it with maybe new discussion points um i guess that's fine as long as it's like just adding a new point in each of the sections and it doesn't changes anything or shuffles anything right yeah as long as kind of like it's obvious which ones were added so like if

i look over it and like it's it's not just one line completely in the middle of some paragraph that i didn't like right because then i won't see the change no i think just like yeah we can only add like new points and uh yes you shouldn't change anything else at least not now so like an app yeah only your points does attack md not have diffs it does have different it's as yeah it's it's a bit weird and then how that works oh but actually i can save a version and and then you can do a diff between the different versions that that may work um but yeah do we want to set up a time for the next call

yeah that would be my question as well um i have all core devs tomorrow at this time so i guess we can do this right before i'll go organize if you guys really like talking yeah i would i would suggest we we go with monday um because then pavel gonna be back as well and and yeah so far he missed these meetings one day is fine with me same would that be the same time then like just stick with this thought forever unless uh reasons otherwise so for me ideally maybe just uh i have another meeting but i i guess i

can i can skip it um yeah ideally one one hour later would be or maybe 30 minutes later as the starting time would be the best for me but if it's only me then then i will just shuffle that existing one around i can't be real 30 minutes later i can do um should we like maybe try and aim for like uh should we stay with like one hour because we're always running over anyway which goes to 90 minutes and then try and stick to that and not run over or something i suspect maybe maybe it's good to keep it one hour and then we run out over like 20 30 minutes but if we if we do like 90 then we're going to be in two hours and

okay yeah that sounds good so i we could shorten the medium to half an hour and then we'll the meeting will only last an hour yeah but then we don't get anything done so yeah i i if you want me to i could send out like an invite for monday for 30 minutes later than this spot that sounded like that's what people were kind of getting to i mean that would be the best for me but yeah i mean it's many more people than me on this call unless anyone has any preference it feels like why not go with yours 30 30 minutes later it's fine with me if that's better for you then i have no problem doing 30 minutes later i could even do an hour later

and beyond that it's starting to get pretty late for me so 30 minutes or an hour later than the current call is fine though yeah let's do it 20 minutes later okay sounds good and should we continue to just send i mean i i i don't mind too much sending it out to everyone it's just i'm always a little bit afraid that it might invite people but i guess that's the price to pay and there might always be one or two people who haven't been following so far who would like to join for the next session so probably best to keep going to whoever is interested i just make sure it's clear that we're not going to go back and review old things like you'll get the very very short version if you're not caught up

puja just a quick question like what's the timeline for publishing these calls will they be like available before monday so that we could just have that in the invite for like people to to go and have a listen yeah uh generally it is within 24 hours i mean like i did it like three four hours sometimes the zoom takes time to process it and once it is done i'll upload it directly okay that sounds good then then i um then we can just do that and well then i think then i'll just wait with the invite until that that's physically done and so once there's a youtube link i'll kind of like put that in the invite for people because there's like several days so so i think it's more feasible for

people maybe over the weekend to catch up the one or two people film that is relevant so then we can have the youtube link in the in the invite and i can also yeah and i can also share the youtube link in the state channel if that is helpful yeah that sounds good as well awesome so then that's probably a good kind of stopping point here or anything last anything to discuss for today not to discuss but um do you want to set like kinda an agenda for the next call and right micah proposed that we maybe discuss the a bit the transactions and whether

you can take up your compressed address as a persona i think that would be a good thing yeah so so the two things i would like to discuss are is there any problem with personas in general like can we just do that and can that maybe solve a lot of our problems um and then if not are there problems with allowing for compressed addresses as a persona as well right and then i would want to maybe extend that and like because because i still think that kind of talking about this easier covers thing in general i can specifically make sense but not like the just the backward compatibility so like is it like does it is it feasible to also allow

uh like accounts basically to control which persona uh existing signatures resolved to from legacy contracts via easy recover so like just i mean that kind of seems to also fit this persona kind of conversation so like how much control can we can we give private keys about like how the system interacts with that persona like i don't think it makes sense to just implicitly do that like if you send a transaction from a specific persona then every signature from that private key also i don't think that makes sense how about we just set the agenda um and let's just say that you know the personas and transactions um and backwards compatibility is the agenda um well and one last thing maybe if we have

time i really think we should at some point have a session on the list half a second on the translation map as well like just the the pure kind of like how is it stored does it expire how much size does it take up because i feel like that's also a big buckle that we kind of so far only barely scratched but i'm not sure if we get to it on monday just like if we have the time that's a big one that i really want to talk about well i hoped but uh because that's like the one part of it the transaction access list is like um it's quite a big topic but yeah i i think it's unlikely that we're gonna get that far the persona stuff may take quite a bit yeah that's great yeah so agenda is personas

and all the ways they can be used and then if we get done with that very quickly then we'll move on to access lists and transaction maps sounds good cool so thank you all talk to you thanks everyone bye