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>
|