Except that it needs more thinking about than that, because of questions like "what data source does everything use to agree that 1 month has passed since the last transaction", or "can I revoke a direct debit within a certain time period after the money's left my wallet" combined with "how do I get notified when money leaves my wallet".
There's also the question of whether the ability to just register a monthly standing order with various common clients would be good enough, rather than needing to pull money.
A lot of this is a UX exercise rather than a technical one, to be honest.
That could easily just be the blockchain itself, by specifying the time in terms of number of blocks.
> "can I revoke a direct debit within a certain time period after the money's left my wallet"
That can be done by having the money first be sent to an escrow where sender could retrieve money with a special key.
Notifications are easy: Email.
There's no way to revoke a transaction but you could implement a hold so ETH could only be withdrawn from the contract x days after the charge is incurred, within such time the owner could cancel the withdrawal.
As far as notifications are concerned, there are events in Ethereum that you can subscribe to. So for example you could subscribe to a charge event, and go in and dispute it.
Not disagreeing, just wanted to point out that one needs to be careful with timestamps in Ethereum, as the source of truth is miner. Using timestamps could result in security vulnerabilities.
However, on the scale of a month, the miners aren't going to be able to mess with you. A block stamped with a significantly incorrect timestamp won't be accepted by other miners.
On the flip side, I'm sure there are/will be oracles for approx. block time, so this is still a solveable issue.
https://github.com/ethereum/wiki/blob/c02254611f218f43cbb075...
From the block validation section: "Is block.timestamp <= now + 900 and is block.timestamp >= parent.timestamp?"
(In Solidity, block.timestamp is in seconds, and I think that's a direct translation from the underlying opcode, so I assume it's 900 seconds here.)
It needs, at a minimum, easy-to-use privacy preserving transactions. Without that, it's a personal-information-leaking nightmare.
I had to call the NYT a number of times to get them to cancel, and it was actually easier to just have it put on a months-long "vacation hold," during which time they didn't deliver. Every time the hold ended, I had to call up again and reinstate the hold. Although this was a hassle, it never occurred to me that it would be difficult to cancel if I were the actual subscriber! I thought it was just a pain because I was the recipient, but not the purchaser.
Hearst newspapers are more porn-like. They offer subscription periods with bizarre terms (3, 7, or 13 weeks) make it difficult to pay without a credit card, and forget to tell you that certain days count as multiple papers because of some special insert. If you make the mistake of giving them your credit card, you must cancel in a narrow window, and renewals are usually timed to skip credit card cycles so you don’t see a charge every month.
I am a weirdo who actually likes newspapers in paper form, but I gave up on my local paper because of bullshit like this.
pre-signed, time-locked transactions?
Correct me if I'm wrong, but that is not how cryptocurrencies work. The crypto is not stored on your computer. it shouldn't be so hard to set up a revokable recurrent payment with something like ERC-20.
Honestly the whitepaper talks a little too much about how revolutionary it will be and all the things it could solve without going into enough detail of implementing the solutions.
https://linux.die.net/man/5/crontab
This is a mostly solved problem. (The subscribee needs to gracefully handle missed or delayed payments, but that's true anywhere. Lack of chargebacks is only a problem if you have really bad wallet security, in which case you have bigger problems. Etc.)