DappCon 2023: ERC-5564 And How We Get Stealth Addresses Adopted - Toni Wahrstätter

Transcript

yeah welcome everyone to my today's talk about privacy um my name is Tony vetta I'm with theum Foundation also with the Vienna University of economics and business mostly focusing on privacy topics um related to bitcoin and ethereum and today I want to talk a little bit about stal addresses which is a new I mean it's not very new but it's a new proposal and ERC that we want to bring to ethereum here on the slides you can see the ERC document so it's co- offered by mat Solomon and bendy Franchesco they are both with umra cache and also um with italic and today's talk will essentially cover everything we want to

do with ERC 5564 which is called stealth addresses before we start into it let me quickly Define the problem that we try to solve by using stealth addresses so on the slides what you can see is we have two entities it's Alice and poob and and what they want to do is more or less Alis has some money that she wants to transfer to Bob so far so simple so the problem there is there are a lot of people watching them because Ellis and Bob are using a public Ledger like ethereum so everyone can more or less see the interaction between them so if ellis. sends to bob. everyone can see that there is a public transaction

ongoing so Ellis cars a lot about privacy so she doesn't want to disc close the connection to Bob so what could what Alis could do is more or less just reach out to Bob and ask Bob hey Bob could you please generate a fresh address for our interaction Bob could be like yeah sure let's do so and then what they achieve is Alice just sends the funds to the new address which is address C in this picture and this allows Ellis to not create a link to Bob so Ellis just sends the funds to address C and in in the end Bob got his money but not directly to his bob. account but to address C and now at this point if they um

continue doing so at some point Bob would probably be like okay that was quite cool but wouldn't it be easier or even smoother if we can do so without requiring any private interaction because in the previous example Alice had to reach out to Bob Bob had to agree um send the new address over and then Bob could could use the new address but now we want to do the same without any prior interaction and this is exactly what stealth addresses allow um both parties to do so Alis can use stealth addresses to generate a new address for Bob um that only Bob can access that's the important thing so Alis generates a new address in the name of Bob and sends

the funds to that new address and then Bob can use his private key his normal private key that also controls for example bob. to derive a new private key which can then unlock the assets sent to the steal address for everyone else it would then look like Alice just sent the funds to some random new address that has never been um interacting with the chain before and what they get is unlinkability so they don't get untraceability but what they get is unlinkability and unlinkability means for two outgoing transactions we cannot tell that they went to the same recipient so for two outgoing transactions we cannot tell that they

went to the same recipient that's more or less the common definition of unlinkability while untraceability is a much more it's a much stronger privacy property which says for incoming transactions we cannot tell who the sender was from the set of potential senders so for incoming transactions we cannot tell who the sender was from the set of potential senders so far so good so what we get is unlinkability but no untraceability what you can he what what you can see here on this chart is on this table is different privacy Technologies compared by their properties as you can see steal

addresses comes with more or less very weak properties so with sta addresses we get unlinkability for other protocols like coin chin wallets that we know from Bitcoin um tornado cach but also privacy pool which was published very recently um in vitalic paper cach Monero they all come with um untraceability and untraceability always requires some mixing and that's the different difference to staff addresses step addresses will never require some mixing so you can you will never be commingled with funds from North Korea for example um on this slide you can more or less ignore the the last um column which is undetectability because for most most

of the times we we have detectability for example tornado cach um deposits or withdrawals are easily detectable because they there's an call to the torado cach contract they take some um they read the tornado cache contract slots and also there are events of course same applies for sta addresses so we cannot hide the stealth address transactions among all transactions but we get the property unlinkability which is for many many use cases um enough and enough privacy for users um to be used already and as you can see the complexity also is very low so stuff addresses don't require any CK Tech or or other very

sophisticated um yeah technology like Z knowledge cryptography and stuff Stu addresses only rely on public um an elliptic curve math so it's really quite simple to implement M so how does it work um let me quickly walk you through a very easy example we won't require elliptic curve math here it's actually quite quite basic so what you can see here is Alice and Bob both have a key pair which is a private key and a public key so for Bob it's lowercase b and uppercase B and for ell Ellis it's actually not a real private key it's just some randomly generated private key so the center of Ste

addresses of stealth address transactions just creates a random key pair this is important so Alice is not using her real key pair she can just generate a random eum um private key and gets the public key to that so how does it work Ellis in the first step takes the public key of Bob and then generates a shared secret together with Bob so Ellis multiplies the private key with the public key of Bob and this allows her to create a shared secet between both which she can then use to generate the stealth address from right so Ellis uses her randomly generated private key together with the public key of Bob and

generates a stealth address from it then Alis can send to that stealth address while publishing a so a was the public key derived from the randomly generated private key so LS publishes a low uppercase a in this case while sending the funds to Bob so at this point Bob received some funds to his stealth address but Bob doesn't even know that there is a stealth address that belongs to him right so what Bob must do is Bob now engages in some parsing Bob parses the whole chain and checks all stealth address transactions and then by um using his own private key Bob can find out if there was a self address transaction that belongs to Bob and if

