forked from cheng/wallet
175 lines
7.8 KiB
HTML
175 lines
7.8 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
|
||
<style> p.center { text-align:center; }
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>What is to be done</title>
|
||
</head>
|
||
<body>
|
||
<h1>What is to be done</h1>
|
||
<p>
|
||
This is incoherent, and not yet ready for the rest of the
|
||
world to see.</p>
|
||
<p>
|
||
Zooko Identity system.</p>
|
||
<p>
|
||
One of the services an identity may provide is IM
|
||
equivalent, email equivalent, single sign on service,
|
||
monetary transfer, and contract formation. If it
|
||
provides one of these, it normally provides the other
|
||
three.</p>
|
||
<p>
|
||
Another service an identity provide is https equivalent,
|
||
only with yurls instead of urls.</p>
|
||
<p>
|
||
At the lowest level, we have multilayer protocol
|
||
negotiation process in which the layers are integrated
|
||
so that additional layers do not result in additional
|
||
round trips.</p>
|
||
<p>
|
||
Excess round tripping is avoided by having compile time
|
||
layering rather than run time layering. At compile
|
||
time, a layered description generates a fully integrated
|
||
protocol, with optimistic protocol negotiation, so that
|
||
if all goes well, all levels of the protocol are agreed
|
||
in a single round trip. Layered source code is compiled
|
||
into integrated and unlayered run time code. According to Google
|
||
research, we lose two percent of users for every second of delay a web
|
||
page takes in coming up.</p>
|
||
<p>
|
||
At the lowest level we have an IP equivalent protocol,
|
||
with network addresses as opaque blobs of variable size.
|
||
Typically these blobs contain IP addresses, possibly IP
|
||
addresses plus port number, plus some additional
|
||
information, with packets typically encapsulated as udp
|
||
packets, during session establishment, imitations of tpc
|
||
establishment packets. Possibly we imitate tcp packets.
|
||
Anyone can write their own IP imitation and drop it in,
|
||
leaving all other code unchanged, thus if an ISP is
|
||
playing hardball, as comcast does, one can encapsulate
|
||
information inside packets that pass ISP inspection as
|
||
some more politically correct packets. The intent here
|
||
is that if someon is having trouble with comcast, lots
|
||
of people will add additional comcast resistent IP
|
||
layers, and if you compile your server with that layer,
|
||
and someone under comcast activates that layer in his
|
||
client, he will talk lie-to-comcast with the server,
|
||
while the server transparently talks some other IP
|
||
imitation protocol with other clients. </p>
|
||
<p>
|
||
Layering, however, is compile time, thus to support a
|
||
new hide-from-the-isp protocol, clients and servers have
|
||
to be recompiled with the new library, rather than it
|
||
being put in the OS, and binaries then automatically
|
||
using it. That is a cost of compile time layering. The
|
||
cost of run time layering is additional round
|
||
trips.</p>
|
||
<p>
|
||
Money should support webmoney, also Satoshi Nakamoto’s
|
||
bitgold coins, if available.</p>
|
||
<p>
|
||
"Satoshi Nakamoto" <satoshi@vistomail.com> has
|
||
published a transferrable proof of work protocol,
|
||
http://www.bitcoin.org/bitcoin.pdf, (I have a local
|
||
copy) </p>
|
||
<p>
|
||
The core concept is that multiple people keep copies of a hash tree
|
||
saying who owns what coins, and in order to add new coins to the list,
|
||
you have to have a copy of the tree. </p>
|
||
<p>
|
||
Problem is this makes coins expensive, for to be
|
||
reasonaly safe against private and public attack, the
|
||
system needs more than a dozen or so copies. </p>
|
||
<p>
|
||
Bitcoin transactions are cheap enough to compete with
|
||
bankcards, but we already have a bankcard system that
|
||
works fine. An alternative system cannot compete
|
||
directly. </p>
|
||
<p>
|
||
Instead, an alternative system has to provide service in
|
||
an area where bankcard cannot. </p>
|
||
<p>
|
||
File sharing is an obvious area. At present, file
|
||
sharing works by barter for bits. This, however requires
|
||
the double coincidence of wants. People only upload
|
||
files they are downloading, and once the download is
|
||
complete, stop seeding. So only active files, files that
|
||
quite a lot of people want at the same time, are
|
||
available. </p>
|
||
<p>
|
||
File sharing requires extremely cheap transactions, so to
|
||
support file sharing on bitcoins, we will need a layer of
|
||
account money on top of the bitcoins, supporting
|
||
transactions of a hundred thousandth the size of the
|
||
smallest coin, and to support anonymity, chaumian money
|
||
on top of the account money. </p>
|
||
<p>
|
||
Let us call a bitcoin bank a bink. The bitcoins
|
||
stand in the same relation to account money as gold stood
|
||
in the days of the gold standard. The binks, not
|
||
trusting each other to be liquid when liquidity is most
|
||
needed, settle out any net discrepancies with each other
|
||
by moving bit coins around once every hundred thousand
|
||
seconds or so, so bitcoins do not change owners that
|
||
often, Most transactions cancel out at the
|
||
account level. The binks demand bitcoins of each
|
||
other only because they don’t want to hold account money
|
||
for too long. So a relatively small amount of
|
||
bitcoins infrequently transacted can support a
|
||
somewhat larger amount of account money frequently
|
||
transacted. </p>
|
||
<p>
|
||
But I digress, I ramble. In order to make all this
|
||
stuff work, we need yurls – but yurls as specified lack
|
||
some capabilities.</p>
|
||
<p>
|
||
I was thinking of putting up a bink in the cloud, and
|
||
then thought "and suppose the government steals
|
||
it." Well obviously, we want all its secrets to
|
||
have a time out after a while, so the government gets
|
||
stuff all, and pretty soon the bink pops up somewhere
|
||
else. </p>
|
||
<p>
|
||
We need each yurl to represent an equivalence class of
|
||
yurls, so that we can have keys that authorize keys, keys
|
||
that time out and are replaced by superior master keys,
|
||
and such like. To implement companies, we need m
|
||
of signatures – a key is valid if is signed by m of
|
||
the underlying n keys, and so forth. </p>
|
||
<p>
|
||
To support action in the cloud, we need the process of
|
||
secret establishment to provide for a new IP – you hit up
|
||
the permanent IP, and get a secret shared with a
|
||
transient IP. </p>
|
||
<p>
|
||
We need protocol generation – you specify your messages,
|
||
you get a generated client server that supports protocol
|
||
negotiation, and on top of best effort messages provides
|
||
session establishment, shared secrets, DNS resistance,
|
||
and within a session, flow control, at least once
|
||
messages not necessarily in order, at most once messages
|
||
in order, and once and only once messages in order.
|
||
</p>
|
||
<p>
|
||
And then we need yurls representing identity, instant
|
||
messaging from yurl to yurl, therefore yurls representing
|
||
instant messaging addresses, buddies, yurls representing
|
||
sums of money, and yurls representing contracts. </p>
|
||
<p>
|
||
When we can do all that, then we have for filesharing by
|
||
such entities, thus a need for binks, and binks have a
|
||
need for bitcoins, but first the yurls, for there is lots
|
||
of stuff we can do with yurls. </p>
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons
|
||
Attribution-Share Alike 3.0 License</a></p>
|
||
</body>
|
||
</html>
|