From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Fwd: Creating a Currency for the (Read / Write) Web
Date: Wed, 5 Jun 2013 19:01:42 +0200 [thread overview]
Message-ID: <CAKaEYhJySt48jonHEKaG=jtDfs2VoHYXGtXimKf1MAAzJVE6nQ@mail.gmail.com> (raw)
In-Reply-To: <CAKaEYhK0UWzQ8TbU3cCXvUSbz-f82n-BFaRmLdSjXzO8bGrdsA@mail.gmail.com>
[-- 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 --]
parent reply other threads:[~2013-06-05 17:01 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAKaEYhK0UWzQ8TbU3cCXvUSbz-f82n-BFaRmLdSjXzO8bGrdsA@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKaEYhJySt48jonHEKaG=jtDfs2VoHYXGtXimKf1MAAzJVE6nQ@mail.gmail.com' \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox