 Okay, hello. I'll start again. So, yeah, so for the past few months I've been doing some privacy research. So yeah, so one of my first ideas basically was to implement a sort of ring signature based mixing contract on Ethereum. That's just like a simple proof of concept of privacy. So yeah, so basically a ring signature is, so normally when you sign a transaction digitally it's signed by one public key. So you know that the signature came from this person. With a ring signature, a signature is created using a group of keys. And then only one member of the group actually creates the signature. But then when the signature is informed you can't tell from the outside who signed it. So basically, if you decide a transaction this way instead of with just your own key, you'd be able to like plausibly deny that you were involved in the transaction. This is part of the way the narrow works. So, yeah, so once we have that we can implement a mixing contract using these sort of alternatives. So the idea of the mixing contract, I have rough code for this right now but it hasn't been tested. So the rough idea now is that a user would submit a public key to the contract as well as a deposit. The deposit is a fixed amount of either as well as fixed ring size currently in the contract. It's probably going to be set to like 11 because that's what scenario uses. Maybe 12 just because it's an error. But so that after that amount of people has submitted a public key and deposit to the contract, then we're able to pull that list of public keys from the contract and create a ring signature from that. So the initial public key that's submitted, it could be that the receiver of the transaction has the corresponding private key. So you would perhaps talk to the receiver beforehand. There's a few ways that this could go. This is the one way. So you can plausibly talk to the receiver beforehand and just be like, hey, it seems like a public key. They send you a public key. You send this to the contract with some ether. Then once the contract has been filled with public keys, the recipient now has the private key of one of the keys in the ring. They would now create the signature signing off basically saying send me the ether that was deposited into this contract. And then every recipient for every sender would be able to do the same thing. Or alternatively, the sender would know the private key and then they would create the signature and then know if either should be in that they could withdraw from the contract. So yeah, that's the basic idea of how it works. I'm going to look at some kind of after talk about some things. So yeah, so the first issue why this hasn't really been implemented yet is because the ring signature is super large. So you can't actually store a ring signature with more than around five members on a contract right now without running out of gas. So you can't perform the verification that we needed to implement this contract with enough ring with a larger ring size that would be actually useful because if the ring is too small, it's easy to sort of backtrace and see, like sometimes backtrace and see other. So a possible solution. The first one was to just create a pre-demo contract that would verify our signature and then kind of actually maybe push the sub-stream. So yeah, I put it into that and it seems to work so far, which is cool. But for top to work, it might have to be pushed up to take a very long time. So yeah, so another solution I'm thinking of is to just use the BN 256 pre-demo files and hopefully that will reduce the gas costs. So yeah, so create a signature so you can't create a signature on-chain. So you have to sign an off-chain and then do all the verification on-chain in the contract and as well as how to protect double-spends. So similarly to having an error done, you would prevent double-spends by using linkable ring signatures. So this is a variation on the original ring signature for algorithm. So linkable ring signatures basically adds another key image to the signature. So the key image is an off-the-chain image of the person who actually signed it. So you can't actually tell who signed it from the key image but you can tell if two signatures have the same key image that they were signed by the same person. So basically this will prevent a double-spend by saying if you're trying to submit a signature to the contract again but you only submit one deposit, then like, no, you can't do it. So some extensions to this that I was thinking of. So I think one of the really cool is just generalized transaction privacy. So right now we think of mixing it to think of like Ether or some sort of monetary value but with Ethereum you could extend this to not just the Ether value transaction but to the call data, since what's happening in the mixer is basically that you have like a transaction and then this transaction gets signed as a ring and like it's submitted and you would fit instead of the value in the transaction you could put some stuff in the call data and have this execute you. Yes, that would be really cool. But that would be an issue if you think it's for us, that's a good thing. So, yeah, so this would allow private contract to come to calls or private contract to come to us. Yes, and also probably one thing, because as I mentioned initially the contract right now needs a fixed Ether denomination amount because basically if you allow people to just send whatever amount of Ether they want to be contracted they would be able to link the side of the recipient. So value-winding would be like pretty cool I think. So I was thinking, I would just start making of this so basically using something similar to how an option transaction works so just using commitments to allow people instead of the actual transaction but then this would somehow need people to keep track of all their values instead of all the chain of questions. Yeah, this is some research. So, yeah, that's basically it. If you want to check out the code I've written so far it's all there. I have mixing contracts and I go with a presentation of my course and bring signatures. See ya. Yeah. Forgive me, forgive me for how superficial this question is. But as an end user who cares about privacy how would you compare and contrast ring signatures with something like a CK Snarks? Because I know a CK Snarks I think like only 15% of exchanges actually implement CK Snarks so what is like the pros and cons to ring signature as a CK Snarks? Thank you. Okay, so the CK Snarks works by basically hiding, you prove that you have some sort of hidden value to a contract or whatever. So this doesn't really hide the link between a sender or a sypian of a transaction. It's used for things like hiding value, could be used for hiding a sender or sypian but it would be a bit more complicated than that. So yeah. Sorry, I'm also really tired right now. I'd like to go off in like six hours. Yeah. What do you think in terms of exchange of this use? I think it's like as an end user. Yeah, yeah, yeah. So we know that the basis of how a ring signature works is like a mixture of the different keys and no different CK Snarks is using like zero nulls proofs. So you know how you see two things work. As an end user, how do you choose which would be best for you in which circumstance? Let's see. Okay. It really has a good both quite powerful, you like when I was based off more of like what I'm describing like a ring signature based on my social interaction based survey and then CK Snarks and like they're both secure I would say. So yeah, as an end user it's really, I believe the CK Snarks are larger. I think. Yeah, yeah. Yeah, it's really, it's really up to you. To be honest, I think as long as they're both valid and transparent, they should be fine. Yeah. Any other questions? Do we have a small question? Hey, thanks for your talk. Just an observation you mentioned about the transactions, if it will become a code data and who is going to pay for the gas, etc. Yeah. Just an idea is just a meta transactions here can have in a way like just to have a layer who will pay for that one. Just like you can consider maybe like as a solution just to have a meta transaction concept into that place. Like EIP 1077 is actually describing how it can be handled. Yeah. Then in case like whoever is coming with an executable transaction can receive a return back. Okay. So we're asking about the, like if you said the pay for the gas kind of. Yeah. So yeah, I didn't think you would ask. Yeah. Like what you said, basically delegating someone else to somehow do it would probably be the best bet. Because if you just submit all your stuff to the transaction, it's pretty obvious that it's like you. So even like you probably have like a delegating person, a delegating group, just like that. And when you have to trust it, just like you want them to like do it kind of thing. Yeah.