[Opensim-dev] Micropayment

Kyle Hamilton aerowolf at gmail.com
Mon Nov 12 03:46:53 UTC 2007


Technically, Linden has already built such a micropayment system.  You
could actually transact with Lindenbucks with a fairly simple XMLRPC
app, and provided that both the buyer and the seller have Linden
accounts.  At that point, the problem would be authenticating to the
XMLRPC server that you'd have to build on the Linden live grid.
(Since Linden doesn't provide any means of performing cryptographic
primitives other than hashing, it would be rather difficult to
implement secure authentication in any mode.)

(And note, this also doesn't refer to the 'limited license' rights on
each lindenbuck.  I don't know that they could be used in such a
manner without violating the terms of the license.)

There's cryptographic protocols that exist to protect the identity of
the buyer and the seller from each other in a "must be done online to
protect integrity" mode.  There's also cryptographic protocols that
exist to protect the identity and integrity of transactions in offline
(i.e., eCash-type) modes.  (The protocols I refer to have means of
auditing a transaction to determine who is trying to cheat, in every
case where cheating is determined -- and also have means of
determining cheating in every case that cheating occurs, without
spilling any information in any case where no cheating is going on.)

The eCash protocols are all under patent in the US (at least they were
in 1995, when ecash.com was ahead of its time -- I don't know whether
the 17 years on each of them has expired yet).  The online protocols
aren't, to my knowledge.

For more information, you can look at Applied Cryptography, 2nd
Edition, by Schneier.

-Kyle H

On Nov 11, 2007 2:13 PM, Aldon Hynes <Aldon.Hynes at orient-lodge.com> wrote:
>
>
> Ezekiel, et al.,
>
>    I agree that it is not the scope of this project to develop or manage a
> banking system.  I believe that if OpenSim is properly architected, people
> creating OpenSim based grids will be able to determine if and how their
> grids will interconnect with an intergrid banking system.  That said, there
> will need to be safeguards in place to make sure that the currency of a grid
> is robust and secure.  The reason I brought this up in the first place was
> surrounding the issue of authentication.  You need to be authenticated to
> have access to the monetary system of any grid.  If anyone can easily create
> money in a given grid, then the value of currency from that grid will be
> worthless.
>
>    Likewise, I do believe that these sort of transactions should, as a
> general rule, be handled off-world.  The one caveat is that, at least in
> Second Life, if I try to pay someone more than I currently have, I'm given
> the option of purchasing more Linden Dollars in world.  This would seem to
> be a useful feature to have in other grids.
>
>    I do not know enough about the risk api of Linden Labs to give concrete
> suggestions, but it does seem as if the existing LL commands work pretty
> well for it.  I'm not sure if the standard XML format for communicating
> between vendor and payment providers is sufficiently described already in
> the risk api.
>
>    I am curious about the insecurity of LLGiveMoney.  It seems as if the
> real issue is if money in a given grid has any meaning.  If it does
> LLGiveMoney is a secure and important part of in world transactions.
>
>    On a more general note, I've been fairly involved with the banks and
> stock exchanges in Second Life.  Generally speaking, they keep their
> accounting information offline.  One bank is talking about using a gold
> standard for banking.  If I recall properly, currently milligram of gold
> costs about six Linden Dollars in the SL Adult grid.  Banks existing beyond
> the scope of a specific grid are logical places for currency exchange.  I
> would love to be able to pay an ATM in SL in Linden Dollars, and then
> withdraw that money from an ATM in DeepGrid Dollars in the DeepGrid.  The
> tools for that are pretty much handled by existing money events.  The only
> problem is that the other grids need to have a secure monetary system where
> money cannot be arbitrarily created.
>
>    My two Lindens, other thoughts are appreciated.
>
> Aldon
>
>
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de]On Behalf Of
> ezekiel at daelindor.com
> Sent: Sunday, November 11, 2007 3:02 PM
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Micropayment
>
>
> Aldon,
>
> I agree that the availability of micropayment is a critical success factor.
> In my view, it would be a honorable undertaking to implement the technical
> base for micropayment because this would allow many people, especially in
> developing countries, to open up their own small businesses. However, I
> think it is not in the scope of this project to develop and manage a
> currency or implement a banking system.
>
> In my view, the is only one easy way to implement payment: Do it off-world:
> The in-world vendor specifies the web address of a payment provider. Upon
> payment, a remote data channel to the provider is established and a browser
> window to the provider is opened on the user's PC. The user pays through
> secure html. The vendor is notified on the remote channel when the
> transaction is complete.
>
> What needs to be done to implement this ?
> - create a standard XML format for the communication between vendor and
> payment provider.
> - Implement an LL command like 'LLRequestPayment' that opens the browser at
> a specified web address and sends payment information to the provider.
> - Accept provider payment notification through 'money' event.
> - Since client based payment (prim payment) cannot be supported without
> additional parameters, it should be disabled. LLGiveMoney is also useless
> because
> it is not secure.
>
> Would this be OK ?
>
> Ezekiel
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>



More information about the Opensim-dev mailing list