 My starting point tonight is that people like to buy all sort of stuff and nowadays people like to buy stuff with Bitcoin more and more This is problematic, especially in the Bitcoin setting because they might be buying things from parties that cannot trust So there should be a system that guarantees people who purchase That their payment is going through only if they receive what they want and vice versa for the sellers Someone a few years ago notice this market need and devise a solution for this and The system was very successful for a long time and was selling all sort of stuff until it was shut down Today, however, I'm gonna start from different assumptions I want to tell you how we can have the sort of fair exchange fair payments on Bitcoin without Explosive escrow without explicit trusty party and we're gonna talk about digital goods songs theorems or Solutions for Sudoku's so let's start from how do you buy a Sudoku solution with Bitcoin in a fair manner? and there is an official solution sort of from the Bitcoin community that was presented in financial crypto in 2016 and sort of See this is a fair exchange problem and uses the blockchain as the trusted party in this context And it will work in a following manner So the seller will take the Sudoku solution and will encrypt it send it to you And then also prove to you in zero knowledge That the sever text actually contains the proof now you're convinced that this thing you got contains a Sudoku solution All you need is the key You could make a transaction that says blockchain. Please do pay this seller as soon as you provide the key Unfortunately in the Bitcoin context, this is too complex for the script for the scripting language in the Bitcoin So we have to do something a little different but on those lines in addition to what the seller sold you should also give you a show of the key and Extend the proof to say this key is related in such and such manner and now you can say blockchain Pay the seller if he provides the pre-image of this string. I know it's gonna work The seller just sends the key and everybody's happy and The guy can use the transaction this point to sell Let's look at one thing though. The proof over there is that zero knowledge snark in this Proposition from the Bitcoin committee that means that somewhere there should be a common reference string Generated by trusted party who generates the string in this context it's the buyer and This sounds sort of problematic the intuition from the authors was that the seller could cheat and the buyer If we're generating it won't break at zero knowledge There's been discussion back and forth and wanted to settle the matter So there is an attack One can do on Leibsner so that one can generate specifically malicious CRS receive a proof and Learn and get part of the witness from the proof in Leibsner So I can learn part of the Sudoku solution say one cell somewhere without pay you So moral of the story Look at the CRS get it from a trusted party. Don't do it just as it is another question I want to tell you about is what can't you buy with this protocol? Digital goods. Yes, but I'm gonna submit to you that there's things I'm gonna call services that you cannot buy What do you mean with services? Think of a cloud setting. So for example, you want to Pay your cloud every month if you at the end of the month you check that they're actually storing your data Properly, or they're actually storing your data in an encrypted manner We have protocols to check these two properties But you can think of all sorts of auditing context. You find my taxes correctly. Did you submit my homework? Why doesn't the old protocol work? So let's take the file the filing taxes example, and let's assume a trusted CRS The seller in the old protocol would send you ciphertext of a witness some evidence of the fact that The taxes were filed. So for example a ship you received and whatnot Then it will prove to you that this ciphertext contains this evidence But now you have proof that the ciphertext contains proof That the service was done You're done. You don't that's all you need to know. You just walk away so In other words, we design and implemented the protocol the sources proud We call them service contingent service payments and we stumble upon another thing in that context We needed a shot circuit implementation and we built An implementation of shot 156. This seems to be the most efficient Available to the best of our knowledge the previous best implementation was by Bristol University from Nigel's smart slot So if you're interested in this or any of the things I talked about you can check out at these links over here Thank you very much