Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkH5q-0007Yf-ME for bitcoin-development@lists.sourceforge.net; Wed, 05 Jun 2013 17:01:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.174 as permitted sender) client-ip=209.85.217.174; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f174.google.com; Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UkH5p-00016J-Co for bitcoin-development@lists.sourceforge.net; Wed, 05 Jun 2013 17:01:50 +0000 Received: by mail-lb0-f174.google.com with SMTP id x10so94665lbi.19 for ; Wed, 05 Jun 2013 10:01:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.167.2 with SMTP id zk2mr15057701lbb.83.1370451702604; Wed, 05 Jun 2013 10:01:42 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Wed, 5 Jun 2013 10:01:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 19:01:42 +0200 Message-ID: From: Melvin Carvalho To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c38662ea69bc04de6b2666 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1UkH5p-00016J-Co Subject: [Bitcoin-development] Fwd: Creating a Currency for the (Read / Write) Web X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:01:50 -0000 --001a11c38662ea69bc04de6b2666 Content-Type: text/plain; charset=ISO-8859-1 FYI: I think this may be a possible blue print for a web version of bitcoin+ripple combined. ---------- Forwarded message ---------- From: Melvin Carvalho Date: 5 June 2013 18:50 Subject: Creating a Currency for the (Read / Write) Web To: public-rww , Nathan Rixham , Web Payments 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. --001a11c38662ea69bc04de6b2666 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI: I think this may be a possible blue print for a web v= ersion 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 / Wri= te) Web
To: public-rww <public-r= ww@w3.org>, Nathan Rixham <n= rixham@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.=A0 And I thought I'd = share some preliminary ideas.=A0 Essentially this is bitcoin+ripple transla= ted to the Web.

Introduction

For those not familiar with the = bitcoin concept it's essentially a distributed ledger where each subjec= t is a primary key in the ledger and can hold 0 or more coins.=A0 Coins are= transferred using a signed and timestamped PKI transaction log from one ad= dress to another, in a distributed data base.=A0

Addresses

I think using a portable URI for ad= dresses is the thing that makes most sense.=A0 So possibilities for this ma= y be a URN, or schemes such as di: (digest) or ni: (named information).=A0 = Anyone should be able to generate an address, and they should be wide rangi= ng to improve liquidity.

Balances

Balances can be calculated= by summing all inputs to that address.=A0 You can additionally keep a stat= e 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.=A0 The signatures could be added using the W= ebKeys spec.

Distributed Database

There are challenges ass= ociated with maintaining a distributed database.=A0 I suggest we start smal= l and whoever opts in can become part of the verification process.=A0 There= are two recent methods for mitigating race conditions an important one of = which is called "double spend".=A0 One is proof of work, the othe= r is consensus based on a unique node list.=A0 I would suggest using both t= echniques.=A0 I'd like it to be possible to use both HTTP (with self si= gned certificates), HTTP, and (secure) websockets too as the transport laye= r.

Coin Creation

This tends to be the most conte= ntious point, with people tending not to like the "premine" conce= pt where you allocate coins to yourself.=A0 However companies like opencoin= have successfully rolled out multi million or even billion dollar premine = schemes.=A0 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 syste= m, it may be easy to spam the network with micro transactions.=A0 As such t= here should be a transaction fee where those that pay the highest fee are p= rioritized.

Trust and Reputation

I think it would also he= lp to have a trust and reputation system added to the process, such that ho= nest nodes benefit from acting honestly, and nodes which are dishonest or n= ot up to date are considered less dubious.=A0 The nature of the function sh= ould be that it's exponentially harder to gain trust after you have a c= ertain score.=A0 Similar to chess ELO ratings.

Linked Data and Exensibility

I think there sh= ould be a deep integration with web principles and linked data to promote a= n app eco system and allow unexpected reuse.=A0 Also it should allow extens= ions such as the ripple protocol's trust lines, IOUs and distributed ma= rkets, which are not initially scoped out.=A0 Reusing existing concepts suc= h 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.=A0 Criticisms welcome.=A0 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.

--001a11c38662ea69bc04de6b2666--