# P4: Private Periodic Payments Protocol by Liz Steininger (Devcon4)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2019-10-09
- Duration: 23:15
- Topics: blockchain, smart contracts, distributed ledger, Science & Technology
- Watch: https://streameth.org/watch/yt-UqgBNqJ4aYM
- YouTube: https://www.youtube.com/watch?v=UqgBNqJ4aYM

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/4/p4-private-periodic-payments-protocol

P4 aims to solve the problem of subscription services offering end-to-end private cryptocurrency payments. This protocol introduces periodicity to cryptocurrency payments through an ongoing relationship between the merchant and the customer without unintentionally disclosing personally identifiable information. We are creating this protocol to allow us to offer a truely end-to-end private subscription data storage solution built with Tahoe-LAFS. By sharing it, we hope that other subscription services will implement our protocol and further the adoption of cryptocurrency payments in real world retail use cases. Although this protocol is currently a work in progress, we have already specified some design decisions. For periodicity, we are avoiding a payment pre-authorization design to keep the user in control of their keys. And for privacy we are utilizing Zcash shielded transactions and the coming improvements in the Sapling release. This protocol is being created by the Least Authority team with support from the Zcash team. 

Speaker(s): Liz Steininger
Skill level: Intermediate
Track: Privacy
Keywords: payments

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 4 was held in Prague, Czech Republic on Oct 30 - Nov 2, 2018.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

