 First of all, it's a pleasure to be here. It's very nice to be talking at DEF CON, and four years after just this event, make me quit my job that I had so far and dive into this crazy botanical chain. So, let's continue. Alright, so I would like to start off with what back then was actually the vision of Ethereum. And the vision of Ethereum was actually not just a DeFi magic token machine, but it was going towards DeFi 3, right? And in fact, Ethereum comprised many parts, and the blockchain was just one of them. There was supposed to be decentralized storage, messaging, like Swarm and Whisper, and then I guess somehow crypto winter happens, a lot of things shifted around, and we're happy that we still have the Ethereum blockchain around. But to me, this whole vision of this Web 3 vision of building decentralized and privacy-preserving applications is still something that I find very appealing to going beyond just financial applications, because me personally, I mean, my e-banking is not the most exciting application I have. And in the meantime, a bunch of things happened, and a bunch of things have also quite some focus on privacy, like we heard already in the panel right now that we have mixers, right? So transaction and value can be handled relatively well in a decentralized fashion. We've seen a lot of applications there. We also see quite some movement on the storage front, right? So obviously, I give us Filecoin, guys, but also StoreJ, which I heard runs IPFS, fine, and a bunch of others. We also see a lot of computational-focused projects, which I turn again, many of which have quite some emphasis on privacy. But what I would like to talk about more is that for many of these applications we really need a fundamental privacy foundation to enable communication between users and dApps and between different components of these dApps, right? So this is what we're aiming to build with Popper. And I would like to go a little bit into the why. Like, why would we do that from an Ethereum perspective? So one thing, and I don't know if the Tornado guys are still around, but this is from the Tornado website, right? So if you try to use... Who here used Tornado, actually? Anybody use mixers? Okay, so you just leaked some metadata, by the way. So, yeah, this is what you find on the website. Make sure to use different IP addresses for deposit with dolls, we can run using Tor browser or VPN, right? That sounds fine, but actually neither Tor nor VPN are suitable in my mind to this DeFi level privacy which we're striving for here. So Tor is not decentralized at all. It's relatively easy to de-anonymize and there's like a body of research on that whole topic. And VPNs are primarily corporate entities that are gathering some data and making it available for whoever needs it or for whoever pays for it, right? So this is the business model of VPNs. Now, more specifically, broadcasting is not privacy-preserving. And I would like to highlight this here because I see a lot of conflation between kind of broadcast-based schemes and mesh networks. I think especially in Bitcoin and ecosystem, you hear that every now and then, we have this mesh network. This mesh network and that's why it's private, right? No, mesh network does not bring privacy and the same goes for any other broadcasting-based scheme. So I would like to briefly go through an example. So we come up with a hypothetical network. So topology is having some nodes and initially nodes don't know a particular transaction. Once they do know a transaction, we mark this X. In between, we draw some lines that show the edges, the connections of these nodes. And what's important is that this is totally public information, right? Anybody can query a note. Anyone can find out who has what transaction at what time. So our hypothetical network topology looks like this, right? And what we see is that as a transaction kind of ripples through the network and gradually reaches all of the nodes in the network, you can of course, what you were just seeing, you were a passive observer of the network, right? And you as a passive observer of the network were just finding out where this transaction originated from. And this is something that not just you can do, this is basically something that anybody out there can do, which is pretty bad for a decentralized system that wants to bring us privacy and has all sorts of nice features on chain. And that again is the reason why the tornado guy has made this suggestion, right, to use VPN or Tor. And finally, one example that I find particularly striking is today I think we still live in this frontier world, right? So to me, this is, we're really mostly at this Ethereum 0.1 stage, right? So what we see is that when you and your dad were on Osaka, you have metamas that connect to, well, default in Fura, right? Let's face it, that connects then to the so-called decentralized Ethereum. And what we increasingly see, and I'm happy that we have projects like Datna, Avato and some others and that you have your note in your living room that you can connect to, right? So this is what we can do and still like your hotel Wi-Fi provider, their ISP and everybody in between can pretty easily find out that you're accessing your service and that you probably just broadcasted a transaction on tornado. So what I would like to see is like a less revealing link between you and your dad and actually denotes that your interface. So this is what we want to do with Hopper to connect you in your wallet and to metadata private Ethereum network. Now Hopper is decentralized, incentivized, privacy preserving messaging protocol. So we don't build a channel application, people can build on top of that. Hopper is also a mixnet. So now we're going to work briefly in how we achieve this privacy. So mixnet basically means that note sustaining messages. These messages are received by a relayer which is short term caching them and we keep this updatable so that it can cater to different types of applications is then mixing the ordering of the transaction before they're relaying them in a different order. And what is important is that an incoming transaction and an outgoing transaction cannot be linked, right? They look different and there are some packet formats that are optimized for exactly that so that your traffic cannot be linked between incoming and outgoing transactions. Now we use onion encryption so basically we don't just do that once but you do that in multiple times. So basically if you pass that message through a chain of relayers that each take one onion layer of an encryption of it you have linkability that is hard to establish beyond gasoline. Why would they do that? Well, and this is an important point to me and one that makes the whole design of this network a lot harder is because they earn money for it. Who here is running a tour note? One, two, two and a half. Two and a half. So we have two and a half. Are there two and a half? How many exit notes do we have in the room? Ah, okay. Why not? Why not? I mean Switzerland. Ah, okay. I mean the question is why would you, right? There's something that comes at quite non-zero cost especially quite non-zero legal cost so why would you do it, right? So any system that runs at scale needs incentives and I think we've seen how this well just kind of works but still not very works really well for Ethereum or any sort of blockchain systems where nodes don't have incentives to run a phone out, right? So this is why we want to incentivize relayers. So basically a hopper comprises a message with a payment layer and on the message layer we use as described only encryption in the Sphinx format which I will go into in a second a bit more in detail and of course we built this on LibP2P and have a JavaScript implementation that I'll show later and we have payment channels and we will also discuss a little bit later in detail with a POC on Renkeby right now. So briefly on the message layer what's going on. We're giving a message to Dave via two hypothetical relayers their friends Bob and Charlie. So Alice is formatting a message which has a header which comprises two components one is routing information and the second one is payment information, right? And then of course there's the body which contains the only encrypted message. So what she does is she basically she defines the root so it's source rooted and she then assembles the header and sends it to Bob. Now what Bob can see in that header is so far only that Charlie is the next downstream node but what Bob is not able to do is not able to extract the payment just yet because that would allow us to be susceptible to kind of take the money and run attacks, right? So I could just take all the money out and not do anything. So Bob actually needs the collaboration of Charlie so once Charlie helps Bob he will receive a key half with which he can unblind the payment channel. And of course it could be that Charlie is just not very nice to Bob and simply doesn't do that but then Bob could basically in the future deny any traffic to Charlie. So that's of course something I mean it goes into the direction of the verifiers dilemma but we basically see with incentives you can improve that because Charlie simply won't get any payment for succeeding transaction that she denies Bob. So it continues in the same fashion Charlie takes the packet with the help of Dave she will then get her payment out and with that we basically have the cycle completed. So this is in simple terms how our message layer works like and now let's look at the payment layer. So on the payment layer what we see is that we see these kind of encrypted payments going around and we have two key halves so it's a secret sharing mechanism which we have in place there and Bob to obtain his payment Bob can derive the first key half and the second one he needs Charlie's help for and with that he can get his payment and Charlie gets her payment. Now if we look at traditional payment journal implementations we see a couple of limitations here that we are trying to improve upon. The first one is of course that we want kind of a tight coupling of the packet and the payment data and the second one is kind of a proof of relay right so we only want you to be able to extract the payment if the next downstream node has actually sent you a confirmation. What we also want is we want you to have a realistic scenario there is packet loss right things don't always go well so we need to be able to have partial payouts and with traditional payment journal implementations you see that payment journals are always set to absolute values right we don't just have delta amounts we set a payment journal to an absolute value so if I send you a transaction or if I send you a million transaction and you were only ever successfully relaying the last one of them you would still get the full payment because it sets it to the absolute value of the last transaction so that's one problem and the second one is you could say well we kind of unlock a payment on a packet by packet basis but that would be kind of a huge proof size which you would deliver to the blockchain and then what could be said is because we heard quite some things about snarks and stars and fancy crypto stuff so the goal of Harper is IoT devices on really small devices that are somewhere out there in the field in which do not have the capabilities of doing really complex computations on there that's what we tried to go for relatively simple critical here so this is a bit more in detail how this proof of relay works and to understand that I will work you once through a setting of a payment channel so our players are on the left is of course smart contract that's our payment channel smart contract and this interaction here is Bob closing his his payment channel so basically getting his money out that he got one way or another from Alice so first of all a smart contract is validating his signature over a curved point that Bob gets from Alice that's the best tool the smart contract is then also validating a pre-image of this point so basically we have this publicly known curve point kind of a pre-image here so this multiplication is an elliptic curve operation so you cannot easily invert it and it could also be as I mentioned before that partial AL should be possible so it could be that some secrets will not be that Bob will not be able to derive all pre-images so there's some parts of that which is which just failed now basically we need to where do we get all these values from what do they mean right so Alice sends kind of an updated curve point with every single packet and she signs it this is an analogy to the updated values of traditional payment channel implementations okay so we have the S total from the difference between two succeeding S totals we kind of have the delta S from which we could also assemble the S fail if something goes wrong I got a package from Alice but I can't pass it on to Charlie so I basically add that to my S fail now for the parts where things did go wrong and they go right so for successfully relayed packets Bob can derive the first key half and the second key half which means the collaboration from a downstream node so the first key half he gets himself whereas the second key half gets delivered from the next downstream node right so basically you just sum that all up and that gives you the pre-image of the you could say the secret which you deliver to the smart contract for payout right so because this one here still gets multiplied it's basically a secret that was known by Alice gets transmitted in a different form over the wire and then can be used by you and only you in order to unlock your payment so this is basically how we achieve a payout conditional to the delivery of a packet evidenced by having a key half from a downstream node and having an efficient settlement that is basically that is basically constant in effort in data overhead so we can settle that on Ethereum today cool and with that I think we are running out of time and my connection here is pretty poor so I let you check out ours okay I expected that sorry for that we have a smart contract on here you see some transactions of opening and closing payment channels and receiving a payout for your connections that I do so you can check it out and with that I am open for questions thank you very much yes so does the settlement of the payment not kind of like introducing like leak who sent what to whom yeah that's of course a good question yes of course it does leak something but it leaks kind of minimal information about what payment channels you have and kind of what you used in bulk if you would do something super stupid like you would settle on a packet by packet basis which is not even economical then yeah that would be pretty bad but what I imagine more is that you would do that on a monthly or quarterly basis so you would then say okay every month I want to take my money out and basically what we would see is that you got X out of this and you get I don't know 0.5 ETH out of it so yes it leaks some information but not more than is publicly known anyway and yeah we are working on right now is how do we incentivize people to open as many like reasonably many payment channels useful payment channels to reduce the meaningfulness of this information thank you for the talk and I actually have a bunch of questions so first one is that I know I suffer from high latency so how is the hope of the problem and second one is that recently I noted a protocol called C-Mex it's using mixing as well so I wonder if you guys had a study of that and what's the opinion of that audio computer this fall and then there's a proposal it's to use down-and-routing to prevent front-sensoring from the phone out so is there any possible that you can use the offer protocol to deal with the problem and also opinion, thank you cool, let me try to remember all these so yes basically this sort of peer-to-peer communication is certainly slower than direct communication that's clear the question is how bad and the question is how bad we want to keep customizable by the application layer so if you build a chat app like WeChat 2.0 you want some one-second latency you have kind of okay privacy so there's this fundamental trade-off between privacy and latency if you want to do some activist group emails then probably you want hardcore privacy and you need 30-minute latency so it should be possible to define that on application layer your second question on C-Mex we will need to look in the implementation details so we have a lot of ideas right now out there and not all are really implemented so it's kind of hard to tell this is by the way, it's all open source you can check it out on our github feel free and the third question yes, so right now ethereum doesn't unlike bitcoin ethereum does not support only running out of the box and yeah, that was one of the inspirations why we started to offer as well so do you think that this is going to like ethereum in the future? that's the goal, I mean for us that's the goal admittedly we're pretty early on here right so we're looking at a largely unfunded project for some donations so yeah, but that's absolutely the goal well thank you any more questions for you? do you have to open up a payment channel with every neighbor that you have or I guess with every relay like how do you how does that work and also isn't there a churn in terms of like new relays popping up and other ones going away to have to constantly be opening up new payment channels, is that how many kind of are there? yeah, so how does this work right now, right now we have a slightly optimistic scenario where we open them on demand for you which is quite easy to exploit but the idea is that you have some strategies as to what payment channels you want to open so we would actively you would actively open them we would have some default strategy that you could you could change yourself because it is right you will have some churn but also some nodes will be decent relayers and others would not be, so basically to reduce churn we are currently working on some mechanism of slashing those relayers that are offline for a too long amount of time so basically something that would be annoying is if you're in an underground and you're like offline online, offline online so you have some maximum traffic loss so that's what we want to prevent here I think we have time for one very last question otherwise we just close it here and I'm around afterwards if anybody has questions on a one-on-one basis thank you very much for your attention