Re: Payments as a CSV

On 20 September 2012 21:04, Michiel de Jong <michiel@unhosted.org> wrote:

> On Thu, Sep 20, 2012 at 8:40 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> > In a given system all of these IOUs are redeemable with the central bank.
> > Historically for gold or silver, but currently it is just a guaranteed
> form
> > of legal tender meaning that merchants should accept it, or that it can
> be
> > used to pay taxes or court fines.
>
> that's not true for IOUs between peers - if your peer defects, your
> money is gone.
>

depends on the IOU ... in some cases it's enforceable I believe, it depends
on the structure of the agreement ... ill try and find out more on this


>
> > So what you should do is to keep a record of transactions as one task,
> and a
> > record of balances (eg in a closed system) as a separate task.
>
> but i want a decentralized, open system. that's why each pair of peers
> should keep track of a balance between the two of them.
>

Well that is a core use case.  But simply have an aggregation function.  So
you add the plus and minus in the js is the easiest way imho.


>
> > as the system scales the
> > balances can get out of sync
>
> no, balances are between peers. the number of participants can scale
> up without such a two-person balance every being affected by the
> thousands or millions of users that are not part of it. the number of
> users involved in the balance will still be two.
>

Sure but a modern financial system has to be able to deal not only with the
2 person scenario, but with 10, 1000, and millions.  So a base standard
needs to be a lowest common denominator.  But it's all extensible by
design, so more complex use cases can be handled.

When money friction i reduced to zero, you can start tackling interesting
problems such as income distribution, poverty (historically govt.
operations) but we can start to bring them into the digital age.  This on
top of making the web a first class market place to match buyers and
sellers of all kinds.