so yeah I'm Liz Steinem gir with least authority I'm going to talk today about something that we're calling p4 because we like to play with numbers and letters and the P the four p's are private periodic payment protocol and so yeah just gonna tell you guys about what our work is with this and why we're doing it so like I said I'm Liz Steinem girl from least authority we believe that people have a right to privacy our mission is to make security easy to use and available to everyone we help others to improve their technologies to be more secure through security audits of things like distributed ledger technologies blockchain projects and related cryptographic efforts we also build technical solutions that incorporate these values using things like privacy by design empowering users to control their own data and also minimizing the access that service providers have to the user data or personal data data minimization we also like to participate with other communities and work together on particular efforts to these goals - I'm sorry I just realized my whole slide is not showing technical problems there we go okay so we operate a subscription-based service that's secure distributed storage product and we call it s4 again we like our letters and numbers and s4 stands for simple secure storage service and it's built using open source technology and enables client-side encryption so that the users can hold the keys to their data not us one of the projects that it uses that you'd eliza's is called Tahoe laughs la FS which stands for at least Authority file store and Tahoe laughs and our s4 service doesn't operate on access control lists or ACL or user accounts but instead works using object capability model oh cap or key based access this is similar to how cryptocurrency works in a high level it's similar in the sense that if you have the private key you have access to the crypto to the cryptocurrency and there's no user lists no centralized party that is kept that's saying that this particular cryptocurrency belongs to you personally so we don't have any personal account information with our system about this so we don't have any personal account information about the ciphertext that we're storing and you either have the capability to access it the key or you don't so this brings us to our problem and why we started this effort to begin with we have to use fiat currency with this so anyway so with our secure storage product we need to collect these subscription payments this is our business model with it and in so however in the world of fiat currency and online tools this results in us collecting personal data by using by using things like stripe and charge B and we are collecting this personal data only for the purpose of processing payments not for operating the service itself so right now we use stripe and charge B and only collect this personal data and not for any account management because of the o cap model so we didn't like this so we started talking amongst ourselves about how we could potentially use cryptocurrency to help us avoid using these centralized systems that are collecting personal data this came about from discussions about GDP our compliance which is the general data protection regulation it's in the EU about how personal data should be managed and so amongst ourselves we figured out that this was a problem and so we thought okay what could we do with cryptocurrency so we started looking around and how we could accept private payments for the subscription service and that would also allow us to do and and privacy for people just like we are able to offer them end to end encryption and privacy with the data storage service itself and so of course this is a problem now it's expensive to make things private and cheap to make them public unfortunately this seems to be the case right now and we're trying to work on making this not the case an expensive is relative and I think that this issue could be easily challenged with new technology so here are the layers of privacy that we're considering when we won't say that we want to do something that's end and private for the user we need to preserve this customers privacy at all these levels and these are the different layers and systems that we need to have interacting with about whether or not there's any personal data that would be leaked or any metadata that could be correlated with other data to become personal data the same way that the same way that like things like Bitcoin and aetherium the addresses could be you you know looked at correlated with other data in order to figure out people so that figure out personal identities so that are not true anonymity but pseudonym anonymity so starting from the bottom and moving to the top we decided to use tor for network layer privacy because it exists right now and it's usable some of our team members contribute to the Tor project which is an anonymity network that allows users to not reveal personal data on the network and this protects against leaking any IP address information which can be considered personal data and then Tahoe laughs is the technology as I mentioned before that we use with s4 and this offers storage laver layer privacy with client-side encryption and lastly we also use or not not Leslie sorry and then we have Z cache I think I I missed that sorry going up I skipped over Z cache see cache I'll talk more about it in the next slide but Z cache sue shielded transactions help us with financial privacy and then Tahoe laughs again helps us with the storage layer privacy and then going at the top we have the client application which is grid sync that we're using for ours but this also applies to the Z cash wallets and this gives users control over their payments and all of this is combined what we need to give us and and privacy for our subscription customers and why we particularly like doing it this way is because these all these things exist right now and we can put them together to have this implemented in a short amount of time so about cryptocurrency payments cryptocurrencies have some technical features that could be utilized including some privacy features one blockchain that we are familiar with is the cache our company's share founders and although there are two separate companies now so we should also share mission for privacy for everyone so we looked at how we could use utilize D caches privacy features to help us preserve privacy in our processing of customer payments and of course Z cache offers two types of payments one that our trend transparents transparent transactions and that which are is more like Bitcoin and then also the shielded transactions which utilize a particular type of zero knowledge proof called ZK snarks and so this assures so for subscriptions we need to establish a relationship between the customer and the merchant to facilitate payments that repeat at specific intervals so we went on to look at subscriptions with cryptocurrency so when we researched what was out there and the standards for doing subscription payments with crypto currencies what we found was a bit limiting and didn't quite meet our needs especially in the case of end-to-end privacy one current use of ZK shielded transactions is to have people prepay for their subscriptions this this works okay this is not ideal for subscriptions but this does work for some service offerings where you can turn off the service when a payment lapses and then turn it back on later after new payment and like for example electricity payments however in our case because people are uploading data to be stored on our storage service this is not an ideal user experience because if they stop their server because of the need to re-upload that data every single time and so amongst other downsides to this approach - and then another option is to do post paid subscriptions but this is also not ideal and it may renewal or payment periodicity a challenge and of course you can use smart contracts for managing some aspects of subscriptions but this and this is an option with aetherium and other platforms but it doesn't really offer much in terms of privacy at the moment and you can't do those on the Z cash blockchain at the moment and I hope to see both of those things change soon too so this meant what this meant is that we need to do some work on defied and defining how to preserve privacy while still establishing the necessary relationship for these reoccurring cryptocurrency payments for a subscription so this is what we came up with for p4 on the left side there's a list of basic tasks that we could that we need to have completed by a subscription and on the right side you can see the various pieces that the various layers the pieces that I mentioned earlier and they're part in these different steps and then this is all done over the Tor network so in the first step we have the subscription initiation the customer visits a web page and completes the subscription request now because we're not caring for much personal data this is probably just a button actually right now it is just a button we don't have any fields or a form for them to fill out because we don't want any more data we just want to know that they want to do this and so and then the second step is subscription creation and invitation and byte code so we the merchant create Z cash address and the and an initial database entry to link the subscription ID to the Z cash address we generate a special invite code for the subscription that includes configuration details to access our storage servers the capability that I mentioned before and it also includes the initial invoice for the service and in that invoice is a signature so that they can also verify us in the future and then the third step is client side subscription configuration the customers client a desktop application in our case grid sync that I mentioned earlier securely connects to us receives and receives the invite code and then gets configured for both managing the data they will store on our service and also the invoices they will receive for it and the fourth step is payment and server update next the customer has to actually send their first payment for the service for the service per the invoice that they just received and they need to do this payment via a Z cash wallet that payment is processed on the Z cash blockchain and we consider it a confirmed after a certain number of blocks are written that might not take too long maybe about an hour I think right now we're thinking about 24 blocks and then this triggers the publishing of the next invoice so the fifth step then is the recurring invoice and payment process from this point the client monitors the next for the next invoice displays it to the customer and continues to do this loop after subsequent payments are made and within when they go checked on the invoice there's we are also utilizing payment codes to be able to like to communicate to them the status of the payment and then also Cigna they can also verify the signature with each of these and then if they stop paying then their service is stopped so privacy is maintained by pushing many of the subscription management activities to the users device into their client client so client side instead of gathering the data in a central repository by a service like stripe or the equivalent of stripe and this decentralization of subscription data along with the Z cache shielded transactions and use of the Tor network allow us to not gather personal information about customers or any metadata that could be correlated for suggestions on who the user is so we'll go into more details this is the invoice so as for data standards again we looked around at things that are existing right now and we didn't see any kind of common language or agreed-upon protocol for expressing notions like billing period due date grace period and late penalties so we designed a simple invoice structure to allow us to communicate this information on the right you see a basic list of data that we need to have in our invoices which could be expanded to include more data for additional features in the future and on the left this is what the string of the invoice data actually looks like in this example a customer is being asked point1 Zack by a particular date here September 4th for the service least authority s for if the payment is made by a given deadline then the subscription will be extended for a month 2.5 million seconds until October 4th 2018 and I think in the future we need to include things like you know trial periods refunds things like that could be also included in this but this was just basically the the short list of data that we need to just process an invoice for the subscription so yeah to start to talk about next steps and where we're at right now so we're wrapping up the edits to our paper about this work and the privacy considerations that we've made in the designing of it we think that by also sharing you know these privacy considerations not just the technical specifications of what we're doing that we can help people understand more about how to do privacy by design or just at least explain how we're trying to do it and we'll be publishing that paper soon and we've already started implementing this for our s4 service we hope to have this we hope to have this available to pay I mean to use ZK shouldered transactions to pay for our service subscription sometime in a few weeks and this includes making updates to our desktop client grid sync and also yeah just making sure that the you know setting up this also includes setting up a separate tour website for people to visit and things like that because we need to force people even from the time that they're interested they're browsing trying to figure out if they want to subscribe to our service to start to use tor so that we don't get that IP address that we can correlate later yeah so also the sapling upgrade to Z cache just recently happened and that how it helps for faster to make a Z cache faster especially as shielded transactions and then we hope to get lots of feedback from various communities especially this community on to help us iterate and improve this we would like to coordinate efforts with other people who are working in the area of subscription subscription services and management within with cryptocurrency and all so people who care about privacy payments and stuff like that so for example and then we were also thinking about all kinds of great things that we could do in the future with this for example we could implement a more robust communication channel for subscription management via the encrypted memo field and Z cash transactions or data can be passed like where that invoice data could be passed back and forth as a in-band communication channel we're also looking at expanding on features within Tahoe laughs to create a communication channel there too and seeing if that would that would help and looking at improvements too or integrations with customer wallets to support this type of invoicing data and also the advanced features of things like trial periods refunds and stuff like that and we'd like to see the development of merchants facing payment frameworks to support subscriptions and management of those subscriptions for companies that want to utilize cryptocurrency payments and lastly we just hope that this inspires other subscription services to use cryptocurrency in a privacy-preserving way while experimenting with tech we understand that maybe privacy can be like an afterthought when you're doing experimentation but if we do want to see this because that in order for this to become mass adoption especially for cryptocurrency for subscription payments I think that there needs to be some privacy in those payments otherwise the world can see everything that you're subscribing to and that's not so cool other and also even if it's not so obvious what that data is if it's just like metadata or something with big data analytic capable it of capable capabilities that are out there right now people could start to easily correlate that data to other data that's out there and figure out more about you too so any current pseudonymity pseudo anonymity that we have right now will be quickly lost and a major factor in decentralization is removing such power from big corporations Central's central organizations and giving it to us as individuals to manage our subscriptions ourselves so usability will be very key in this too so I look forward to hearing from people about these efforts and how we can move forward thank you thanks yeah we have about four minutes for questions does anyone have any hi is there any anything that's in that's stored in the data that allows me to if I was a user to get any kind of proof that says my data is being stored and and is retrievable if I'm subscribed to a service like this yeah so in Tahoe laughs if there's proof of storage I don't think so right now I think that there's yeah there's maybe some other ways to do it but not not in the sense that there yeah not in the sense of the other projects that have that right now which I'm sorry Oh merchant networks so we're the merchants right now in this case in this use case where the merchants and this is just how we're going to handle it as a merchant in terms of integrating with other merchant networks that would be something that we could talk about is like a future possibility and you mean other companies other merchants like Netflix or something like that thank you like any of this subscription providers have they shown interest into using this kind of like anonymous payments into their service well yeah so other so other companies have said that they want to do subscription payments with cryptocurrency so like I said you could do right now subscription payments right now we're kind of difficult there's some workarounds that we have but we need to make those easier to use for cryptocurrency in general and then when it comes to the angle of privacy I think that well it might be okay to not be so worried about the personal data that's being leaked in the experimental phase in the short term that if we want to see in the long term if we want to see mass adoption I think we need to have some privacy preserving features in these subscription management services whether or not that's true anonymity that's a difficult thing but um yeah I just I think that it I think that most people out there just will not want to do subscriptions if they think everybody else in the world knows what they're doing what they're subscribed into that I think that we would want to keep that information to ourselves and only share it with who we want to share it with have you had a chance to connect with Kevin from who's doing VIP 13:37 I just talked to him quickly about this last night and yeah well we're gonna connect some more and talk about it some more I'd love to see us like coordinate efforts on that oh I see you're here too awesome yeah I'd want us to coordinate efforts on that because I think that it would be really good to talk to make sure that like you know we're being consistent on how we define things like invoices structure and stuff like that and yeah see if we can help with privacy on the etherium Network - any other questions so one question uh you say you comply with gdpr but how about AML anti money laundering you're opposed to monitor transactions if it's recurring payments if it's over fifty thousand how can you do that with uh if you don't know your customers yes okay I see AML stuff will I didn't sure there's yet like you said you mentioned fifty thousand in this case like to subscribe to our data storage service it's definitely not fifty thousand it's much cheaper than that so I think for like the day to day subscriptions that shouldn't be a problem but I can tell you once we implement this and we start actually receiving these these payments for our service in that way our business will definitely and before that - but I'll know a lot more about how this is actually going to be handled by the regulator's at least in Germany but right now it doesn't we don't foresee any major problems about that because again kyc AML is more about like large quantities of money as far as I understand you're shaking your head no though no not that's not my area of expertise but I think that that's definitely something that we should explore but I also think it's unrealistic to do the opposite thing which is to have all of this personal data floating around in public too so we have to I think we have to find some sort of like common ground between offering more privacy for subscription payments you with cryptocurrency and adhering to laws and regulations