Proposed simple REST (and OAuth) based standard for financial transactions | Hacker News Reader

Proposed simple REST (and OAuth) based standard for financial transactions

wiki.github.com

13 points_pius10 comments

I had a similar idea to this a while back. But instead of mapping URLs to transactions, you would map URLs to a fixed denomination of currency.

So, for example, the URL http://eepay.com/usd/10/agh38hj3 would represent a $10 USD note, payable by the entity that issued it.

Ownership of a particular currency "note" would be handled via a private key. In other words, the individual in possession of a private key for a given URL would be considered the "owner" of that note. With that private key, one could either redeem the currency in question or transfer ownership to someone else. Transfer of ownership would be handled via a secure handshake, in which the new owner of the note is given a new private key, which can then be verified.

Obviously this is all very low level, so actual transactions would abstract away most of this.

The advantage of this type of currency would be that it is anonymous and doesn't require a whole lot of verification information for every little purchase. This would make it ideal for microtransactions, or for transactions where you wouldn't want to reveal your identity.

The disadvantage is that it would be a challenge to keep private keys secure. Another obvious disadvantage is that such currency would only be successful if it was backed by a highly trusted institution. There are other challenges and disadvantages to be sure.

You can't get low latency and high throughput with HTTP overhead. The headers will be bigger than transactions for starters.

Feels hopelessly naive. Conflates transactions and securities, for example.

Surely you can comprehend that people might want to make transactions related to securities, current accounts, and any other store of value/assets?

This is fascinating. But. How do you prevent a bad actor asset provider from creating money out of thin air?

If you can't solve that problem, your economy is going to have more liquidity than real assets. It's a hard problem.

Much respect for Pelle. But this won't fly until that problem is solved.

You deal with it the same way you do in real life. You don't do business with them. If I only trust dollars I can stick to dollars. But if I trust Brooklyn Greenbacks or the BACE, then I can use them. Not sure how this is related to the protocol as any paper currency has this issue also.

But part of the beauty of the current financial system is that most of the time if I use a trusted intermediary, I can confidently engage in financial transactions without having to build up a trust history.

Again, not sure how this matters as it seems like you are going down a path that is unrelated to the actual protocol. There has been discussion of Ripple on the agile banking list and other payment systems that rely on intermediaries, and OpenTransact could be used in those systems, but the issue is not inherent in the protocol alone.

Just playing devils advocate here; This is another one of those standards that assumes the whole world speaks English.

How does this assume English any more than the other protocols, HTTP and OAuth, on which it is based?

And, isn't that level of assumption a good thing for comprehension and interoperability?

Reply on news.ycombinator.com