Re: Creating a Currency for the (Read / Write) Web

On 6 June 2013 05:40, Brent Shambaugh <brent.shambaugh@gmail.com> wrote:

> Melvin,
>
> I like your post. Concerning this subject, I noticed that Apostolis
> Xekoukoulotakis posted to the p2p foundation mailing list with the title:
> "ripple as a decentralized insurance system" (1). I also was involved in a
> discussion with the Sensorica project, where I started learning more about
> value networks (2).
>

Insurance is a valid service, and it's valid to pay for insurance.  There's
an issue with people trying to sell you insurance when you dont want (or
need it).


>
> I am a bit concerned about what David Wood said about banks. I believe
> that in the future they will still play a role. In Ripple, possibly as
> Gateways. I hope to get back to this soon.
>

Banks are going nowhere.  Just as newspapers evolved to take advantage of
the internet, so banks (at least the smart ones) will evolve similarly.


>
> Brent
>
> (1)
> https://lists.ourproject.org/pipermail/p2p-foundation/2013-May/005952.html
> (2)
> https://groups.google.com/forum/?fromgroups#!category-topic/sensorica-infrastructure/2bb_Rmv_D
>
>
> On Wed, Jun 5, 2013 at 11:50 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>> I've been thinking for a while about how to create a currency for the
>> read write web.  And I thought I'd share some preliminary ideas.
>> Essentially this is bitcoin+ripple translated to the Web.
>>
>> *Introduction
>>
>> *
>> For those not familiar with the bitcoin concept it's essentially a
>> distributed ledger where each subject is a primary key in the ledger and
>> can hold 0 or more coins.  Coins are transferred using a signed and
>> timestamped PKI transaction log from one address to another, in a
>> distributed data base.
>>
>> *Addresses
>>
>> *
>> I think using a portable URI for addresses is the thing that makes most
>> sense.  So possibilities for this may be a URN, or schemes such as di:
>> (digest) or ni: (named information).  Anyone should be able to generate an
>> address, and they should be wide ranging to improve liquidity.
>>
>> *Balances
>>
>> *
>> Balances can be calculated by summing all inputs to that address.  You
>> can additionally keep a state of balances using the payswarm vocab, or
>> perhaps, goodRelations
>>
>> *Transactions
>>
>> *
>> I think a distributed data base could be maintained using read / write
>> web technologies, such as HTTP POST / PATCH or SPARQL Update.  The
>> signatures could be added using the WebKeys spec.
>>
>> *Distributed Database
>>
>> *
>> There are challenges associated with maintaining a distributed database.
>> I suggest we start small and whoever opts in can become part of the
>> verification process.  There are two recent methods for mitigating race
>> conditions an important one of which is called "double spend".  One is
>> proof of work, the other is consensus based on a unique node list.  I would
>> suggest using both techniques.  I'd like it to be possible to use both HTTP
>> (with self signed certificates), HTTP, and (secure) websockets too as the
>> transport layer.
>>
>> *Coin Creation
>>
>> *
>> This tends to be the most contentious point, with people tending not to
>> like the "premine" concept where you allocate coins to yourself.  However
>> companies like opencoin have successfully rolled out multi million or even
>> billion dollar premine schemes.  I would suggest coin creation in line with
>> bitcoin, where they are created proportionally to those maintaining the
>> integrity of rhe shared database.
>>
>> *Spam Protection
>>
>> *
>> Given the nature of the system, it may be easy to spam the network with
>> micro transactions.  As such there should be a transaction fee where those
>> that pay the highest fee are prioritized.
>>
>> *Trust and Reputation
>>
>> *
>> I think it would also help to have a trust and reputation system added to
>> the process, such that honest nodes benefit from acting honestly, and nodes
>> which are dishonest or not up to date are considered less dubious.  The
>> nature of the function should be that it's exponentially harder to gain
>> trust after you have a certain score.  Similar to chess ELO ratings.
>>
>> *Linked Data and Exensibility
>>
>> *
>> I think there should be a deep integration with web principles and linked
>> data to promote an app eco system and allow unexpected reuse.  Also it
>> should allow extensions such as the ripple protocol's trust lines, IOUs and
>> distributed markets, which are not initially scoped out.  Reusing existing
>> concepts such as the bitcon blockchain (e.g. so-called coloured coins),
>> ripple ledger, opentransactions, payswarm and web credits should all be
>> doable.
>>
>>
>> Just some food for thought.  Criticisms welcome.  Please let me know if
>> you're interested in running a node, and maybe we an get a reference
>> implementation going, as proof of concept.
>>
>
>