zkSummit - ZK0x02 - P4: Private Periodic Payment Protocol - Liz Steininger (Least Authority)

Transcript

[Music] okay so lots of peas right here p4 for peas to be exact the private periodic payments protocol basically yeah reoccurring subscriptions with privacy and to introduce myself real quick I'm Liz Stein Inger from least Authority CEO and managing director and yeah so we care a lot about privacy okay yeah so least authority I'll tell you a little bit about ourselves and and why I want

to work on this but yeah so we believe that people have a right to privacy we help to we hope to do this by helping others to improve their technologies we do this through security audits helping to make sure that the the you know personal data that is being used in other people's technology is being securely held and transferred and then we also build our own secure storage product and just generally contribute to secure software's open source software that has a security aspect to it so we focus our efforts a lot on usable secure technology that it's great to have secure technology but it's even better if people can actually use it we also try to focus on privacy by design that

bringing the thoughts about privacy and protecting people's data earlier into the process of software development and we'd like to focus also on decentralized tools that are also open source so these are things that we just yeah we like to help out projects that are doing these things and we also like to do these things ourselves oh there we go so we have a problem you know this is how it starts right people have problems and then we want to solve them because of a technologist and we like to solve problems so we don't like to collect personal data because we care about privacy so we but we need to collect it for private for payments for payments processing and this is our problem and

it's pretty difficult for us to run a subscription service for secure storage and also expect accept payments and so right now we use stripe and we collect personal data basically only for the payments processing and we don't need personal data to suits to store people's data and so yeah this presents us with a really interesting problem where it's just the payments that we're struggling with and that's complicated by the fact that it's a subscription service so yeah the reason we're all here is because we think that the current financial system is outdated right cryptocurrency talking about how blockchain can also to change FinTech

this is what brings us together events like this and then we also do believe that we must defend our own privacy if we expect to have any so there's a privacy aspect here to so collecting payments through these online payment processors like stripe is pretty convenient for us but it is going against what we what we want to be doing in this world so in the script o currency world we do have to remind ourselves that privacy matters and so how do we work around this particular problem we wanted to see if we could come up with a way to accept private payments for our subscription service that also protects privacy so that brings us back to the topic of privacy by design so we thought yeah hey we need

to do privacy by design if we're thinking about solving this problem right and we have this great opportunity to disrupt the status quo to do something different to do something different and better than stripe and to incorporate privacy from the beginning of our designs and we have these grand visions of you know all of us here are working on some project or watching some projects that have grand visions of changing the world so if we want to change the world we should also think about how we want the world to be and if privacy is something we value that needs to be incorporated in the beginning we don't want all of our subscriptions to be public knowledge we don't want to leak data in the process of pain for these subscriptions and we also and we also don't want to leave things that

could be correlated with other data that could then become personal about us so a good example of how we like to think about this is HTTP and HTTPS we all built the internet with HTTP now we've just switched to HTTPS and we realize that that's better how about we do that the other way like start with HTTPS now and so that's what we are trying to think about with with how we approach this so to talk a little bit about just quickly about what we are trying to add the subscription service for is is rs4 product which is simple secure storage service I'm not trying to

do marketing or anything but it's important to understand the security principles that are behind it and how it functions because this really ties into making having private private payments be so important to this type of particular system and so it does incorporate it's it's basically capability based security and it has client-side encryption you have to have the capability to access it there's no logins there's no passwords and things like that and so we because of that we don't have any personal account information on people they're actually just isn't account information in general which is nice and so the ciphertext is stored with servers that we take care of the servers are what I

like to call stupid but they don't know what their story and they just have shards shares of of CF ciphertext and they don't know they they know enough to like put it back the client-side is what puts it back together and decrypt it and the server's know nothing about this so this is good security properties and it has good privacy properties so yeah and then we have the payments where we're using stripe really not cool so um payments by subscriptions this is important we need to do we need to accept these payments for a subscription business model and to like go over that real quick it's just that these payments need to repeat at specific intervals

these are in there then they need to be related there are many variations on how merchants would prefer to manage these subscriptions that can get kind of complicated and they want to offer a very option of various options for the plans you know maybe different periods that they need to repeat and all of that we want to try to make sure that there's not a relationship being built that could then become data that you could look at to then deduce who somebody was based on their behavior of paying the subscriptions so there's a privacy concern there too but this but but for us it really does seem that like the subscription business model is a good fit for what we're trying to do so yeah this is what we have this problem and blockchains right now most of them do

