Unlinkable Payments: The Beauty of Stealth Addresses

Transcript

I'm really happy to be here today to talk about a topic I'm really passionate about which is blockchain privacy maybe to be more precise today the next 20 minutes I'm planning to talk about stealth addresses and even more precise it will be about ERC 5564 which is also called stat addresses and maybe let me quickly introduce myself to those that don't know me yet my name is Tony bartletta I work at the Vienna University of economics and business doing mostly privacy stuff there mostly focusing on bitcoin and efferent privacy maybe some of you might know me from other projects like math booster picks tornado warning which are

more or less hobbyist projects but today's talk is actually very different today I want to talk about EAP 5564 stealth addresses maybe to give you a quick rough outline what I'm going to talk about so the first part I want to define the problem in the second part we're going to cover some technical details about stealth addresses and then we're moving on with use cases for staff addresses and going deeper into the weeds with eap5564 and why some standardization is needed to finally get some adoption for Stuff dresses so let's directly dive into the problem definition as you can see here on the

slides we have two entities which is a lesson bar and Alice has some money that she wants to transfer to Bob so far so simple the problem here is there is a large crowd looking at them because the blockchain is of course publicly accessible and transparent and Alice she cares a lot about privacy and she wants to avoid that people can create a link between those so Alice doesn't want to create a link to Bob and this might have a lot of different reasons for example Bob might be a politically exposed party or Bob might be a seller of some illicit Goods there are many reasons why people just want not to create a link between two

entities so what Ellis could actually do is she could just reach out to Bob and ask Bob to generate a fresh address for this interaction Bob could be like here let's do that and then Bob generates a fresh address which is here address C and Alice could then use the fresh generated address to just send the money there so far so good the only problem is it needs some interaction beforehand so at some point Bob would probably be like okay wouldn't it be cool to do the same but without requiring any prior interaction and this is exactly the point where both of them might discover stealth addresses so staff addresses kind of allow Alice

to generate a fresh ethereum account a fresh ethereum address that has never been used um in the name of Bob Ellis will then just send the money to the new stealth address knowing that only Bob will be able to access the funds there for everyone else it would look like Alice just sent funds to a new address and this could be um even Alice herself so maybe Alice just switched her wallets and has transferred the money to a new account and I um I remember vitalik has mentioned that shortly you just don't want to create a link between those entities and what LS and Bob have achieved in this example is

unlinkability so what they don't achieved was untraceability but they get unlinkability so they get the property of not creating a link between the sender and the recipient um unlinkability is defined by for any two outgoing transactions we cannot tell that they went to the same entity and this is exactly the case here because we cannot tell that address B and address C are actually both controlled by Bob so how does it work essentially it's quite simple when you compare it for example to more sophisticated stuff we already hear it

like CK snarks or homomorphic encryption because we only need elliptic curve map here so we have both entities again we have Alice and Bob and Alice and Bob both possess a key pair and the lowercase letter here is donated as the private key and the uppercase letter is the public key so um essentially Bob has his own keeper and Alice can just create a random keeper so this is important Alice is not using her own keeper Alice is actually using a randomly generated keeper to generate the step address so the first step LS what Alice has to do is Alice derives the private at the public key of Bob so the public key is public so this is no challenge for her

Alice gets the public key of Bob and then she does The Following Alice multiplies her own private key so this is an elliptic curve multiplication C multiplies her own private key just to recall it's a randomly generated private key she multiplies it to the public key of Bob she hashes the result which gives her a hash chat secret kind of and then she multiplies the hashtag secret with the generator point of the elliptic curve which then gives her a public key so an elliptic curve coordinate that she can then use to add Bob's public key to it finally this will then be called the

stealth public key and Alice can just convert that stealth proper key to an ethereum address and we'll be able to send to that ethereum address so this is described in the third step Alice would send to the ethereum address and would also publish her ephemeral public key and here just to recall the ephemeral public key was created from some random integer so it's not actually Alice private key it's some random integer where else derived the public key from now the funds are now on the stealth address and now we need some way for Bob to find out that he received the money so what Bob does is he takes all the ephemeral public keys that have ever

been published on chain and he Loops over them so he takes all of them and then she he just tries out if one of these ephemeral public keys can be used to derive an address that has some funds on it and if there are some funds on it then Bob can be sure that that's actually in self-address that he controls so what Bob does he Loops over all the ephemeral public keys he multiplies his own private key to it he does essentially the same that Alice does but with his own public key and his own private key so you can see um Bob in the end he also has this value MHS which is the hash shared secret between both Bob multiplies it with the

generator point to get an elliptic curve coordinate and then he can just add his own public key to it and and that's essentially it so what Bob can then do he can also derive the private key to that address and that's the kind of the magic stuff that is here involved because Bob has his own private key and he can use the private key and add it to the hashed shared secret which is here denoted as HS and by doing so Bob can derive a new public new private key that is then able to access the funds on the Staff address and for those interested why the whole thing works it's essentially this equation holds true which says okay we have the hash shirt secret and we can

multiply it with the generator point of the elliptic curve and then add the public key of the recipient which is the same then first doing a simple arithmetic addition between the private key of the recipient in this case of Bob plus the hashtag secret and then multiplying the whole thing with the generator point so this is essentially the background how the whole things works and yeah we can maybe one more thing um staff addresses have been continuously improved over time so the first iteration so the first proposal for staff addresses is from 2011 and it was improved in 2013 in the crypto node white paper and what the crypto node

