- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 7 Jun 2013 23:50:35 +0200
- To: public-rww <public-rww@w3.org>, Nathan Rixham <nrixham@gmail.com>, Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYhLsLXHV1OA1zF5k4BYwmzKvVxsXBcPJiA=71NUt-eBiLw@mail.gmail.com>
On 5 June 2013 18:50, 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. > I'm going to start working on a reference implementation and testnet for this concept, which I also want to write a tabulator pane for. The idea is would be to run a test net for a year, then when the bugs are ironed out either convert the testnet to live, or reset a new block chain. If anyone is interested in discussing, implementing or running a node, just pop in to #webcredits on freenode -- cheers!
Received on Friday, 7 June 2013 21:51:03 UTC