* [Bitcoin-development] Fwd: Creating a Currency for the (Read / Write) Web
[not found] <CAKaEYhK0UWzQ8TbU3cCXvUSbz-f82n-BFaRmLdSjXzO8bGrdsA@mail.gmail.com>
@ 2013-06-05 17:01 ` Melvin Carvalho
0 siblings, 0 replies; only message in thread
From: Melvin Carvalho @ 2013-06-05 17:01 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]
FYI: I think this may be a possible blue print for a web version of
bitcoin+ripple combined.
---------- Forwarded message ----------
From: Melvin Carvalho <melvincarvalho@gmail•com>
Date: 5 June 2013 18:50
Subject: Creating a Currency for the (Read / Write) Web
To: public-rww <public-rww@w3•org>, Nathan Rixham <nrixham@gmail•com>, Web
Payments <public-webpayments@w3•org>
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.
[-- Attachment #2: Type: text/html, Size: 4649 bytes --]
^ permalink raw reply [flat|nested] only message in thread