
Proposed simple REST (and OAuth) based standard for financial transactions - _pius
http://wiki.github.com/opentransact/opentransact/opentransact
======
jsdalton
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.

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

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

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

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

~~~
jakehow
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.

~~~
olefoo
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.

~~~
jakehow
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.

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

~~~
gojomo
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?