so Bob can use his private key to to derive the new stealth address private key to then unlock the funds so Alis uses her private key together with Bob's public key to generate this shared secret which is then used to generate the stealth address and on the other side Bob can more or less do the same he uses his private key together with uppercase a which is Ellis's randomly generated public key to derve to find his St address but also to unlock his St address so far so good what do we want to use um stff addresses for of course as said you don't get this very strong privacy properties that you would get if

you use tornado cash or privacy polls coin chin wallets and so on because they always require some mixing step addresses um can be used to protect both the sender and the recipient for example if you want to donate to I don't know to WikiLeaks um you can use stuff addresses because then on chain no one can see that you just donated to W to Wiki leaks because for everyone else it would look like you just donated funds to some random address or you send funds to some random address which could um also be your um you yourself so it could also be the case that you just send funds to yourself of course there are many um daily applications like payroll checks that require some privacy um you might

not want your colleagues to know how much you earn or other people to know how much you earn therefore they can be used to private messaging so we're already um talking with farter for example how St addresses can be used to do messaging kind of I send a message to you but not directly to your address but to the STA address the same applies to multix let's say you have a multis um so I have a multis and three friends of mine are also part of that multis sick but I don't want my friends to know who the other signers are just for my own security I don't want the the other signers to have some incentives to corrupt to find out who the other

signers are and then steal my money so what I can do is I can give them signing rights to a stealth address of them that I generate without them um being able to know who the other signers of that wallet are and the same applies to private pups and stuff and as said as as it says on the slide but essentially every interaction that should remain private so what we do is we have private interactions between two parties without any mixing involved so let's talk about some challenges so St adresses come with a lot of challenges and here on the slides you see the major challenges that we currently face some of them have some very good paths how we can solve them

some not so let's go through them so stess users cannot pay for gas that's that is a very common critique which is um very valid because if I send die for example to a St address then the user has no e on that address so the problem is the user cannot do anything with that die and the user would need some way to fund that address to do something right so the user needs some if Eve on that address to do something to pay for the gas of course there are some solution account obstruction is is a great solution because account obstruction allows you to pay more or less through side channels and stuff but also ticketing system so we have recently been hacking on a on a project which was

called gas ticketing which more or less allows you to set up a private um side Channel with Builders with Searchers to pay them through a site Channel um and they will then include your transactions so um just Google for gas ticketing or something then you can find this blog post um yeah this is one solution how you can already um yeah solve that problem with user not being able to pay for the gas the next challenge that we identified is users having to manage many private keys and this is of course a big problem right because managing multiple Keys it's hard enough to manage one key or two keys not not even speaking of managing hundreds

of different keys that you might need because you need a private key for every single stat address but there's also a cool solution vial came up with it very recently which is separating the logic from the assets so what you can see here is a very naive implementation which would never work because it's um because it's yeah not secure but in a very naive implementation you would have a logic holding account and an asset holding account and what you could do is so the logic the asset holding account would point to the logic holding account and then you can provide your private key to the asset holding account the asset

holding account would forward your private key to the logical holding account the logic holding account would verify that your private key if multiplied by the elliptic curve gener by the elliptic curve generator Point matches to the priv to the publicly stored in the logic holding account and then he returns true and if the asset holding account receives a true from the logic holding account he and the asset holding account allows you to spend but as you as said this would never work of course um inputting a private key into a contract is also something that will never work this is just to show you how we can easily split logic from assets the much more sophisticated solution uses CK narx so what what you

can do with CK narx is more or less you generate a proof over the whole ethereum state so you have a proof and you prove that in the state of etherum there is a certain contract and in that contract there is a public key that I know the private key of and the whole system then looks like the follow following the user generates a proof against the whole state the state in this case just um displayed as a Merle tree then the user can provide that proof to the asset holding account and if the proof is successful the user proof that he knows the logic from the associated logic account without connecting both that's important so we don't want to create a link between the asset holding accounts

and the logic holding account because as soon as we create a link between both you can cluster a US user you can cluster user by all his addresses so in this case we don't have any Link in between those wallets right then the next challenge is recipients can destroy the sender's privacy which is a very valid point if I send um if I send to your stealth addresses twice and you to to to different stealth addresses of one entity and this entity then commingles the funds at some point then um you would know that it was me right so if for example if 10 people donate to WikiLeaks and Wikileaks then cashes out using binance then binance knows all the

donators which is of course a big problem um especially when you use a centralized exchange but as we have seen in coin wallets for example that they suffer the same problem a great ux that more or less doesn't allow you to ever com mingle funds can solve this problem of course if a user wants to do raw transactions he can still commingle the funds but using a great ux UI um we can do a lot and then of course fragmentation because of many different stealth address protocols stealth addresses can be generated through every ell more or less every elliptic curve so you can use SEC 256 K1 curve SEC 256 R1 curve and you there are even more different um possibilities how to create

