wallet/docs/program/what_is_to_be_done.html

175 lines
7.8 KiB
HTML
Raw Normal View History

2022-02-17 22:33:27 -05:00
<!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.&nbsp; 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 Nakamotos
bitgold coins, if available.</p>
<p>
"Satoshi Nakamoto" &lt;satoshi@vistomail.com&gt; 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.&nbsp; The bitcoins
stand in the same relation to account money as gold stood
in the days of the gold standard.&nbsp; 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,&nbsp;&nbsp; Most transactions cancel out at the
account level.&nbsp; The binks demand bitcoins of each
other only because they dont 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.&nbsp; 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."&nbsp; 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.&nbsp; To implement companies, we need m
of&nbsp; 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>