Hacker News Reader

Comment by vertex-four | Hacker News Reader

This sort of thing is, actually, a reasonable use case for things like Ethereum's smart contracts. If there were a standard interface by which revocable "direct debits" could be created against users' wallets, this would be solved.

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.

View on HN

Every Ethereum block contains a timestamp which smart contracts can read, so it's trivial to write code that only allows withdrawals in 1 month intervals.

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.

> Every Ethereum block contains a timestamp which smart contracts can read, so it's trivial to write code that only allows withdrawals in 1 month intervals

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.

True if you're being really fine-grained about it, like using the timestamp as the seed of a random number generator.

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.

Are you sure about that? I was under the impression that there were no checks whatsoever and it's only a goodwill of miners (and lack of incentive to do otherwise) that provides somewhat accurate time.

On the flip side, I'm sure there are/will be oracles for approx. block time, so this is still a solveable issue.

Here's a spec from 2015:

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.)

I stand corrected - it seems blocks' time must be increasing and must not be more than 15 minutes in the future, according to clocks of validating miners. Thanks, didn't know that!

Yes, but realistically, Ethereum (like every other cryptocurrency) needs a lot more work before it's ready for mainstream usage.

It needs, at a minimum, easy-to-use privacy preserving transactions. Without that, it's a personal-information-leaking nightmare.

> "what data source does everything use to agree that 1 month has passed since the last transaction"

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.

Time in terms of number of blocks is likely to drift over the years, isn’t it?

the time will vary around some mean, like a random walk, which might drift significantly over the years. But over a short time won't be off by too much.

Reply on news.ycombinator.com