Author: Erik Aronesty 2016-06-22 20:37:06
Published on: 2016-06-22T20:37:06+00:00
The discussion revolves around the need for subscriptions to be built into the protocol. It is clarified that PaymentRequest is a response to a customer-initiated action, and not something that merchants can initiate themselves. According to BIP0075, all InvoiceRequests are initiated by customers. Merchants do not initiate anything; subscription information must reside in the customer's wallet in response to merchant advice on setting up a subscription. The only way to do this within BIP70/75 is by tacking parameters onto a PaymentRequest or PaymentAck. The only thing left to work out is what fields to tack on and what they mean, such as subscription amount, currency, interval, and interval type. Wallets are responsible for initiating subscriptions on behalf of users. Recommendations on how to do this should be included in the spec. Wallets can add support for subscriptions without any spec by using BIP0075 and letting users set them up manually. However, it would be helpful if users did not have to enter the main parameters for subscriptions since it is easy to get amounts and times wrong.The discussion then shifts towards the possibility of expanding Bitcoin URIs to include signatures. For BIP75 store and forward servers, it is suggested that the DNS record would have the user's public key as well as the URL of their store and forward endpoint. Expanding the Bitcoin URI could also be done for people who prefer a simpler route and do not want to rely on servers.Furthermore, there is a debate on whether subscriptions should be built into the protocol. Erik Aronesty argues that payment channels seem inappropriate for monthly subscriptions, and merchants cannot send requests to users for future payments because users do not run servers that they can connect to. Therefore, there is a need to have an interval for subscriptions, at a minimum, stored in the wallet so that the next month's payment can go out on time. Support for varying currency conversion needs to be baked into wallets. By adding advisory subscription info to the PaymentRequest, this is left up to the wallet to secure/validate/repeat/convert/etc. as needed for each subscription. The UI described by Andy Schroder is nice but not unique to the solution.In conclusion, there is a need for subscriptions to be built into the protocol to facilitate Bitcoin's use as a real payment system. It is suggested that subscription information should be stored in the customer's wallet in response to merchant advice on setting up a subscription. Wallets are responsible for initiating subscriptions on behalf of users, and recommendations on how to do this should be included in the spec. Expanding Bitcoin URIs to include signatures is also recommended.
Updated on: 2023-06-11T18:43:39.355515+00:00