Stu ches and the last problem is exactly what the ERC 5564 tries to solve essentially we try to um create a standard for stealth addresses so let's look at it as said stealth addresses are not equal to stealth addresses because there because there are many different protocols that um you can use to generate stealth addresses for example as said SE 2506 K1 and so on but there are also elliptic curve pairing based steal addresses um lce based steal address protocols that are that are already Quantum proof resistant and stuff and the problem here is the recipient if he receives a stealth address transaction the recipient must do some parsing right and

for that the recipient must know which stealth address protocol was used so I cannot I cannot just use some random um elliptic curve without telling the recipient because otherwise the recipient would have to try out every possible protocol just to give you a rough sense of how many Stealers protocols there were so this is just a yeah a shortened list um with all the stust protocols Academia came up with very recently so you can see step address protocols being based on standard elliptic curve as we as we know in love them but there are also step address protocols being based on um lce based cryptography or even um elliptic curve pairings so what ERC 5564 now tries to

do is create this common basement for stealth addresses where you as the sender you can indicate to the recipient which um St address protocol you used for example if you use St address protocol X then the recipient knows ah it was St address protocol X and I will do the paring that St address protocol X requires so going deeper into the ERC it's actually very simple so everyone who knows solidity can already see that's the whole contract by the way so the contract is very very simple the contract allows you to do two uh one thing you can execute one function which is called announce and this function will emit an event and this event is exactly the information we talked

previously um about this uppercase a that the recipient needs to find his stal address so we have a contract that does nothing else than emitting an event containing the information required by the recipient to find the stealth address there are also some other um arguments that um the contract emits in the event but they are not that important at this point right then your C55 64 also comes with its own address format because I previously I said you can use the public key um from a user to generate um stealth address stealth addresses from the problem is the power

scam cannot be outsourced so the user has to do the parsing himself and in order to allow the recipient to Outsource that parsing process for example to let some centralized party do the paring we require two public Keys more or less on the recipient side so the recipient can just generate a stealth meta address which is more or less nothing else than two public keys concatenated so we have two public keys they are both compressed we just concatenate them prefix them with st e and so on and then the user can simply publish his stealth meta address and everyone can then use the stealth meta address to generate as many stealth

addresses from it as desired and users so the stealth meta address itself is not something secret or something that the user must keep private so the user can even publish it in his Twitter bio or put it into another contract which is done by EAP um 6538 which proposes to have a central place on chain for the steal for stealth adust management right so that's essentially all um on the slides you can still some find some yeah some further links for example there's a proof proof of concept just to show you how it works then there is a tutorial um if you want to use

steal addresses already today then check out umbra.com guys they are already working on that for two years and they are live on mainnet and some layer 2 so you can use steal addresses already today compared to the ERC it's a little bit less efficient but they they are already live so addresses can be tried out already today on on the main net and there is also a paper so we recently wrote a paper about steal addresses it's called um base sap so kind of the base layer for stealth address protocols um and you can also find that paper which also covers everything I said in much more detail yeah that's essentially all thank you very

[Applause] much thank you Tony great stuff great stuff right we have some time for questions so if anyone has any questions please raise your hands yes do sir hi thank you for the talk amazing um amazing topic uh I like I have a few questions but I guess the main one is that this um scheme where Alice announces on chain that she's sending to a stealth address doesn't this erode some of the privacy because if I want to hide the fact that I donate to WikiLeaks I as far as I understand from the scheme I reveal the fact still that I donate to some stealth address because I'm using this protocol and like is is this the

case and how can it be over overcome right right yeah it's it's actually the case if you do everything in one transaction so if I send you some funds and in the same transaction I emit that event then everyone can see ah I just did a stealth address transaction the thing is you could also do it separately if you care about that so you could send the funds to the staff address and in another transaction or even from another account emit the event so you can then use the contract to just say him okay I just want to emit some information um while doing nothing else in that transaction yes uh thanks for the presentation so um I have a question I guess in a similar

Direction so you explained that you cannot use actually the private or public key for um Alis account and that you actually have to generate an eal pair every time and so the first question is why is that the case it's not clear to me and uh in case you could let's say just use public information then you could avoid this problem of announcing I guess right because Al public is already announced in a sense M and uh then the question is could you use maybe U if you can't just use the public key some other public information as I don't know publicly unknowns together so that it would generate every time something different right right right yeah that's a that's a very good question um the thing is why we use a random CH random keeper instead of Lis keeper is more or less so let's say I

send you um I sent to your stealth addresses 10 times right so I would more or less generate a new private keeper for every single transaction and then I would have 10 different stealth addresses so kind of every transaction that we have would be completely unlinkable of course if I want to I can also send to your staff address um twice but that unve a little more information and then you use something mutable but still the the or some from the that's a good idea yeah um I think even some of the papers I just had on the slides um did exactly that so for example um our first interaction requires um let's say I generate a stuff

address for you and then I sent to that stuff address and then we can say okay as soon as we have the first interaction between us we just increase Anns that would work yeah okay thank you Tony sorry I'm afraid uh running shorten time so uh yeah give a big round of applause to Tony again