store data publicly and most cryptocurrencies have personal data in the transaction so we need cryptocurrency with privacy and you guys have heard of Z cache so so we started looking at Z cache because we know that it's got these privacy properties in the transactions that we would like the Z cache the shielded transactions and so we also as a side note for disclosure Z cache company is a sibling company of ours but yeah so we've been talking to them about this and this is just a quick rundown of what Z cache is I won't spend time on it because I think somebody else did earlier somebody from the Z cache team and they're here but yeah so this is the shield of transactions offer us a

particular type of the particular type of zero knowledge proof called ZK snarks and when the when there's a Z cash transaction there is an existing string of data that that the sender of the transaction provides the zero knowledge proof along with the encrypted transaction data which provides properties of the encrypted data cryptographically so this assures ownership over the spending key and allows for verification for the transaction is valid while preserving privacy of the transaction details and thus a clean release that's coming in a few months will also make this faster to use so we've been looking at that goal for ourselves about like how can we implement something that's actually usable around the same time as sapling

and that's usable today because um you know we want to use it now so yeah so now it's expensive to make things private and it's cheap to make things public and we need to change that one of the current yeah sorry I lost my knit place okay okay now into the difficult part of putting all the pieces together so using cryptocurrency for subscriptions this is getting into the real real problem that we have so one of the current uses of ZK shielded transactions is to have people pay prepay for subscriptions this is out there being used by first by some people

and this is this works really well for service offerings where you can just shut down the service but this doesn't work so well for us because then we're left left with a bunch of ciphertext that belongs to somebody and we're not quite sure what if they want to pay a month later or something so it puts us in a weird business situation that we wanted to see if we couldn't work around that - and this doesn't work and this also is another option would be to use them something like smart contracts for managing subscriptions but yeah the privacy problem is there - and then yeah impose another option as the post paid charging for use but this also has the same kinds of problems with as like the prepayment

and then there's issues around periodicity so basically the recurring nature of these payments we need to have this ongoing transactional relationship there and so some of the problems that we've we started looking into with this was the pre-authorization that pre-authorization cryptocurrency is like any semblance assemblance of pre-authorized payments by design so this is definitely something that we have to solve and then it would an ideally pre-authorization and also pre-authorization is bad because we ideally want to keep the power in the hands of the users and this is why cryptocurrency doesn't work like that as for data standards the cryptocurrency share no common language or protocol and

that's why some people are talking about like cross chains actions and ways to have that but especially true in this case there's no notion of billion period due date grace period late penalty and stuff that you would see in other subscription systems and using cryptocurrencies for subscriptions imposes an additional financial risk on customers and merchants about price volatility right now so we wouldn't thought how can we control for these issues in designing something and so looking at what we needed to actually design we looked at the required events for it so subscription service has to have sign up by the customers they have to do the creation and they need to check the payment status there needs to be a new

way also to be could be confirming that the payments have been made and communicating that that next payment so that reoccurrence of the payments is what needs to be there too and this this is at what we thought is the list as the MVP like the the Minimum Viable Product to have any kind of protocol that would help for reoccur in private payments so these so this is a diagram that we came up with about the sequence of events that has to happen you know looking at those things that have to happen and these are the parties involved and so we have the customer the client and our cases grid sync but this could be a client in the machine I think you guys can probably read that it says customer device and external systems and then the

wallet that you need to have to utilize e-cash in this case and the secure network tour and then the merchant would be us in the payment network again of Z cash and so this is the basically what the steps that have to come and this isn't the first part is not so interest it's kind of interesting but it's how we really make sure that this loop at the bottom happens without revealing any information that could that you could be you that any data that could be used to see any patterns that which then could tell you who the person was because you know we store we have we have other data and so if we could correlate that data we could start to figure out who somebody was and we don't want to do that so we need to make sure we do this

in a way that's anonymous along the way so yeah so you took I'll go through in some more detail so you would visit the tour based webpage and this is where the the user would go and say yep I want to sign up and they generate a code for themselves and this page doesn't have to be very fancy it really just has to generate the code and then they put the and then the code is sent back to them and then they put the code into there client and that client that code then talks to least authority and least authority server says okay great you need configuration information to connect to our network so that you can store your data so we send that Tahoe config and the first signed invoice back to them and so I'll talk a little Xin

