bb6c750a0e
Finally going public with it. Linked it from my reaction.la web index, so should become visible to search engines bye and bye
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>
|