white paper essentially did was equipping the recipient with two public keys so the recipient here has two public Keys one is the spending public key and the other is a scanning public key many of you might know that from Monero or something other privacy focused protocols so what we can do here is we can separate the parsing process from accessing the Staff address so this means we can now give the scanning private key which is here denoted as smaller lowercase SC we can give that away to a trusted third party which could be some telegram bot or something else that can then notify the recipient as soon as a stealth address transaction

appeared so Bob would not be forced to do the parsing which is some heavy computational work himself he could just give away his scanning parsing his scanning private key and then he can get notifications every time when he received some stealth address transactions right then let's let me quickly come to the to the question why do we even need some standardization and why ERC 5564 even exists the problem about staff addresses is that stealth addresses are not directly equal to staff addresses what I mean by that is there are many many different protocols we can use today to generate stat addresses so I just showed you a

very simple protocol that used the SEC for example the SEC 256 K1 curve that is also used on ethereum but we can actually use many different approaches to generate these data choices for example just to give you a sense Academia has came up with many many different proposals of how we can generate stealth addresses and how we can continuously improve them so on this slide you can see staff addresses being computed with post Quantum secure lattice based cryptography but there are also staff addresses that use elliptic curve pairings for example but the essence here is standardization is key so we need some way to tell the

recipient how we calculated the Staff address because otherwise the recipient would have no possibility to find out which protocol was used to generate the status and this is exactly where ERC or erp5564 comes in because Erp 5564 proposes this standardized framework where we can transmit the information that is required by the recipient to know which exact status protocol was used to the recipients so that the recipient can directly continue parsing in the right way for those knowing um some parts of solidity you can directly tell how simple the contract is

so the contract essentially only has an event which is the announcement that finally includes the information that is required by the recipient to First find the stealth address and second derive the private key to the staff address and second there is a function and that can do nothing else but emitting the event and what the event includes is is address himself the ephemeral public key and some metadata so the shim ID is the part used to indicate which style of address protocol that was used for example we could have the SEC 256 K1 curve having the shim id1 and then we could have some elliptic curve pairing

based stefit address protocol having the Shema D2 and by looking at the shimadi the recipient directly knows okay if I want to check if that Staff address transactions went to myself I will just have to um see what the shimad is and then continue in the using the right stealth address protocol secondly there is the stealth address itself that is included in the event and this is just some ux improvement to not require any RPC calls for positive balances because as soon as the recipient has derived the stealth address he must he must only compare if the Staff address locked in the event matches the Staff address he computed or she computed and if so then he can be

sure that the Staff address belonged to to that entity third the femoral public key which is the important information for the recipient to um to find its own Staff address and also to calculate the private key that can finally access the Staff address and and lastly there's the metadata field that can be used to indicate which token contract was interacted with so you can also send erc20 tokens ERC 721 tokens by just specifying the token contract address in the metadata and there there's additional place in the metadata you can also put the method ID into the metadata

field and also the amount of tokens that was interacted with so EAP 5564 also comes with its own address format the address format is nothing else than a prefix and two public Keys just to recall that's the two public keys so the parsing public key and the scanning public key are also often referred to as the viewing public key and they are encoded in one address format so the address format is quite long as you can see because it essentially holds two public keys they are both compressed so we have the prefix and two public Keys the spending public key and the viewing public key and together and they create this new

address format where users will just need to get the stealth meta address so this is called the stealth meta address of the recipient input it into some user interface and then the user interface is able to generate a stealth address on the Fly and directly um sent to that Staff address so the user will only need the stealth meta address of the recipient and importantly and there's no way to create a connection between the stealth meta address and the stealth addresses created from that staff met address so the staff materials can be published for example on some website in the Twitter bio and it can also be published as another Erp in some central place so

having a smart contract that just stores the staff matter address which can be used to Signal the ability to receive stealth address but also having some central place that one could use to store his own her own stealth meta address for others to find it quickly what to use them for so vitalik already mentioned it um briefly staff addresses are very handy to be used for donations because donations have this property where you often want don't want a link between the the donor and the recipient so for example if you're in politically exposed party and you want to be able to receive

donations but you know that people might not want to donate to you because of this public link that is created then staff addresses are perfectly fine because they can in this case protect the sender of donating because the sender can then be sure that there is no link between the politically exposed party and herself furthermore payroll checks so you could just give the stealth meta address to your employee and your employee will then be able to generate stealth addresses on behalf of you that you can then access so you would receive your payroll checks to your new Staff address every time third multi-signatures so also metallic mentioned that very

briefly so that if you don't want to um let your multi-signature signers know who the other signers are you could just grant them access rights to his signing rights to a self address this would then mean that the individual signers they would not be able to find out who the other signers are because you would not Grant signing right for example to Alistair leave and pop the leaf part two stealth addresses of them and finally there are some other use cases like private pull-ups and stuff but more or less it's every interaction that should remain private so every injection where you don't want to create a link between descendant to recipient that's essentially all so thank you very

much I want to point out there is a proof of concept so if you have if you bring have if you bring your laptop with you just you can go to stealth stealthyphenwallet.xyzat so there is a proof of concept deployed on zipolia so you can use it already today and it might not work on on mobile but it will work on desktop so um try it out it should it should be working and also a big shout out to the guys from Umbra Umbra you can find them at app.umbra.cash it's a application already deployed since 2020 implementing stealth addresses in a little different way than EA and then erp5564 does but it's essentially already live on mainnet and you can use them already today and

also you can find my contacts here if you have any questions or if you are what if you're building a wallet that cares about privacy then feel free to reach out I'm really happy to answer any questions thank you [Applause] [Music]