1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
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 <melvincarvalho@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAKaEYhK0UWzQ8TbU3cCXvUSbz-f82n-BFaRmLdSjXzO8bGrdsA@mail.gmail.com>
References: <CAKaEYhK0UWzQ8TbU3cCXvUSbz-f82n-BFaRmLdSjXzO8bGrdsA@mail.gmail.com>
Date: Wed, 5 Jun 2013 19:01:42 +0200
Message-ID: <CAKaEYhJySt48jonHEKaG=jtDfs2VoHYXGtXimKf1MAAzJVE6nQ@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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.
--001a11c38662ea69bc04de6b2666
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">FYI: I think this may be a possible blue print for a web v=
ersion of bitcoin+ripple combined.<br><div><br><div class=3D"gmail_quote">-=
--------- Forwarded message ----------<br>From: <b class=3D"gmail_sendernam=
e">Melvin Carvalho</b> <span dir=3D"ltr"><<a href=3D"mailto:melvincarval=
ho@gmail.com">melvincarvalho@gmail.com</a>></span><br>
Date: 5 June 2013 18:50<br>Subject: Creating a Currency for the (Read / Wri=
te) Web<br>To: public-rww <<a href=3D"mailto:public-rww@w3.org">public-r=
ww@w3.org</a>>, Nathan Rixham <<a href=3D"mailto:nrixham@gmail.com">n=
rixham@gmail.com</a>>, Web Payments <<a href=3D"mailto:public-webpaym=
ents@w3.org">public-webpayments@w3.org</a>><br>
<br><br><div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>=
<div><div><div><div><div><div><div>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.<br>
<br></div><b>Introduction<br><br></b></div>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 <br>
<br></div><b>Addresses<br><br></b></div>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.<br>
<br></div><div><b>Balances<br><br></b></div><div>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<br></div>
<div><br></div><b>Transactions<br><br></b></div>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.<br>
<br></div><b>Distributed Database<br><br></b></div>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.<br>
<br></div><b>Coin Creation<br><br></b></div>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.<br>
<br></div><b>Spam Protection<br><br></b></div>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.<br>
<br></div><b>Trust and Reputation<br><br></b></div>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.<br>
<br></div><b>Linked Data and Exensibility<br><br></b></div>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.<br>
<br><br></div>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.<br></div>
</div><br></div></div>
--001a11c38662ea69bc04de6b2666--
|