voice contains but that's that the the data pieces that that we need to add to these transactions to know about how the subscription is going to function and how it's going to like their the the period of time and stuff and then they make a pain oh and also we want to sign it for security purposes too and so we send that signature over initially and so then they make the payment to a receiving address which we have put in in this initial send of data to their client and so they know that they need to go to their Z cash wallet and make the payment and that goes on to the Z cash network where we're monitoring the Z cash bla the blockchain the network for that payment to appear and when we see that payment appear then that's the

key for us to generate the next invoice for them and we basically just update this invoice information to reflect the the next state so your next payment do basically and that could be like any period that is defined with the data and this we serve on and in this design we said okay we can serve it on a tour based web page because this way we don't know who they are when they go visit the web page because if we put it on our website or any kind of centralized place we could get their IP address so then we could find out who they are there's other problems too so we thought this way we don't know who they are and so they just go to this address and they get the data that they need from us and so um yeah they their client then knows

to check for the invoice information on this page and then maybe serve it back to them in a nice UI or something yeah so it notifies the customer of this invoice information and that's on the client side so that that like that periodicity that's happening is on their on their device as opposed to out in the blockchain err and some centralized repository where it could be mined and so yeah then they make an ex payment when they're ready and then this can be adjusted so this is where we're thinking right now of how this could be designed and how this could work and we know that some of this could be done a little bit differently but this is something that we could actually build in the next few months actually quicker than that it's not a whole lot of work to do this but

figuring out how it works altogether is the hard part so this is the invoice data that I mentioned it needs to include a version number also payment address to receive funds so this would be the Z address that people need to pay us at and then the human facing subscription description just so they know what they're paying for subscription provider public key this is um you know so that they know who that we are who we say we are and that they're paying the right people and then the payment details and this is about the subscription so the time period of the subscription the price per that time period the maximum number of payments acceptable so if they want to pay ahead and then also payment due date and time

and this is what we think is a minimum data that we would need in order to process this so um earlier you saw some other stuff again we want to preserve privacy and we want to implement something that has a protocol that enables the customer to pay for subscriptions without intentionally or accidentally disclosing additional information to us or unnecessary and personally identifiable data to either us the merchant or any third party such as email providers banking institutions or anybody else watching the network so every event in our sequence is an opportunity for data to be gathered and be connected back to who we are and so we wanted to make sure that every event

that was happening that there was some privacy preserving features there and so tour for anonymous web browsing this allows the subscriptions to be discovered without revealing the user's identity if I were browsing and to note this could also be replaced with other secure and anonymous options but this is what we chose to use right now just because for additional an initial implementation is because it works now but I'm sure there's people designing really cool other things out there that we could substitute for this but we just want to have that privacy feature and then the Z cache shielded transactions to avoid disclosing transactional data on the böck chain and again you could probably reimplemented other blockchain that had

privacy protecting features yeah we just say that when swapping these people these pieces out that we it we would need to reevaluate the whole privacy implications and the security risks of the whole system so a quick mention for a related work there is Bitcoin VIP 70 which talks about subscriptions but not reoccurring ones and this is not an exhaustive list of related efforts but I just wanted to put that out there in case anybody wanted to look at some of these related efforts and then there's probably some that I missed too and then there's a theorem there's some discussion around subscriptions there

too and there's things like lightning Network and bolt for Z cache and you know these all are things different efforts that people are making in the subscriptions subscription space but not necessarily with so many privacy features so our next steps are to implement this on s4 for ourselves and along with the with this a plain release which will make things faster and then this will give us an end-to-end privacy solution for our file storage system and the payments that people make to us in the Senate this isn't the end solution for us we surely could build cooler stuff but we just saw this as like how could we prototype something really fast

and how could we design just the basics and we could build really cool much much more interesting things on top of it but we wanted something functioning as soon as possible and yeah we would like to facilitate the development of higher-level applications like user facing wallets merchants facing payment frameworks and stuff that utilize private periodic payments also so my calls to action for you guys is to contribute to the development of this type of work talk about the work and raise awareness implement it steal our ideas send us your ideas send us your thoughts and feedback and see how far we can take these kinds of concepts forward to have in the end privacy for people not just

privacy and pieces and I have to give credit to the creators of Tahoe laughs and the creators of p4 it wasn't just me so and then I guess questions