 Hi everyone, thanks Brent for the intro. I'm Prathish and Here to present our work on decentralized anonymous micro payments as Brent said this is joint work with my advisor Alessandro Matt Jin Cheng Peihan and Ian Okay So digital payments are a solved problem, right the customer sends along some money to the merchant The merchant keeps an amount for themselves Sends along a tiny bit to the payment network and everybody's happy But this model breaks down when the transaction amount is much smaller than the transaction fee itself Supporting such small payments is important for a lot of applications. However, for example consider that When I visit a web page, I don't want any ads So I give the website owner some money and get back at free web page since most ad impressions and clicks are worth Fractions of a cent what I want to pay is fractions of a cent But since transaction fees are often on the order of tens of cents, this doesn't make any sense There's a risk history and cryptography of constructing such micro payment schemes and lots of esteemed names have worked on this problem But we still don't have any widespread deployments that involve multiple merchants and many many customers. I Think a potential reason for this is that all these prior schemes they require a central mediator to instantiate the micro payments And this is an issue because now your customer and merchant need to have Complex financial relations with this middleman and they have to meet regulations and many other reasons So let's look at what's happening in the decentralized world here the cryptocurrency Bitcoin Has seen widespread adoption across the globe and I think one reason for this is that to transfer money to somebody I don't need to even have met them before I don't need to establish relations with them Don't have to meet any regulations. I just signed a message and put it on some global ledger in more detail Let's say Alice wants to send to Bob say four point three dollars All she does is sign this message from a to b amount four point three and Put the message on the signature on a global ledger that's maintained by the nodes in the Bitcoin network so can we use Bitcoin for micro payments directly and The answer is not quite because you run into a few problems The first is that even the bitcoins decentralized and there's no actual middleman taking a cut You still suffer from the issue of high transaction fees These are roughly on the order of credit card network transaction fees today and it's projected that as Bitcoin tries to scale These fees will only get higher The second issue is that each transaction takes a long time to confirm in Bitcoin on the order of ten minutes and The recommendation is actually to wait a more like an hour For your transaction to be confirmed This is particularly bad for micro payment applications because nobody wants to wait an hour for their web page to load a Third issue is from like a privacy perspective Where the issue is that Bitcoin doesn't offer any strong anonymity guarantees in particular the sender receiver and Transaction amount are all public for every transaction This has two consequences The first is that you don't have fungibility and this has nothing to do with mushrooms but just means that Even if I have two coins of the same denomination, they might not be treated equally depending on their transaction history The second or more obvious issue is that of privacy and this is particularly bad for micro payment applications For instance, you don't want your browser history to be available for everybody in the world to see on this global ledger So two separate works have dealt with these two classes of problems The first is a work by passing a lot at CCS a couple of years ago And they use the technique of probabilistic payments, which we'll dive into later to implement micro payments for Bitcoin These this technique solves both the first two problems by amortizing a transaction fee and confirmation time across Many payments which don't hit the ledger To solve the problem of anonymity Zero cash was proposed at Oakland roughly three years ago And this is an anonymous Bitcoin like currency which hides all the information about the sender receiver and Transaction amount for every transaction. So the ledger looks opaque to some outside observer Okay So what we want in some sense is micro payments that combine these two worlds In more detail, we want micro payments that are decentralized for the ease of deployment property Anonymous for fungibility and privacy reasons and finally offline for the fast response that is useful for micro payment applications What we achieve is a definition of a crypto primitive that has these properties via via the idle functionality a Construction for this definition under standard cryptographic assumptions like nizzix and commitment schemes and To realize this construction we use two primary tools The first is a fractional message transfer protocol, which is in some sense an analog of OT specialized to our setting prior constructions of FMT schemes bundle under this umbrella called translucent crypto and As we'll see later in our setting we can't prevent all double spending trip graphically So we have to rely on the rationality of The agents in the system and so we provide a tight characterization of double spending Okay So the main building block of both our construction and the passenger lot Paper is that of probabilistic payments in this model when Alice wants to pay Bob a cent She doesn't give him a cent for every transaction, but what she does is she takes a dollar and then interacts with Bob in such a way that Most of the time She gets to keep the dollar and no transaction occurs. So she doesn't have to talk to the ledger or payment network And we call this a null payment But like one out of every hundred trials Bob gets a dollar So a transaction occurs either via the ledger or some payment network and we call this a macro payment Why do probabilistic payments lead to micro payments? the idea is that These 99 null payments they amortize the transaction fee and the cost of using the payment network so your transaction fee and Your confirmation time are both amortized over your 99 null payments, okay So let's dive in a bit more to see how passenger lot use Implement probabilistic payments over Bitcoin the key idea is to take a coin flipping protocol and combine that with Bitcoin in somewhere in more detail When Alice and Bob wanted transact what Alice does is she escrow some value V on the ledger They engage in a coin flipping protocol if Alice wins she gets to reuse the escrow for further Trials of this for the executions of this protocol But but if Bob wins, it's a macro payment and he gets to redeem the value and keep it for himself The key thing to note here is that Alice escrow is the value only once and she gets to reuse this escrow again And again until a macro payment occurs and Bob redeems it. So this is where the amortization property comes from Okay, so your cash is a bit more Involved but at the high level the idea is to use zero knowledge proofs And combine them a bit coin to hide information about transactions In more detail now that zero cash leiser consists not of messages and signatures but serial numbers of spent coins commitment to new coins and Zero knowledge proofs that link the two So let's say Alice owns a coin C1 that she received in some past transaction Its commitment appears on the ledger as you can see cm1 and she wants to transfer the value in this coin to Bob What she does is she takes her secret key and combines it with the coin to generate the serial number for C1 Next she takes Bob's public key and uses that to derive a commitment for a new coin C3 and corresponding commitment cm3 Finally she creates a zero knowledge proof that asserts that the first two steps that performed correctly and that The value in the input and output is a maintain. They're not having arbitrary inflation Okay, she publishes a Transaction consisting of the old serial number the new coins commitment and the proof to the ledger The reason why this gives any security is that? Only Alice can derive the serial number for her coin Anybody else looking at the ledger can't link cm1 with SN1 because they don't have Alice's secret key Similarly, that's the reason why Alice can't spend Bob's coin that she creates for him Because she doesn't know his secret key and therefore can't generate his serial number. Okay So the naive idea would be to just take the passenger last protocol and replace Bitcoin with zero cash So now Alice escrow is her value not in a Bitcoin transaction, but in a zero cash transaction They engage in the coin flip as before if Alice wins she keeps the escrow, but if Bob wins he gets to redeem it This doesn't work for two ish for two reasons You don't have anonymity and the customer can double-spend So let's dive into each issue in the first case What we see is that when Alice She since she wants to amortize the transaction fees. She has to reuse the escrow every time But Bob wants to be convinced that whenever Alice is transacting with him She's using a valid escrow so he needs to learn in some sense the serial number of the escrow coin But this creates an issue because let's say Alice transacts with Bob. It's a null payment, but Bob still learns the serial number of the coin Next she goes to say some of the merchant Carol interacts with her and this time it's a macro payment So Carol gets the serial number and is able to append the transaction to the ledger Bob now sees the ledger and sees oh a coin that somebody tried to use with me has now been spent This so that Alice doesn't have the strong guarantee of anonymity that we had in zero cash There are other attacks which lead to even further loss of privacy. So this this naive idea doesn't quite work What we do to solve this is to make the serial number translucent So what this means is that now Alice instead of Creating a transaction and appending to the ledger just commits to it and sends along the commitment and Approved that the commitment was formed correctly and the transaction inside is valid at the time of creation Then they engage in some probabilistic opening protocol that opens the commitment only with some fixed probability What we want is that with probability one minus P the commitment remains completely hidden to Bob, but with probability P He's able to open it and get out the transaction and redeem it To achieve this we create this fractional message transfer protocol which has two properties fractional hiding ensures that with probability one minus P Bob learns nothing about what's inside the message and Fractional binding ensures that Alice cannot bias the probability that the commitment is opened it always has to be P So in some sense what Alice wants is exactly Fractional hiding and what Bob wants is exact is exactly fractional binding Okay, we realize the construction of this I'm using under the assumption of DDH and then the random oracle model Okay So that solves the issue of malicious merchants that want to de-anonymize customers, but what about malicious customers? so let's say we have a malicious Alice and The attack that she can perform is she can use the same coin with multiple merchants at the same time so let's say she's transacting with these four merchants and Two of them became my macro payments That's a Carol gets her transaction onto the ledger first and Bob being a bit slow Looses out so now Bob doesn't have can't redeem the Transaction the macro payment and Alice has gained utility at his expense In our setting there's no way to prevent this double-spending attack cryptographically because there's no global immediate consensus among The merchants about what is and isn't a valid payment at any given time Consensus only comes along at these 10 minute blocks in Bitcoin Whereas here we want this immediate confirmation, so we can't wait for these 10 minutes So to solve this we disincentivize customers from cheating by having them penalized if they cheat The idea is that now before any transactions Alice creates a separate deposit coin and this is put on the ledger And then she wants to interact with Bob What she does is commits not only to the transaction as before but also a secret share of the deposits serial number The proof now also proves that the secret shares formed correctly and the deposit is valid at the time of the transaction They do the probabilistic opening as before and if Bob is able to open the commitment He gets the transaction and also the secret share and he posts both of these to the ledger Why does this help us and The idea is pretty simple. Let's say Alice is transacting with Bob. It's a macro payment He gets the transaction and the secret share and he posted to the ledger Let's say now that Alice cheats and she's interacting with either Bob or perhaps with another merchant and Becomes a macro payment again. This other merchant now gets a different secret share of the serial number and is able to recover this Of the recover the serial number and append it to the ledger at this point Alice's deposit is revoked and she has some negative utility Okay, so so far we've used probabilistic opening and deposits to prevent linkability and double spending But are we done and the answer is not quite we're still lacking in terms of both functionality and the security analysis What happens when the customer they're saying, okay, I'm done with the system. I want to leave it Can they withdraw the deposit? Ideally you want them to be able to withdraw the deposit because otherwise the deposit money is some sunk cost for them And they're incentivized to constantly keep cheating to recover as much as they can But if you allow them to recover the deposit what they can do is withdraw it just before the deposit is revoked and This is clear an issue because it's defeated the entire purpose of asking We run into similar issues when dealing with merchant or boats and they try to frame the customer for double spending There's some similar issues arise So this is from a functionality perspective But we haven't even talked about What the value of the deposit should be if it's unbounded then Again, our system is completely unusable because nobody will sign up to do to for this mic micropayment scheme So we solve both of these issues We extend zero cash with some extra features to allow this this withdrawal deposit feature And we provide a tight economic analysis of how much A customer can gain by double spending and The main idea is that basically the deposit value has to be equal to the financial activity that you want to conduct in the system Okay, so to conclude The key idea from our paper is that we used this translucent crypto plus game theory to construct decentralized anonymous micropayments Our game theoretic analysis is applicable not only to our setting but also To others for example the pass and shut out paper They had they had the idea of deposits, but they didn't specify what the value should be it's also applicable to probabilistic smart contracts and application suggested by passing a lot and Finally as I said before we extended the interface of zero cash to be more expressive and programmable and we're already able to use this Added programmability and some new applications that are working on right now Thank you any questions So could you prove from a game theoretical point of view that the best strategy is to be honest? Yeah, I think so in our case The idea is that when you double spend you lose all your money Whatever money that you could have gained from double spending so it makes no sense to double spend So what are the pros and cons versus payment channels such as lightning network? So I think in payment channels you are limited to Specifically the merchants that are in your network right and also I think there was this paper bolt By Ian and Matt that constructed these anonymous female channels and they had not the perfect anonymity that we gain in in our setting There's basically no link between Even these now payments between too much consecutive now payments between the same customer and the same merchant Yeah, so I think the paper has and then a comparison with payment channels and I think we have stronger anonymity guarantees I think there's a question So how do you prevent? The user from giving the same secret share to all the merchants So we have waited to drive the secret share using some like the public key of the Some cycle we have a way to make it unique to per merchant and per instance of the protocol too. Yeah There's a question And some per instance specific randomness I have a question Can you tell me if I understand your solution correctly? And I think that the the payment channel used in lighting network is like kind of a One-to-one channel. I think your solution once the deposit is done. I think it's a one-to-old Yeah, you can use the deposit once and then you can transact with However many merchants that deposit value supports It's not limited to say ten merchants. You can do a Specific set of ten merchants. You can transact with any set of ten merchants and another question is that Do you think this probability is the payment is realistic in real applications because The entire protocol is like not very practical at the moment, but I Think I mean I don't think there's been deployments of probabilistic payments before directly, but I think if you adjusted for certain applications, it might be useful