 The next speaker speakers are from Gru Taylor, an online payment system. Our guests and speakers are Christian Grothoff, Jeff Burgess and Serenity. So enjoy this talk. Thank you very much. Thank you. And thanks to the organizers for inviting us to present. Let's start with a bit of a motivation. So in 1971, the American think tank, the Rand Institute, was asked, suppose you were an advisor to the head of the KGB, the Soviet secret police. Suppose you are given the assignment of designing a surveillance system for the surveillance of all citizens and visitors within the boundaries of the USSR. The system is not to be too obstructive or obvious. What would be your decision? Anybody know what the design is they came up with? It's not the internet hint. Yes, they pretty much proposed a design that is remarkably similar to modern credit card systems. So welcome to the USSR. Or some of our friends put it. So to quote Snowden, I think one of the big things that we need to do is we need to move away from true name payments on the internet. The credit card payment system is one of the worst things that happened for the user in terms of being able to divorce their access from their identity. So it's not just that the credit cards have numbers. It's the idea that you need to prove who you are in order to pay. That's the problem. That's a social problem. But it turns out also our friends in the banking industry, they also have a problem called 3D secure or verified by Visa. So it's a very complicated process. You've all probably suffered through it by now. The main feature that it had when it was introduced, I was saying, okay, with the old credit card payments system, we just have to type in the numbers. You as the merchant are liable. If we do this new thing, you have to enter your SMS receive pin or some other things. Then we can shift the liability to the customer. So that's the main new feature that they introduced. Introduce a significant latency. So if you want to do a credit card payment process, if you can do this under 30 seconds, you are really, really good. It can refuse valid payments. At least me, who I'm traveling a lot, I frequently get, well, payment refused. You're in the wrong country. What on earth are you doing in the Netherlands? Legal vendors can be excluded. So various legal shops have been told, well, we're not going to process your credit card payments anymore. You're bad PR for us or governments don't like you. And of course, as a buyer, you have no privacy. So this will be replaced simply because the technology is so awful. The big question is with what? So there's one proposal, a family of proposals running around, which are that the big payment, the big tech companies will do this for us. Essentially, so Amazon or Apple or Google or somebody like this will impose a payment system through their software and hardware platform and people will just use it because it's very convenient. So essentially this is creating another oligopoly. It doesn't address any of the privacy concerns. If anything, it potentially makes them worse because the banks haven't really figured out how to use a lot of this information. They just now sell it to Google. But it's also, it is somewhat worse in the sense that it loses what kind of federation they already have. And it means to some extent even fewer points of failure. There's also another proposal out there, of course. It's the blockchain world with bitcoins where the main feature that is often proposed is saying well, we don't need all of this banking regulation. Interesting technology. It has a huge advantage that it's actually implemented in free software unlike most of the rest of our banking system. Try to get the source code for a visa. It's actually free software. You should look at it. It's a decentralized peer-to-peer payment system. But as any payment system, it has to solve a simple problem which is Byzantine consensus. We have a bunch of parties that are possibly ill-behaved, very likely malicious because it's about money, and they have to agree on our balances. That's Byzantine consensus. We have to have an agreement among parties that are not necessarily trustworthy and they have to agree on who has how much money. And that's fundamentally an expensive problem to solve. And the Bitcoin people solve this by tying initial accumulation. How do I distribute bitcoins initially by solving this consensus problem? Yeah. So the idea was to make it competitive for adding new transactions to this ledger. But of course, this results in an extremely expensive system. And even if you could somehow solve the proof-of-work problem, just the distributing all the information to some fraction, the substantial fraction of the nodes is extremely expensive. So even just the blockchain itself, the scaling problem is already there even if you can magically make the proof-of-work go away. So it's extremely expensive banking. And of course, the other thing is... Here's the example of it being extremely expensive. The current average transaction value on the blockchain is about $1,000. This is not being used for normal purchases. The transaction fees for a transaction or the average transaction fee is something like $3 a transaction. If you include the mining reward, so effectively how much carbon dioxide is being burned per transaction, you get to like $3 per transaction. And it will be worse in the future. Yeah, it has been worse in the past, too. But the other thing is it doesn't solve the privacy problem. So on Bitcoin, all the transactions are public and linkable. So the state can trace them. They might be able to find out who your account is. They might not. So we neither have the strong accountability where I can say, okay, this is not going to be used for illegal things. So it's kind of great for extortion. On the other hand, as a citizen, if I use it, there's no guarantee that the rest of the world will forever what everything I've done on Bitcoin is about. So of course it has been enhanced with laundering services to better protect our privacy. And there's also cryptographic attempts to enhance it. The strongest of which is the zero-cash system, which uses some fairly advanced cryptography to hide the identity and the value of transactions. It works... I think a zero-cash, poor transaction, an anonymous zero-cash transaction takes about two minutes on your computer just to set up the transaction to do just the very heavy-duty cryptography to get it ready to go. So it's a very advanced crypto, but it's slow. So right now we basically have two choices. We can have a libertarian economy. Great for extortion, money laundering, all of these things. No regulation. And rather expensive. Or we can have this total surveillance apparatus built by the credit card system. Which one do you pick? Well, we try to provide you with a third choice, namely Nutala, which is based on an old idea of digicash, but with a bit more modern cryptography added. That's supposed to provide a privacy-preserving system. So when you spend money, you have privacy. But when you receive money, we call it taxable because your income is visible to the state. So the state can say, was this a legal transaction and did you pay your taxes on it? And of course, we want to make it practical and extremely efficient compared to all of the other solutions so your transactions go over quickly. All right. So we're going to be using electronic coins stored in wallet software, which will be an extension in the browser or something else. We're effectively going to act very much like cash and we'll be paying in existing currencies, so Euro, US dollars, or bitcoins if you want to have. You can use this to make much cheaper bitcoin transactions. So like a side chain. And it's also because everything will be free software and reasonably straightforward. It will be relatively easy to roll out a... roll this out for some sort of regional currency or something else. Any kind of thing where you need some sort of transaction system, whether in regular money or funny money. The high level view of the system is you have the exchange, which is like the payment service provider, which allows the customers to withdraw coins using a process involving blind signatures. So the exchange does not know which customer got which coin. The customer can then spend the coins at merchants have to pretty much immediately online deposit the coins at the exchange. So because this last leg here has to be done online, this is only an online payment system. It will not work if you're offline in the sense of you can't talk to the exchange. Of course it can work if you have a community and the rest of the world has gone dark. You can still pay within your community if the exchange runs within your community. All right, so we're building on... So the idea is we'll build on top of... We use the existing wire transfer network. There can be some aggregation in this or whatever. So the general idea is we have a customer and they want to be able to make purchases. So what they do is they first create an account with some exchange, install the wallet software, create an account, and then what they do is they tell their bank to fund this account by doing... In the US this would be an ACH payment. In Europe it would be a SEPA payment. SEPA payments are I think about four cents if you buy them for the way companies buy them. And for most customers, most SEPA payments, at least as far as I know in Europe, SEPA payments, the cost tends to get hidden these days so you don't see it. Okay, so that's... Once the money has arrived at the exchange, then the customer can withdraw a coin, their wallet will withdraw coins. And these coins are blinded so the interactions that they're doing here will be cryptographically unlinkable to whatever else they do in the system. And while the coins exist, effectively exchange has an SCO account within the banking system to kind of store the value in the existing banking system. So when the customer finds some merchant that they want to buy something from and they spend the coins, the merchant immediately runs this deposit operation with the exchange and the exchange may or may not aggregate those payments but at some point they pay the merchant's bank account and the... But the merchant knows as soon as they've done the deposit operation successfully that they're going to get paid. And... Yeah, yeah. Okay, to make it a bit less abstract, Serenity is now going to give you a demo of the system, a live demo against the real system. You can also go to this web page with an appropriate browser and do it yourself there. Okay, my mic is on. I don't want to test that. So first of all, I'm gonna install the wallet. Nope. What? Demo. Wrong link. Click on introduction. Okay, installation is compatible. Audio torson. Okay, so second of all, you're gonna get an account so you're gonna first of all click on bank and then I will ask you for your login. You can either log in if you already have an account or register if you don't. But... By the way, if you want to get this account, use the name Shash 2017, password is the same. Like everything else here. It's Shash 2017. Never. Money money for this. It's just because for data demonstration. Torsten, you have to say what you were doing. You accepted the fees. I accepted the fees to withdraw some coins. Now 4 minus 4 equals 0, obvious. Withdraw approved. Now you can see in my wallet if I click here, 19.8 kudos. This is just the current demo currency. Meaning that the withdraw fees was 0.2 kudos. Now we're gonna go to the easy shop or whatever it's called I don't remember. And we're gonna pay for a chapter of Richard Stallman's book. Free softwares, whatever it's called. I am not gonna bother reading right now. The payment came up just automatically in that particular setting the payment came up automatically. In case you missed it, you just paid, right? It's easy to miss. Torsten, can you do it again slowly? Because I think it's a bit too fast for the audience. Okay, then I'm just gonna click on the other one. Confirm payment. Here's the contract being shown. Sorry. Slowly, Torsten. They used the credit card payments. They're supposed to take a couple of minutes. So a lot of why it can be this fast is because you're not providing any identity information. Wait, there's one thing left. Donate. Don't do the donations, we don't have time. So I'll just point out that much of why it can be that convenient is just because we're not providing any identity information. You don't have to think about do I want to type my name into this website, you just go. I was actually asked by a representative of Deutsche Bundesbank that we're going to require two-factor authentication in the future. Where do you do two-factor authentication? I said, well, I own the hardware. It's my notebook, one factor. And I have my username and password to my account on that machine. That's the second factor. I mean, it's like cash, basically. That's the point. Okay, so what are the impacts of this? So first of all, it's finally a free software payment system, right? And because your income is going to be transparent, it's going to be very hard to be corrupt in that kind of system, right? I'm sure I can no longer say, you know, I've never got this money. It's highly efficient. We need a couple of cryptographic signatures, a couple of database entries, so transactions, as you see, they go through really fast, you know. And of course, very comfortable to use because you just, you know, need one mouse click. We had people say it's maybe a bit too easy to spend your money with the system. You might get rid of all of it. So it's your privacy. And we're planning on using it to also provide accountability on network usage so we can use micropayments. So you want to access my web service? I'm currently under attack. Attach a couple of, you know, fractions of a cent. And then I don't have to show you a captcha, for example. Yeah. So we mentioned something about regional markets and we'll say a little bit more about that. It can also be deployed in a variety of special situations for kids and other things like that. It should be better for competition as well because since the exchange software, everything is GPLed, we, the ideal would be that there will be multiple competing services that can lower prices this way. The other thing is the system is good against discrimination and for accessibility because the exchange does not have a contract with the merchant beforehand. The exchange says I'm going to issue coins at whatever merchant you're going to spend them. There's no protocol where the exchange can say I refuse to deal with WikiLeaks. You can't. The regulator says issue coins, you better pay them up. So because there is no such prior agreement, you can't discriminate. You're going to really establish banking again as a neutral thing. Like network neutrality, we need banking neutrality. We can't have Google decide to say, oh, we're not going to deal with you. We need a neutral platform. And the protocol ensures this in this case. Because it's free software, the wallet can be there to educate you about your expenses. It keeps a transaction history for you. It can help you analyze where you spend your money. It can warn you about your spending too much. Because it's a free software wallet, we as a community can enhance these features and make sure that the wallet provides us with tools for financial responsibility, not for a way to drain us of our money as quickly as possible. And of course, because it's free software running on my computer, I can tailor it to my needs. So if I have accessibility needs, I might have a wallet that's really tailored to my specific abilities and usability requirements. Want to say more? No. Okay, let's go over some use cases. First, use case. Today, when you're a journalist, you're typically working in some big corporate structure. And the big corporate structure is there because your main source is not selling your articles, but advertising. And that means, of course, that the publishers also have to track the readers so that they can tailor the advertisement. So we have, on the one hand, the drive, we need to understand the readers so we can advertise to them. And then, of course, we have the second problem, which is that we have advertising content and journalistic content. They're really next to each other, produced by kind of the same entity. So is it now advertisement or is it extra journalism? Very hard to distinguish the two. Yeah, so the idea with Taylor, what happened is we can do one-click micropayments like we just showed with the demo. So you can simply run a blog and get paid. You don't need a... The payments can be quite small because the transaction fees can be really small. The... You know, it's relatively easy to set up. They won't be... If you do it in this kind of, in this form, linked to any sort of other corporate apparatus or advertising, and your readers can remain anonymous, which seems like it might be relevant in the case of publishing journalism. Yeah. In other cases, we have lots of people that today are effectively discriminated against by the banking system, either because they don't have the right papers, they don't have an address where they can be registered. This in particular applies to refugees, but also, of course, to kids. And so if you have these non-bankable people, well, they can't use money as an easy way of doing exchange and running an economy. As a result, they are mostly directly dependent on Direct8. There's not really companies that are running in the refugee camps, even though there's a population that could work. The fact that we're excluding them from our monetary system means that they can't easily work in the way that we usually work. And the result is, of course, that they are highly dependent on this aid. So, with Holler, it's relatively easy to spend up a local currency, or to provide some sort... You can have an NGO can provide either its own currency or local currency, or something else like euros as some sort of basic income directly to a group of people, a group of refugees or whatever that are running the software on mobile devices. Then you can sort of create a small economy in that environment, use it with where you have... If necessary, you have taxation for whatever the local businesses there are, and you can start to actually use that money to fund a local government. You can have the sort of mechanics of Western banking sort of just up and running in this aid. And so the next camp, I expect us to run a government here, right? The badges should be a good starting point. Okay, last use case. Well, today, as you might have seen in Anani's talk, we have pretty easy privacy providing authentic encryption for email, which is great. It's free software. It's easy to use because of this encryption available for all the platforms, including the proprietary ones. And the great thing is that the spies will no longer be able to inspect the content of our emails, and the not-so-great thing is today we're relying on spam filters to inspect the cons of email to suppress the spam. Well, if you have effective end-to-end encryption that becomes universal, the spammers will eventually also start to encrypt emails. First, we will hear all of this as a great success. And then once we get 100,000 of those, we will say, oh, that's a problem. One thing that you could do if you want to, if this becomes quite the same, if encrypted spam emails become a serious problem, is you could do peer-to-peer email behind payments in the email so you can include a taller payment in the encrypted message, and the sender attaches some payment, and then the receiver can simply grant a refund to the sender if they don't... The receiver's software can simply grant a refund to the sender if they don't click the junk mail button. So this could work. We haven't implemented anything like that, of course, but it could be done with the underlying... Basically, Adam Becks altered it of hash cash except for with real cash and without the proof of work. Have real income if you spam a sense of spam. Okay, let's move a bit on towards the technology, but we have to first explain a bit what taxability means in Taller. So the high-level idea is when we say taxable, when you're a merchant and you receive income through a system that's going to be visible from you depositing the coins at the payments of his provider at the exchange, and then, of course, they can say, oh, you got this amount of money. And the contract that you agree to with the customer is going to be embedded, the hash of that is going to be part of the payment so that later the state could come to you and say, what was the contract? What did you sell? Is it a VAT or is it income or whatever tax is applicable and check that? The exchange does not see the contract, only sees the hash of the contract because, of course, the contract itself is none of the business of the payment service provider. And because of this, the state can trace transactions whenever you receive money and then apply the right level of taxation. We don't say how high the taxes should be, but we just say the income is visible to the state who can see the banking system and controls it not to everybody, and therefore, the state can apply taxation. However, there are a couple of loopholes. Yeah, so there's a technical loophole that's kind of hard to avoid in any sane way where obviously if you take money out of an ATM, you can immediately hand it to somebody else and this is true for us as well. In this case, you're essentially doing the withdrawals for them. And that, in principle, there's measures you can imagine. If that actually becomes a problem, there's things you can imagine people doing to try and suppress it just by looking at the pattern of withdrawals and things like this. And the other thing is that's somewhat more interesting is there's nothing we can do to prevent transfer of coins amongst people that trust each other. So when we say that Taller is taxable, what we mean is that transactions between people that don't trust each other will be visible to the banks of the recipient of the money. If you're just transferring coins, if you're just giving coins to your brother, there's nothing we can do to stop you from doing that. That's perhaps, one way you can argue that this perhaps should be more liberal than it is in today's society, or that's a subtle point, we don't want to get into it. In general, we've met people who basically said all of these limitations actually features because you might want those. If I want to give my kid money or my spouse money, it might be a good idea for me to just be able to hand over the electronic coins and not have to have them pay income taxes on it. It doesn't make any sense. It's not economic activity as such if it's within a family. Let's talk about the crypto. The high-level point is we're using very, very old crypto as far as crypto goes. But of course, modern instantiation. So we use hash functions, blind signatures, no signatures, Diffie-Hellman key exchange and the cotton shoes protocol in modern instantiation, but they have well understood old constructions for crypto. This is important because some of the other projects in this area are used for other stuff that's like two years old and has not been as analyzed as well, I would say. All right. One thing we need that's kind of essential is what we call a denomination key. This is a key that represents a particular amount of money. This is a five-year-old note. It's a particular RSA key that the meaning of this is that the thing signed by this is a five-year-old bill. So we create... This is just an ordinary RSA key creation. We pick two primes, we multiply them, and then to get this end, the product of them is going to be part of the public key. We take the other token function of that product, which we can compute because we know the P and Q and now what we do is we pick this small e less than phi of n, which is usually around 65,000, and we invert it mod phi to the n, and then what we do is we publish e and n. So the private key of the RSA key is really d or in faster algorithms, d and p and q, all three together, and then the public key is this e and this pair e and n. So that e and n will be published. To make it a bit simpler, using pictures, we throw some dice, get some random numbers, create a public key which you're going to represent by a seal. That's signed by this public key, and we have a tool, which is the hammer, which allows us to apply the seal to objects. All right. So now we also need various signing keys. In particular, the merchants need to be able to sign that they're proposing a contract to a user. And this we do with the ECDSA, which is a particular elliptic curve signature algorithm. So essentially what happens is they pick a private scalar, actually something else, but actually something they hash into a scalar, but whatever, they pick a private scalar and they multiply it by the generator of the curve. To get a curve point that represents the public key for that particular merchant. The main upshot is you have some small value m that you created at random, and it gives you the ability to sign documents with that value. Right? So we also use elliptic curve signatures to create, where customers will use elliptic curve signatures with every coin that they buy from the exchange. And so they'll have a different small c, which is again a scalar on the curve, and multiply by that we get this big c guy, which we refer to as the coin's public key. So for each coin you have a private key and a public key. Again in pictures we just write this public key, this big c like a serial number on the coin, a bit hard to see here. And the small c gives us the capability of signing things with the coin. Then we're going to represent like with the seal. So I can sign things with coins. These are all the keys that we're going to use for now. There are a couple more in the actual system, but I think these are the main things needed for understanding the system. Okay, let's get started. Alright, so this is what's called how we do, this is blind signatures, this is how you would draw money anonymously. So what you do is your wallet will know this, will find or otherwise know the denomination key of the amount of the coin that value that it wants to withdraw. It computes one of these planchets. It makes up a private scalar, comes up with a big c, which is the curve point corresponding to it, the public key for that coin. And what it does is it takes, for technical reasons, a full domain hash of c, and that is the thing that is being, taking this full domain hash is the first part of the RSA signature algorithm. And so what it does to have the blind signature is it picks some blinding factor in the integers mod this n, and it exponentiates this to that e from the RSA, from the RSA setup, which is the same as encrypting it to this thing that you think of as a signing key, and then you multiply that by this full domain hash f. So you have this thing that you've encrypted to the key, and you multiply it by this thing that you want signed, and you send that to the exchange. Okay, so in pictures again, basically you make yourself a red number b, and you use to lock the planchette into an envelope that you can only open kind of with this b value, and otherwise I can send this envelope to somebody and they won't know what is in there. So they can't see in particular what the serial number of that coin is, because that's what I need to hide. Yeah, so now on the exchanges side what they do, so they receive this blinded planchette and what they want to do, this f' from the previous slide, and they also receive an authorization to take some money out of the balance that the user has given them, and so then what they do is they run the ordinary RSA signature algorithm which consists of just taking this f' and exponentiating it to d. And if you think about what that does in terms of the form of f', f' was f times b to the e, then d distributes over it, so you end up with just f to the d times b to the e times d. Oregon, put it more simply, you apply the hammer to the envelope without knowing what's in there and send it back. So on the user side when they get back this s' which had the form f to the d times b to the e times d, well b to the e times d is just b, so they can multiply it by b inverse and they get back a signature of the original guy. So this is how blind signatures work, it was David Chum that came up with this, it's 30 years old. It's exploiting the kind of homomorphic properties of RSA that we usually try and hide and usually try and avoid, and the only delicate parts of this are essentially how to preserve this homomorphic property and not create some other kind of catastrophes, and that was why we had that FDH back in the beginning, but that's another thing. Anyway, so the main thing is at this point the wallet has the coin and you saw this happening in the demo a bunch of times because 1980 is a bunch of coins in our case. Now on the web in the demo, the steps of course you have to authenticate yourself to your bank, tell the bank, send the money to the payment service provider, the payment service provider says, okay well this is my fee structure, how many coins do you want, you authorize the transaction with your PIN, TAN check and eventually you get your coins. So this is just the overall diagram for that interaction. Now the next step is of course to go shopping. So the first step is the usual thing, you build yourself some shopping cart at some shop and somehow agree with the merchant on what you might want to buy. Now at the time when you do the checkout, the merchant has to say well what payment method do you want. We offer two ways of doing this nicely. One you can with JavaScript detect that the TALA wallet is present. Basically the TALA wallet exposes one bit of information to the website namely I'm there or not. So in terms of fingerprinting it adds one bit to your profile unless of course TALA becomes universal which we all hope. Second possibility if you have JavaScript disabled all of the TALA payments work still with JavaScript disabled and you can still do something there because we have a CSS tag that you can set or not set to show or hide elements on the web page depending on the TALA wallet being present. So the TALA payment process works completely without JavaScript but of course you might do more fancy interactive stuff if JavaScript is there using this method. Then when you've decided okay the user should pay with TALA what you do is you send a 402 payment required HTTP status back to the browser. Who knew about 402? It's ancient right? And the only thing you have to do basically you have to add additional header XTALA contract URL which is an address where the wallet can obtain the contract in JSON format. Basically saying this is what you should pay for. And then the body you can do whatever you want to do in case something goes wrong like the TALA wallet isn't really there because you fail to detect it properly or somebody just directly access that web page and maybe you show your normal non-TALA payment process there. The contract itself looks like this basically a bunch of JSON where you specify things like which payments are available to us providers are you willing to deal with what fees are you willing to cover for the customer how much is he supposed to pay how long is the offer valid what is he buying all of these basic things are defined in the contract. Anyway on the cryptographic side once we have this proposal to do this the contract of course has to include a signature saying this is what the merchant offered me. So we have the proposal D here that's the JSON and we're going to sign it merchant key that we saw earlier that we did second in the list of keys and you sign it and send that to the wallet, right? All right so when the wallet receives this proposal which is signed by a merchant and the user actually clicks this pay button what happens is the wallet will send back the three things so it'll send back the signature S that the exchange gave it that it obtained from the S prime the exchange gave it on this big C and so what this signature says is that big C is a coin that represents five euros and then it'll use big C to sign this contract that the exchange gave it Now of course it's possible that one coin isn't enough to pay for a contract and then you just do it with a bunch of coins until they end up to the total value of the contract Then what does the merchant do? Well he basically checks is the signature correct? Yeah. If it's correct he passes down to the payment service provider the payment service again checks is the signature correct and have I seen this coin already? Has it been double spending? Has the guy tried to spend his money twice? If no, I'll accept it and tell the merchant it's all good signed the exchange If it's invalid I have to provide the old purchase as proof that it has been double spent Again here's the process in the WC3 payment interest group format you basically first negotiate what you want to buy you obtain the contract confirm that you do want to pay to the merchant who sends it to the payment service provider the payment service provider confirms it you tell the wallet, yep contract went through, by the way get your product, your business logic, your confirmation page here and then the wallet goes to that confirmation page again you've seen it happen Now this one little problem with this setup that we've described so far which is what if I want to buy something big not the 10 cent thing but maybe something for 100 euros now if I have coins and I want to be able to pay things for 1 cent and things for 100 euros I don't want to end up doing 10,000 transactions of 1 cent for a 100 euro transaction that would even with this system take too long because you have to do 10,000 signatures now of course I can give out different denominations 1 cent, 2 cent, 4 cent, 8 cent and so on but it's still of course a puzzle that I might have whatever a 5 euro coin but I want to buy something for 3 euros and I shouldn't tell the user well you have more money than what you want to buy but you don't have exact change so we can't handle it so how do we deal with giving change that's basically the main things that we improved over the original DigiCash now in giving change we have two key requirements so first of all we need the change to be when you obtain change whatever change the user obtains it needs to be unlinkable to this transaction because perhaps they like gave out their real name or their address or something like this in this transaction and so we don't want the coins that they get back from it to be linkable to it and we also want to maintain that it's tax this taxability property which we got sort of from the way the blind signature scheme works okay the key idea is basically when I sign a contract as a coin say I sign a contract over 3 euros with a 5 euro coin I say don't give the merchant the full 5 euros only give him 3 which means the exchange knows that on this coin there's 2 euros left and then I can later go to the exchange and kind of double spend the coin saying please give me change for the 2 euros that are remaining on that coin and then I get 2 additional say 1 euro coins right and effectively now the 5 euro coin is completely burned and that's good now of course there's a problem with that but let's first give you a bit more background so just this is it's hard to know how much crypto people are in the audience so this is what a Diffie-Hellman key exchange looks like so we have 2 parties and in the classical Diffie-Hellman there's 2 parties but whatever in whatever setting there's 2 private keys a C and a T and these are scalars for some elliptic curve and we multiply those by the generators of the curves and then we come up with big C and big T which are the points on the curves so these are the public keys and now this curve is an Abelian group which means that when I the order in which I add things doesn't matter so what I can do is I can take and I can take and I can multiply this little C the guy who knows the little C can multiply T by itself and I can add T to itself C times which is the same as C times T times G and this is Abelian so we end up with T times C times I can reverse the order of these 2 guys and that is the same as adding this big C to itself T many times so this is how Diffie-Hellman key exchange works if you want to have a simple idea just think of it as a lock with 2 keys if you have either of the 2 keys you can open it if you have both it's of course also awesome alright so here's our sort of strongman solution to this which we sort of mentioned already so we have a we have this partially spent coin what we want to do is we want to pull out a new key a new coin from the residual balance on that so what we're going to do is we compute this new coins public key and we pick a random blinding factor and from so we take again we take this FDH this hash of the new coin and we run through the ordinary blind signature algorithm from it and we request we request except instead of asking that the value be funded from some user's account we ask that it be funded from the residual value of some partially spent coin now the big problem was that I said I can't show that C new the new key right that is coming out of this process pretty much looks like the previous withdrawal process is actually owned by the same person so I could say okay I had 100 euro coin I want to pay him so what I'm going to do is I'm going to tell the exchange give me change for 99 euros and he creates the C new for the new coins which means he will own them only he has the private key and I signed the change request with my old key and I transferred the value to him he doesn't have to trust me he knows he has the private keys he generated them he never disclosed them to me he gets the signatures from the exchange so he knows he now has valid coins and he had this as income and the system thinks I got change right so that's what we have to prevent we have to make sure that the owner of C new is the same as the owner of C old but because we want to make sure that transactions are unthinkable we have to at the same time make sure that nobody else knows that this public key C new has a relationship to the public key C old right so keep them unlinkable but make sure they're owned by the same person is the idea all right so to do this okay so what will this so to do this we're going to use a a Diffie-Helman key exchange to derive the news the C new and the B new so okay so what do we do we we have our C old that's partially spent we now instead of creating the C new what we do is we create this little T which is also an elliptic curve scalar but and we compute a public key that corresponds to it and we compute this X which is the result of this Diffie-Helman key exchange and we run two key derivation functions on it of which give us a C new and a B new and then from C new we we again compute the key the the public key and we create this hash and we we recall and we blind it with the B and we request that we request that the exchange signs this that should be very confused here certainly because from the exchange perspective this year and what we did before we told you is wrong looks the same right both cases I get this envelope that I don't know what's in there so how do I know that Jeff how do I know that this process was followed the answer is we do it three times so we make up three of these T these T1 T2 T3 we do each of them getting a different Diffie-Helman key exchange result with the C old and we send all of them to the exchange and but then I can just cheat you three times well we're not going to give you three coins for the value of it only going to give you one and so the exchange picks one of these values that it picks one one two or three and what we do is we send back we send back the we send back the user is required to send back this private key for the big T for the other for the others and then the exchange can run through these derivations and check that for the other two that it didn't pick the user did the derivation correctly and if they did then they can run through then they can finish the protocol but that means I can cheat you one out of three times successfully just by guessing isn't that not quite cryptographic security Jeff? one in three times means that your tax rate will have to be more than 66% to be able to do any tax evasion with this so if my tax rate is 70% then you do it four times 80% five times the number of times I have to do this in the cut and choose protocol for same tax rates okay so I've done this correctly you've checked this and then I get my coin I've proven that I've done this correctly now at this point I could have still run this with the person who wants to invade their taxes it can still be that all of these transfer private keys were known to somebody else so I got the coin but I have to now still make sure that the new coin is owned by the same person so what the exchange does it says okay if somebody gives me the old coins public key I'm going to also hand out the envelope and the transfer public key it's just a little you know exchange volunteering some information that's usually pretty harmless and if I'm the one who owns the old coin I have the private key of the old coin I can also do the Diffie Helman with the transfer public key and I can also derive the new coin's private key and the blinding factor and can open the envelope so this basically means that the owner of the old coin has kind of a back door into the Diffie Helman and can also reconstruct the private key of the new coin this way and we know from the cut and choose that it was constructed properly which means that now if there were two parties both have all the private keys and signatures which means we've reduced this possibility of a transfer of money to this case where we're sharing private keys which we could have just done directly we're back in the situation where we trust each other in terms of who can spend it alright okay so we have this we so the customer asks the exchange to convert the new coin to the old key the protocol ensures the the new coins via this last step the protocol ensures that the coins can always be recovered by the old from the old ones and this implies that the new coins are in some sense owned by the same entity as they owned the old ones if where ownership is sort of determined by this possession of the key or the ability to get the key so we can use this protocol to give change we can also use it to give refunds basically if the merchant signs give the money back to the customer add it back to the balance of the coin the customer refreshes the coin and he has change has a refund if we have to expire coins we can basically say this coin would expire into years if you want to detect that it's about to expire it just runs the refresh protocol, gets a new coin and we can forget about the old keys don't have to keep an ever growing ledger like in bitcoin and of course if the protocol has an occurrence in a board situation where the network goes down and they need to remember I can also just say okay the merchant the transaction didn't complete but I can back out by running the refresh protocol and have my coin back in a new state that is fresh and unthinkable to the board of transaction so to compare the system with other things as you can see compared to cash you know we don't work offline we only work online the transaction costs are extremely low payments are extremely fast we do support taxation because income is very easily visible to the state we have anonymity for whoever buys something but no privacy for whoever receives money we of course would claim this is the most secure system of all of them we don't have conversion here saying you don't have to convert right with bitcoin you have to create a new currency here you can pay in euros, you can pay in dollars you don't add a conversion risk for the user or a conversion cost and of course it's a free software project part of GNU if you're interested we have all sorts of information lots of documentation and the source code we have relatively good documentation on the specifications for the protocols and things like this I'm not sure what it is I should mention this is a GNU package that is going commercial so we are also looking to build the business around it so if you happen to have a couple of million euros lying around please talk to us or run a bank, if you run a bank that's almost more useful a bank will be better, yes to conclude we have the choice, we can suffer mass surveillance from the credit card oligopolies or the big payment providers like Google Apple Pay and so on we can as a society engage in an arms race with unregulated blockchains and have our ransomware extort us or of course we can enjoy the benefits of cash like in India where they sometimes cash even for offline payments or you can help us build taller and establish a payment system that balances the social goals of transparency and privacy thank you I'm sorry any questions so Serenity is taking over my job so come on do you have any questions yes I would like to ask do you so the original Trump's e-scash has this nice property of if you spend twice the same coin that your anonymity gets revoked so there's a big problem with those schemes there's a huge literature on sort of expanding on those schemes the reason for doing that is to allow offline spending and specifically to allow the merchant to be offline so in our scheme the user can be offline much of the time the merchant needs to be online the reason we don't want to do anything like that is because if you think about just managing the system it's almost impossible to imagine that double spending will never happen like restoring from back up there's all kinds of failure modes where double spending is just going to happen by mistake so if you have that kind of system where you de-anonymize the user it's very the privacy properties for the user at that point are very hit or miss so it's really not acceptable if you want to say your system is really private so it's dangerous for privacy that's one thing but the other thing is from the business point of view if you double spend a coin you can also billion spend the same coin and now you're only a billion dollars if you double spend it now I have to go after you and recover the billion dollars that you obviously don't have so it's not like being able to de-anonymize you give me an easy way as the operator to get my money back so it's a huge business risk to de-anonymize and then go after the people and that cost we just don't want to pay one of the advantages of something like taller is because acting as a thin layer on top of a set of payments it doesn't it doesn't incur there's nothing like all of the nasty collection stuff that has to go on in a credit card and it's those things that initially made credit cards very expensive so we avoid all that and we don't have that initial that cost so this already seems really compelling for the retail scenarios where I've used Bitcoin so far it seems like it would be better for me but I do like one or two charge backs a year I like almost take a Kali in it it's my favorite thing about credit cards so would you come closer to the mic? if I had to choose between being anonymous and being able to do a charge back if the merchants screwed me and have the credit cards company like negotiate with me I'm not sure which one I'd pick I wonder if you thought about the charge back path and if you could factor it out of the crypto it sounds like I don't do as many charge backs as you do but I have done them at a few points in my life and there's a very nice feeling of I'm in charge when you do that the there is a system for refunding and the merchant has to choose to refund in the scheme that we have and the so the mechanics of doing a refund work and in fact the refunds can be done anonymously so the customer can get their money back without having to reveal anything about their identity in the scheme the way we envision it working is that the merchant would have to authorize the refund because there's simply not money in the system otherwise it's not impossible to imagine that the exchange could do some sort of arbitration there but now you're asking the exchange to do this arbitration process and realistically all of the schemes that people are seriously talking about deploying that's what they're getting rid of is this arbitration process Apple Pay all of these things it's that the 3D secure all of these things the whole point is to reduce the customer's ability to object so that there's less risk for the merchant there the good thing is you have cryptographic proof of the operation and if you want to have this kind of arbitration process you could of course say I'm not going to pay the merchant directly but some arbitration process operator that is going to hold the funds in SQ until I decide it's all good so that would be a separate service just if you really need this arbitration at the extra cost it imposes then buy it and add it on top as an extra layer I guess you're saying that in the architecture you proposed the exchange could unilaterally decide to do a refund no you have the signatures it can give you back the money it can put the money back on the coin you get the signature from the merchant that authorizes the refund and you have no way of knowing who is the right customer but ultimately it's the exchange who decides what the money is on the coin the exchange shouldn't be an arbitration if you want an arbitration service build it separately would be my answer question hello hello my name is Pavel I have a bit of ideological question I'm crypto anarchist so it means that I believe that cryptocurrencies are here just to provide us completely new kind of personal and economical freedom and this is not only me but Satoshi thought the similar idea I mean the control not only over corporation but even the government so when I first heard about Anonymous Taxable Money it sounded for me like a big joke but so my question is you have a lot of different competitive cryptocurrencies and my question is how do you want to persuade people to use a friendly cryptocurrency without coercion this is not a cryptocurrency this is a transaction system ok but anyway so my question is how people will use the system without law or without forcing people to use the system people use credit cards without law people use PayPal without law why shouldn't they use Tala without a law it has advantages for them in terms of privacy I should point out when we say that it's taxable what we're doing is we're converting we're saying that our system does not reduce the government's ability to monitor transactions relative to what the underlying transaction system provides if you run Tala on top of Zcash you will have very cheap transactions and nothing will be traceable but for example if you run on top of SEPA payments it will have the same properties as SEPA payments in terms of taxation if you run on top of Zcash it will have the same properties as Zcash we have to stop sorry to interrupt you no more? we'll be here for the rest of the day please come find us and we'll be happy to answer your questions thank you