Author: Christophe Biocca 2014-02-25 19:06:20
Published on: 2014-02-25T19:06:20+00:00
The discussion is about the protocol for recurring payments and its limitations. One suggestion is to allow a list of timestamps for recurring payments, which would shift the thinking to the merchant platform. Another suggestion is to add daily as an option and specify the recurring cycle as every n*period (one of daily, weekly, monthly, yearly). The current protocol only allows four possibilities for recurrence, which seems restrictive. The amounts are specified in terms of satoshi, and timestamps are UNIX time. The merchant ID namespace is for identifying the merchant, and the subscription ID is for identifying the recurring subscription. There are some concerns regarding the explicit value constraint that max_payment_amount > max_payment_per_period. It is unclear what happens if that constraint is violated. Additionally, it is unclear when the payment should occur given such a contract, such as if it's "monthly" then what day in the month would the payment occur? The comments were moved above the field definitions to encourage people to write enough detail without being put off by line length constraints. It is suggested to talk to BitPay/get Jeff+Stephen involved because they have customers that really want recurring payments, and those guys will have a clearer idea of customer requirements than they do. Some other comments about the bitcoinj implementation specifically include the lack of "wallet directory" concept, and the need to structure the code to allow that. Using a background polling thread is likely not flexible enough, as on some platforms you can't stay running all the time without upsetting people. Wallet apps should have an ability to control wakeup tasks. The BIP 70 is implemented in Bitcoin Core on the C++ side, so that isn't a concern.
Updated on: 2023-06-08T01:57:30.673155+00:00