 Hello everybody, thank you for the introduction and thank you for attending my talk. In the previous talk, we have heard about the Bitcoin payment system and in this talk I'm here to talk to you about the credit networks which is conceptually different payment system that opens the way for different applications. Let me start with the basics and let me start with an example. So my credit networks allow us to represent trust between users using credit allocations. Imagine that we have two friends, Bob and Alice and for some reason Alice needs some money and Bob is kind to lend this money to Alice. At this moment Alice owes $100 to Bob. Such a normal situation in real life can be represented in a credit network with a directed edge from Alice to Bob with a weight of $100. As you can imagine, this credit network can be used to represent more elaborated situations. For example, imagine that Alice and Bob go for a hike and they decide to invite the friends Dave and Carol and during the hike, Dave pays for a link to Carol and at that moment Carol owes $10 to Dave. However, Carol doesn't know too much Dave and she's not really kind to settle the debt directly with Dave and instead what she can do is use the transitive trust that they have with Bob and Alice. In the credit network, this can be represented with Carol creating a credit link to Alice. Alice will increase her credit with Bob and finally Bob will create a credit link of 10 with Dave. In such a manner, such a debt is settled between Dave and Carol. Here notice that for intermediate uses like Alice, this settlement doesn't incur any credit loss. Before, she owed $100 and now her net balance is the same. Even though she owes a little more, $110, she's owed $10. In the end, the net flow, which is matters, is the same, is $100. Credit network divided by form can be used to perform payments or to pay for services. As an example, imagine that Bob wants to pay for a service to Carol worth $15. In order to perform such a payment, we need to find paths from Bob to Carol with enough credit. Once we find such paths, we need to decrease the credit along the paths in order to perform the transaction. We decrease the links one by one in the whole path and once the credit is decreased, the payment is settled or the transaction is settled. At this moment, you may wonder, well, why we really care about credit networks? It turns out that credit networks tolerate misbehaving users. Imagine the example that Abe became malicious and for her now it's really simple to create many other users under her control and create credit links between each other, extend credit between the users that see controls. However, it's difficult for her to get trust from honest users. So in a credit network, introducing nodes for an attacker is way easier than drawing trust from honest nodes. Such a symmetry allows us to characterize the misbehaving user effect. In particular, the effect of a misbehaving user is localized to those users that have extended credit to the attacker and is bounded by the amount of credit that honest users have extended to the attacker. Such nice properties have boosted the use of credit networks in several applications. For example, credit networks can be used to prevent spam in the email system. They can also be used to improve the online reputation system in online marketplaces like eBay. It has been shown that credit networks can also be used to create a civil resilient content voting and the idea is that credit networks have been used not only in academia but there are also real life deployments of them. One example is Ripple that has used a credit network to create a real life online payment system and because we are in real world crypto, I thought that I'm going to focus on this example for the rest of my talk. The interesting point with the Ripple network is that the nodes in the graph represents not only users but also banks like CBW or Cross River here in USA or Fedor and Santander in Europe. They also represent gateways which are entities that allow us to integrate cryptocurrencies into the Ripple network. In doing so, the Ripple network supports fiat currencies like dollars, euros, pounds or you name it. It also supports cryptocurrencies like bitcoins and even the users can define their own currencies. Ripple has several advantages over the current banking system. In particular, Ripple can perform inter-currency transactions even all around the world in a matter of seconds instead of days. It's possible to perform inter-currency transactions worldwide at a really small tiny fee and while in the banking system, banks are the only ones who are able to check the integrity of the transactions. In Ripple, transactions are publicly verifiable. The interest here is that Ripple is deployed today, it has around $1 million trade volume today and several banks are actually using Ripple for performing the transactions for their clients. Just to make sure that we understand the difference between them, we might wonder like we already have Bitcoin, we already have cryptocurrencies. Why do we really need a great network? As I said before, they are really conceptually different. A cryptocurrency like Bitcoin is a currency and in doing so, it only accepts payments in which both the sender and the receiver accept Bitcoins. However, in a great network like Ripple, it's possible to perform transactions in any currency. Actually, the sender can specify one currency and the receiver can receive such transactions in a different currency, which is called an inter-currency transaction. Such definitions give us differences in how they work and the properties that we get. For example, transactions in Bitcoin are performed as a direct transaction between any two wallets in the system. However, in a great network like Ripple, transactions are only possible by a path between the sender and the receiver. They also differ in scalability. We have seen that Bitcoin, the permissionless nature of the conceptual algorithm makes it a bit slow and transactions are added to the system at a limited transaction rate. However, the local nature of transactions in the Ripple network make the possibility of adding them quicker and make the system highly scalable. Nevertheless, even that Bitcoin has successfully used a public log to perform public verifiable transactions, Ripple has adopted the same idea and it's also possible to publicly verify transactions in Ripple. Actually, Ripple has a log that is called Ripple Ledger and as you can imagine, they store the whole set of transactions in the beginning of the system until today. They also store all the credit links between any two users in the system. In such a log, users are represented by the hash of the public key, a pseudonym. And as you can imagine, it's possible to link together all the transactions that are performed by a given pseudonym. We know that such pseudonymity leads to only linkable anonymity and such weak privacy notion is prone to anonymization attacks. Actually, there have been several works in Bitcoin that have shown that such weak privacy is actually a privacy problem. However, it has not been shown for Ripple and we wonder ourselves like, is privacy actually a real problem in Ripple? And if so, can we actually measure that? And the answer is yes. And for that, we define two novel statistics that I'm going to explain now. Let me start with the simpler one and let me start with a story. Imagine here that Carol has some Bitcoin in the Bitcoin system and she wants to pay to Bob in euros. Because Carol is in the Bitcoin system, she cannot pay directly to her. Instead, she has to use the Ripple system. In order to do that, she needs to use what is called a gateway, which is an entity that has an account in Ripple, another account in Bitcoin, and allow the transfer for one system to the other. Doing so, what Carol will first do is send the Bitcoin to the gateway and such transaction, as we know, is locked in the Bitcoin blockchain. Now, when the gateway sees that they receive the bitcoins, see the gateway sends the corresponding credit to Alice in the Ripple network. As in Bitcoin, the transaction is locked into the Ripple ledger. And now that Alice has seen that has enough credit, she can perform an inter currency transaction and pay Bob. The point is that these two transactions are partly available, so we can just take a look at them and see that Alice, which are the Bitcoin and Ripple addresses that belong to Alice, and similarly, we can do the same for the gateway. And as you can imagine, this is only the tip of the iceberg. We were able to do the same not only for Bitcoin, but for other cryptocurrencies, like Bitcoin, and we were able to do it for other credit networks, like Stellar. And I wanted to stress here that this is the first heuristic that allow us to link wallets that belong to the same user across different payment systems. The heuristic is based on a behavior that we do in our daily lives. So imagine that we have a wallet that most likely we are not going to carry like 100,000 euros on that. Most likely we are going to carry a smaller number, like 100, and we pay for our dinner in the restaurant, we go to the cinema, and whenever we run out of cash, we go to the bank, we draw some money and top off our wallet to keep purchasing products. Such behavior can be reflected in the repo network. For example, a gateway like BitSum will create a wallet, which is called the call wallet, that is used to issue credit to the clients. However, BitSum will not use this wallet to perform the daily transactions with the users. Instead, we'll create another one, which is called hot wallet, and create a credit link from the call to the hot wallet. Now, BitSum can use the hot wallet to perform the daily transactions with the client through the path that it has with the call wallet. And the reason to do that is because now, if the hot wallet becomes compromised, the attacker has access only to the 200 credit here, but not to the credit of the users. Once we realize this behavior, we wonder ourselves, well, let's try to link the hot and cold wallet belonging to the same user. In order to do that, we define as an heuristic that looks at the correlation between the network topology and the transactions in the repo network. In this example, we know that the call wallet is used only to issue credit to the clients. So we know that this should have only outgoing links in the credit network. So we know that A should be the call wallet. Now also, we know that the hot wallet should be connected to the call wallet. So we know that potentially B, C, and D could be the hot wallet. But obviously we want to refine this a little. So we further know that the call wallet must be used to top off from time to time the hot wallet. So now we look at the transactions and we see that A is paying to B. So we suspect that B might be actually the hot wallet. But we can even further refine this heuristic. We know that the hot wallet is also used to fund client the wallets from time to time. So we can take a look at the transactions and we see that, in fact, B is paying to D and C. Therefore, now we know almost for sure that A and B are the call hot wallet that belong to the same user. In order to verify the effectiveness of our heuristics, we downloaded the complete repo network graph. We downloaded all the transactions in the repo network from January to December 2015. And this slide represents our results. In green, we show which are the transactions where both the sender and the receiver are publicly known to the gateway. While in red, we show which are the transactions in which either the sender or the receiver have been denonymized by our heuristic. Interestingly, we show that our heuristics are able to denonymize as many transactions and they were known already for BitStorm. We also saw that if you look at the known transactions for Chris, Ben, David, and Ripper at DYM, seems that they don't relate too much to each other. However, our heuristics were able to link together their wallets. So we know that they might belong to the same user. Actually, the Ripple community has been able to verify that actually, DividendRibbler and DYM actually belong to the same user. We notified the results to the gate grids and we got an answer from two of them, BitStorm and RippleFox, and both of them acknowledged our results. For curiosity, RippleFox actually decided to publish all the wallets after we notified them. That's why they appear all in green now, actually. Funny fact is that even after this work, I managed to get an internship at the Ripple company. So when I was there, I showed them this work and this work actually triggered an interesting discussion about the necessity of privacy in such a great network. There we also saw that banks actually strongly demand privacy and obviously the Ripple community is also really concerned about the privacy problems of the current Ripple network. We also shared our results with the Ripple community triggering discussions in the Ripple forums and we believe that this work should inspire us to use privacy enhancing technologies in the current networks. From our side, we started such use by asking ourselves, well, wait a minute, what does it mean actually that this is the concept of privacy in a current network? And in our paper, we defined two notions of privacy. The first one is transaction value privacy and the idea here intuitively is that an attacker should not be able to determine which is the actual transacted value between two onus users. The other notion is transaction receiver privacy and the idea here is that an attacker should not be able to determine which is the actual receiver of a transaction given that we fix the center and the transacted amount. As you can imagine, the transaction center privacy can be defined in a similar manner to transaction receiver privacy. Here, I don't have time to explain the details but we have formalized these properties as cryptographic games and all the details are in the paper if you're interested. The next step was to define a system that achieved these properties and our first approach was a centralized approach that we call brief pay. The idea here was simple. We have a server or a service provider that maintains the complete credit network according to the request that comes from the users. As you can imagine, such a setting has a huge privacy challenge even if the credit network is stored because it's encrypted, sorry, because the access pattern to the encrypted data might reveal enough information for the attacker to break privacy. So in order to overcome this challenge, what we did is we used a minimum trusted hardware to perform the encryption and to run oblivious algorithms that hide also the access pattern when accessing the encrypted data. We were able to prove that brief pay provides strong privacy guarantees for the first time and also to show the practicality we downloaded the whole set of transactions in the Ripple network and emulated that in brief pay. We saw that the running times are similar to the running times in the current Ripple network so this system is practical. And in our next approach, we observed that I as a user in a credit network would actually really care who owes money to me and to whom I owe some money. So basically I care about the local credit links and as soon as the net flow in the credit network doesn't change without my consent, I don't really care about what happens from two hops away from me. So therefore we defined an approach, in which every user locally stores his local links or the links with his neighbors. And then the users collaborate between each other in order to perform multi-hop transactions. The idea here is that with such a system we don't really need a ledger which is first privacy invasive, as we have seen and second is really big. Actually the Bitcoin blockchain right now has around 90 gigabytes which consumes a lot of memory. And on the other hand in our approach we don't really need also the proof of work which as we have seen in the previous talk consumes a lot of resources. In Silent Whisper we were also able to prove that it achieves strong privacy guarantees as in brief pay. And again we emulated the same set of report transactions and running times for executing these transactions were in the order of seconds similar to the current times in the repo network. Nevertheless, although these two approaches provide strong privacy guarantees are interesting the main problem with both of them is that they cannot be deployed today in the repo network. Either because we need to deploy some minimal trusted hardware which is not there yet or we need to totally avoid the repo ledger. Therefore we ask ourselves like what can we do to have a privacy preserving transactions in the current repo network? And in order to answer this question we define we are actually working on a new protocol called Pathsoft. And the idea is to perform what we call path mixing for privacy preserving transactions. The idea is really simple. So imagine that in the field here we have a set of senders and a set of receivers and we want to perform several transactions from each sender to its receiver through a path that share a common node. For example, in this example imagine that every sender sends a common amount let's say 10 and now every receiver simultaneously also receive the same amount let's say 10. If we have an attacker that has access to the network before this transaction and after this transaction it's not able to figure out who is paying to whom. Some of you might have guessed already that this idea is similar to conjoin in Bitcoin. For those of you who don't know conjoin transaction is a transaction in which we have a list of input addresses a list of output addresses and if the transaction is signed by each of the input addresses the bitcoins are simultaneously or atomically transferred from the input to the output addresses. So the transaction is supported by the current Bitcoin protocol and it's actually deployed in practice. So our natural first idea was to deploy exactly the same in Ripple. The problem is that Ripple only allows transactions that have a single sender and a single receiver. In order to overcome this challenge what we define is what we call a share wallet and the idea is that we take the private key of the share wallet and distribute that among the users that participate in the path mix. In such a manner we're able to enforce rounds of synchronization such that every user agrees and then the protocol continues or honest user doesn't agree because some other user misbehaves and then can't stop the protocol at that moment. In such a manner we ensure that honest user don't lose credit in the process. PathSafo has interesting properties. First of all it enables atomic transactions for the first time in Ripple which have interesting applications other than privacy. For example we imagine that you can use it for crowdfunding in which either everybody contributes to the crowdfunding or if there is not enough if not enough credit has been raised then nobody loses credit in the process. The idea is that PathSafo is fully compatible with the current Ripple network. Actually we were able to successfully test one PathSafo transaction in the real Ripple network in the mainnet and it's also compatible with other merging creating networks like Steader. We observe that PathSafo can be seen as a simple smart contract even though Ripple doesn't allow yet a script a script language like in Bitcoin. So what we wonder at this point is that is it possible to create other smart contracts even though we don't have a script language yet or is there any inherent limitation by the fact that we don't really have a script in Ripple yet. We don't answer any of these questions and in the future we are also looking into applying our privacy techniques to other emerging creating networks like Steader and other distributing scenarios like the lighting network which a pair of users share a link if they have a Bitcoin payment channel between the two of them and obviously if you are interested in this topic I'm open for collaborations and if you are interested just please come and in the last minute I would like to thank my collaborators for all the helping me in all this work actually Tim Ruffin is here if you want to talk to him and I would like to thank them to make creating networks great again. Right so do you have time for one question so go ahead. Feel free to correct me but my impression so you talked a lot about Ripple gateways but my impression is that is there any more well at least I couldn't find anyone working and I heard that this concept is dead so is it true and if it is could you comment on the relevance of your research in this issue? So first thing I have to say that Ripple is newer than Bitcoin as any other new system is really dynamic so it changes a lot. There are gateways that are working today so I'm still there gate hub there are several of them that preserve over time but these two that are some that start at the beginning and are not there any longer so the idea is that their gateways are still there and those gateways are there are still using these techniques so we can apply that to those gateways today as well so there are today and they are still working on that. Alright so let's thank the speaker.