fred/wallet
1
0
Fork 0
forked from cheng/wallet
Code Pull Requests Activity

I found I has been using lfs on windows

Browse Source 
Which is not supported by debian. Chaos ensued
and I had to back out of a bunch of bad commits
that had been pushed.

No end of evil probably ensued, with lost state
This commit is contained in:
Cheng 2022-06-15 17:08:35 +10:00
parent 2d942dbb50
commit 9c396b0ad2
No known key found for this signature in database
GPG Key ID: D51301E176B31828
7 changed files with 4474 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1152
docs/names/client_server.md Normal file
View File

File diff suppressed because it is too large Load Diff

1137
docs/names/identity.md Normal file
View File

File diff suppressed because it is too large Load Diff

350
docs/names/name_system.md Normal file
View File

@ -0,0 +1,350 @@
---
title: Name System
...
We intend to establish a system of globally unique wallet names, to resolve
the security hole that is the domain name systm, though not all wallets will
have globally unique names, and many wallets will have many names.
Associated with each globally unique name is set of name servers. When one’s
wallet starts up, then if your wallet has globally unique name, it logs in
to its name server, which will henceforth direct people to that wallet. If
the wallet has a network accessible tcp and/or UDP address it directs people
to that address (one port only, protocol negotiation will occur once the
connection is established, rather than protocols being defined by the port
number). If not, will direct them to a UDT4 rendevous server, probably itself.
We probably need to support [uTP for the background download of bulk data].
This also supports rendevous routing, though perhaps in a different and
incompatible way, excessively married to the bittorrent protocol.We might
find it easier to construct our own throttling mechanism in QUIC,
accumulating the round trip time and square of the round trip time excluding
outliers, to form a short term and long term average and variance of the
round trip time, and throttling lower priority bulk downloads and big
downloads when the short term average rises above the long term average by
more than the long term variance. The long term data is zeroed when the IP
address of the default gateway(router) is acquired, and is timed out over a
few days. It is also ceilinged at a couple of seconds.
[uTP for the background download of bulk data]: https://github.com/bittorrent/libutp
In this day and age, a program that lives only on one machine really is not
much of a program, and the typical user interaction is a user driving a gui
on one machine which is a gui to program that lives on a machine a thousand
miles away.
We have a problem with the name system, the system for obtaining network
addresses, in that the name system is subject to centralized state control,
and the TCP-SSL system is screwed by the state, which is currently seizing
crimethink domain names, and will eventually seize untraceable crypto
currency domain names.
In today’s environment, it is impossible to speak the truth under one’s true
name, and dangerous to speak the truth even under any durable and widely used
identity. Therefore, people who post under names tend to be unreliable.
Hence the term “namefag”. If someone posts under his true name, he is a
“namefag” – probably unreliable and lying. Even someone who posts under a
durable pseudonym is apt show excessive restraint on many topics.
The aids virus does not itself kill you. The aids virus “wants” to stick
around to give itself lots of opportunities to infect other people, so wants
to disable the immune system for obvious reasons. Then, without a immune
system, something else is likely to kill you.
When I say “wants”, of course the aids virus is not conscious, does not
literally want anything at all. Rather, natural selection means that a virus
that disables the immune system will have opportunities to spread, while a
virus that fails to disable the immune system only has a short window of
opportunity to spread before the immune system kills it, unless it is so
virulent that it likely kills its host before it has the opportunity to
spread.
Similarly, a successful memetic disease that spreads through state power,
through the state system for propagation of official truth “wants” to disable
truth speaking and truth telling – hence the replication crisis, peer
review, and the death of science. We are now in the peculiar situation that
truth is best obtained from anonymous sources, which is seriously suboptimal.
Namefags always lie. The drug companies are abandoning drug development,
because science just does not work any more. No one believes their research,
and they do not believe anyone else’s research.
It used to be that there were a small number of sensitive topics, and if you
stayed away from those, you could speak the truth on everything else, but now
it is near enough to all of them that it might as well be all of them, hence
the replication crisis. Similarly, the aids virus tends to wind up totally
suppressing the immune system, even though more selective shutdown would
serve its interests more effectively, and indeed the aids virus starts by
shutting down the immune system in a more selective fashion, but in the end
cannot help itself from shutting down the immune system totally.
The memetic disease, the demon, does not “want” to shut down truth telling
wholesale. It “wants” to shut down truth telling selectively, but inevitably,
there is collateral damage, so it winds up shutting down truth telling
wholesale.
To exorcise the demon, we need a prophet, and since the demon occupies the
role of the official state church, we need a true king. Since there is a
persistent shortage of true Kings, I here speaking as engineer rather than a
prophet, so here I am discussing the anarcho agorist solution to anarcho
tyranny, the technological solution, not the true king solution.
Because of the namefag problem and the state snatching domain names, we need,
in order to operate an untraceable blockchain based currency not only a
decentralized system capable of generating consensus on who owns what cash,
we need a system capable of generating consensus on who who owns which human
readable globally unique names, and the mapping between human readable names,
Zooko triangle names (which correspond to encryption public keys), and
network addresses, a name system resistant to the state’s attempts to link
names to jobs, careers, and warm bodies that can be beaten up or imprisoned,
to link names to property, to property that can be confiscated or destroyed.
A transaction output can hold an amount of currency, or a minimum amount of
currency and a name. Part of the current state, which every block contains,
is unused transaction outputs sorted by name.
If we make unused transaction outputs sorted by name available, might as well
make them available sorted by key.
In the hello world system, we will have a local database mapping names to
keys and to network addresses. In the minimum viable product, a global
consensus database. We will, however, urgently need a rendezvous system that
allows people to set up wallets and peers without opening ports on stable
network address to the internet. Arguably, the minimum viable product will
have a global database mapping between keys and names, but also a nameserver
system, wherein a host without a stable network address can login to a host
with a stable network address, enabling rendezvous. When one identity has its
name servers registered in the global consensus database, it always tries to
login to those and keep the connection alive with a ping that starts out
frequent, and then slows down on the Fibonacci sequence, to one ping every
1024 secondsplus a random number modulo 1024 seconds. At each ping, tells the
server when the next ping coming, and if the server does not get the
expected ping, server sends a nack. If the server gets no ack, logs the
client out. If the client gets no ack, retries, if still no ack, tries to
login to the next server.
In the minimum viable product, we will require everyone operating a peer
wallet to have a static IP address and port forwarding for most functionality
to work, which will be unacceptable or impossible for the vast majority of
users, though necessarily we will need them to be able to receive money
without port forwarding, a static IP, or a globally identified human readable
name, by hosting their client wallet on a particular peer. Otherwise no one
could get crypto currency they would need to set up a peer.
Because static IP is a pain, we should also support nameserver on the state
run domain name system, as well as nameserver on our peer network, but that
can wait a while. And in the end, when we grow so big that every peer is
itself a huge server farm, when we have millions of users and a thousand or
so peers, the natural state of affairs is for each peer to have a static IP.
Eventually we want people to be able to do without static IPs and
portforwarding, which is going to require a UDP layer. One the other hand, we
only intend to have a thousand or so full peers, even if we take over and
replace the US dollar as the world monetary system. Our client wallets are
going to be the primary beneficiaries of rendevous UDT4.8 routing over UDP.
We also need names that you can send money to, and name under which you can
receives. The current cryptocash system involves sending money to
cryptographic identifiers, which is a pain. We would like to be able to send
and receive money without relying on identifiers that look like line noise.
So we need a system similar to namecoin, but namecoin relies on proof of
work, rather than proof of stake, and the state’s computers can easily mount
a fifty one percent attack on proof of work. We need a namecoin like system
but based on proof of stake, rather than proof of work, so that for the state
to take it over, it would need to pay off fifty one percent of the
stakeholders – and thus pay off the people who are hiding behind the name
system to perform untraceable crypto currency transactions and to speak the
unspeakable.
For anyone to get started, we are going to have to enable them to operate a
client wallet without IP and port forwarding, by logging on to a peer wallet.
The minimum viable product will not be viable without a client wallet that
you can use like any networked program. A client wallet logged onto a peer
wallet automatically gets the name `username.peername`. The peer could give
the name to someone else though error, malice or equipment failure, but the
money will remain in the client’s wallet, and will be spendable when he
creates another username with another peer. Money is connected to wallet
master secret, which should never be revealed to anyone, not with the
username. So you can receive money with a name associated an evil nazi
identity as one username on one peer, and spend it with a username associated
with a social justice warrior on another peer. No one can tell that both
names are controlled by the same master secret. You send money to a username,
but it is held by the wallet, in effect by the master secret, not by the
user name. That people have usernames, that money goes from one username to
another, makes transferring money easy, but by default the money goes through
the username to the master secret behind the quite discardable username,
thus becomes anonymous, not merely pseudonymous after being received. Once
you have received the money, you can lose the username, throw it away, or
suffer it being confiscated by the peer, and you, not the username, still
have the money. You only lose the money if someone else gets the master
secret.
You can leave the money in the username, in which case the peer hosting your
username can steal it, but for a hacker to steal it he needs to get your
master secret and logon password, or you transfer it to the master secret on
your computer, in which case a hacker can steal it, but the peer cannot, and
also you can spend it from a completely different username. Since most people
using this system are likely to be keen on privacy, and have no good reason
to trust the peer, the default will be for the money to go from the username
to the master secret.
Transfers of money go from one username to another username, and this is
visible to the person who sent it and the person who received it, but if the
transfer is to the wallet and the master secret behind the username, rather
than to the username, this is not visible to the hosts. Money is associated
with a host and this association is visible, but it does not need to be the
same host as your username. By default, money is associated with the host
hosting the username that receives it, which is apt to give a hint to which
username received it, but you can change this default. If you are receiving
crypto currency under one username, and spending it under another username on
another host, it is apt to be a good idea to change this default to the host
that is hosting the username that you use for spending, because then spends
will clear more quickly. Or if both the usernames and both the hosts might
get investigated by hostile people, change the default to a host that is
hosting your respectable username that you do not use much.
We also need a state religion that makes pretty lies low status, but that is
another post.
# Mapping between globally unique human readable names and public keys
The blockchain provides a Merkle-patricia dac of human readable names. Each
human readable name links to a list of signatures transferring ownership form
one public key to the next, terminating in an initial assignment of the name
by a previous block chain consensus. A client typically keeps a few leaves
of this tree. A host keeps the entire tree, and provides portions of the tree
to each client.
When two clients link up by human readable name, they make sure that they are
working off the same early consensus, the same initial grant of user name by
an old blockchain consensus, and also off the same more recent consensus,
for possible changes in the public key that has rightful ownership of that
name. If they see different Merkle hashes at the root of their trees, the
connection fails. Thus the blockchain they are working from has to be the
same originally, and also the same more recently.
This system ensures we know and agree what the public key associated with a
name is, but how do we find the network address?
# Mapping between public keys and nework addresses
## The Nameserver System
Typically someone is logged in to a host with an identity that looks like an
email address, `paf.foo.bar`, where`bar` is the name of a host that is
reliably up, and reliably on the network, and relatively easy to find
You can ask the host `bar` for the public key and *the network address* of
`foo.bar`, or conversely the login name and network address associated with
this public key. Of course these values are completely subject to the caprice
of the owner of `bar`. And, having obtained the network address of `foo.bar`,
you can then get the network address of `paf.foo.bar`
Suppose someone owns the name `paf`, and you can find the global consensus as
to what public key controls `paf`, but he does not have a stable network
address. He can instead provide a nameserver – another entity that will
provide a rendevous. If `paf` is generally logged in to `foo`, you can
contact `foo`, to get rendevous data for `bar.foo`, which is, supposing `foo`
to be well behaved, rendevous data for `bar`
Starting from a local list of commonly used name server names, keys, and
network addresses, you eventually get a live connection to the owner of that
public key, who tells you that at the time he received your message, the
information is up to date, and, for any globally unique human readable names
involved in setting up the connection, he is using the same blockchain as you
are using.
Your local list of network addresses may well rapidly become out of date.
Information about network addresses flood fills through the system in the
form of signed assertions about network addresses by owners of public keys,
with timeouts on those assertions, and where to find more up to date
information if the assertion has timed out, but we do not attempt to create a
global consensus on network addresses. Rather, the authoritative source of
information about a network address of a public key comes from successfully
performing a live connection to the owner of that public key. You can, and
probably should, choose some host as the decider on the current tree of
network addresses, but we don’t need to agree on the host. People can work
off slightly different mappings about network addresses with no global and
complete consensus. Mappings are always incomplete, out of date, and usually
incomplete and out of date in a multitude of slightly different ways.
We need a global consensus, a single hash of the entire blockchain, on what
public keys own what crypto currency and what human readable names. We do not
need a global consensus on the mapping between public keys and network
addresses.
What you would like to get is an assertion that `paf.foo.bar` has public key
such and such, and whatever you need to make network connection to
`paf.foo.bar`, but likely `paf.foo.bar` has transient public key, because his
identity is merely a username and login at `foo.bar`, and transient network
address, because he is behind nat translation. So you ask `bar` about
`foo.bar`, and `foo.bar` about `paf.foo.bar`, and when you actually contact
`paf.foo.bar`, then, and only then, you know you have reliable information.
But you don’t know how long it is likely to remain reliable, though
`paf.foo.bar` will tell you (and no other source of information is
authoritative, or as likely to be accurate).
Information about the mapping between public keys and network addresses that
is likely to be durable flood fills through the network of nameservers.
# logon identity
Often, indeed typically, `ann.foo` contacts `bob.bar`, and `bob.bar` needs
continuity information, needs to know that this is truly the same `ann.foo`
as contacted him last time – which is what we currently do with usernames and
passwords.
The name `foo` is rooted in a chain of signatures of public keys and requires
a global consensus on that chain. But the name `ann.foo` is rooted in logon
on `foo`. So `bob.bar` needs to know that `ann.foo` can log on with `foo`,
which `ann.foo` does by providing `bob.bar` with a public key signed by `foo`,
which might be a transient public key generated the last time she logged
on, which will disappear the moment her session on her computer shuts down,
or might be a durable public key. But if it is a durable public key, this
does not give her any added security, since `foo` can always make up a new
public key for anyone he decides to call `ann.foo` and sign it, so he might
as well put a timeout on the key, and `ann.foo` might as well discard it when
her computer turns off or goes into sleep mode. So, it is in everyone’s
interests (except that of attackers) that only root keys are durable.
`foo`’s key is durable, and information about it is published.`ann.foo`’s
key is transient, and information about it always obtained directly from
`ann.foo` as a result of `ann.foo` logging in with someone, or as a result of
someone contacting `foo` with the intent of logging in to `ann.foo`.
But suppose, as is likely, the network address of `foo` is not actually all
that durable, is perhaps behind a NAT. In that case, it may well be that to
contact `foo`, you need to contact `bar`.
So, `foo!bar` is `foo` logged in on `bar`, but not by a username and
password, but rather logged on by his durable public key, attested by the
blockchain consensus. So, you get an assertion, flood filled through the
nameservers, that the network address of the public key that the blockchain
asserts is the rightful controller of `foo`, is likely to be found at `foo!`
(public key of `bar`), or likely to be found at `foo!bar`.
Logons by durable public key will work exactly like logons by username and
password, or logons by derived name. It is just that the name of the entity
logged on has a different form..
Just as openssh has logons by durable public key, logons by public key
continuity, and logons by username and password, but once you are logged on,
it is all the same, you will be able to logon to `bob.bar` as `ann.bob.bar`,
meaning a username and password at `bob.bar`, as `ann.foo`, meaning `ann` has
a single signon at `foo`, a username and password at `foo`, or as `ann`,
meaning `ann` logs on to `bob.bar` with a public key attested by the
blockchain consensus as belonging to `ann`.
And if `ann` is currently logged on to `bob.bar` with a public key attested
by the blockchain consensus as belonging to `ann`, you can find the current
network address of `ann` by asking `bob.bar` for the network address of
`ann!bob.bar`
`ann.bob.bar` is whosoever `bob.bar` decides to call `ann.bob.bar`, but
`ann!bob.bar` is an entity that controls the secret key of `ann`, who is at
this moment logged onto `bob.bar`.
If `ann` asserts her current network address is likely to last a long time,
and is accessible without going through
`bob.bar` then that network address information will flood fill through the
network. Less useful network address information, however will not get far.

148
docs/names/peering_through_nat.md Normal file
View File

@ -0,0 +1,148 @@
---
lang: en
title: Peering through NAT
...
A library to peer through NAT is a library to replace TCP, the domain
name system, SSL, and email. This is covered at greater length in
[Replacing TCP](replacing_TCP.html)
# Implementation issues
There is a great [pile of RFCs](./replacing_TCP.html) on issues that arise with using udp and icmp
to communicate.
## timeout
The NAT mapping timeout is officially 20 seconds, but I have no idea
what this means in practice. I suspect each NAT discards port mappings
according to its own idiosyncratic rules, but 20 seconds may be a widely respected minimum.
The official maximum time that should be assumed is two minutes, but
this is far from widely implemented, so keep alives often run faster.
Minimum socially acceptable keep alive time is 15 seconds. To avoid
synch loops, random jitter in keep alives is needed. This is discussed at
length in [RFC2450](https://datatracker.ietf.org/doc/html/rfc5405)
An experiment on [hole punching] showed that most NATs had a way
longer timeout, and concluded that the way to go was to just repunch as
needed. They never bothered with keep alive. They also found that a lot of
the time, both parties were behind the same NAT, sometimes because of
NATs on top of NATs
[hole punching]:http://www.mindcontrol.org/~hplus/nat-punch.html
"How to communicate peer-to-peer through NAT firewalls"
{target="_blank"}
Another source says that "most NAT tables expire within 60 seconds, so
NAT keepalive allows phone ports to remain open by sending a UDP
packet every 25-50 seconds".
The no brainer way is that each party pings the other at a mutually agreed
time every 15 seconds. Which is a significant cost in bandwidth. But if a
server has 4Mib/s of internet bandwidth, can support keepalives for couple
of million clients. On the other hand, someone on cell phone data with thirty
peers is going to make a significant dent in his bandwidth.
With client to client keepalives, probably a client will seldom have more
than dozen peers. Suppose each keepalive is sent 15 seconds after the
counterparty's previous packet, or an expected keepalive is not received,
and each keepalive acks received packets. If not receiving expected acks
or expected keepalives, we send nack keepalives (hello-are-you-there
packets) one per second, until we give up.
This algorithm should not be baked in stone, but rather should be an
option in the connection negotiation, so that we can do new algorithms as
the NAT problem changes, as it continually does.
If two parties are trying to setup a connection through a third party broker,
they both fire packets at each other (at each other's IP as seen by the
broker) at the same broker time minus half the broker round trip time. If
they don't get a packet in the sum of the broker round trip times, keep
firing with slow exponential backoff until connection is achieved,or until
exponential backoff approaches the twenty second limit.
Their initial setup packets should be steganographed as TCP startup
handshake packets.
We assume a global map of peers that form a mesh whereby you can get
connections, but not everyone has to participate in that mesh. They can be
clients of such a peer, and only inform selected counterparties as to whom
they are a client of.
The protocol for a program to open port forwarding is part of Universal Plug and Play, UPnP, which was invented by Microsoft but is now ISO/IEC 29341 and is implemented in most SOHO routers.
But is it generally turned off by default, or manually. Needless to say, if relatively benign Bitcoin software can poke a hole in the
firewall and set up a port forward, so can botnet malware.
The standard for poking a transient hole in a NAT is STUN, which only works for UDP – but generally works – not always, but most of the time. This problem everyone has dealt with, and there are standards, but not libraries, for dealing with it. There should be a library for dealing with it – but then you have to deal with names and keys, and have a reliability and bandwidth management layer on top of UDP.
But if our messages are reasonably short and not terribly frequent, as client messages tend to be, link level buffering at the physical level will take care of bandwidth management, and reliability consists of message received, or message not received. For short messages between peers, we can probably go UDP and retry.
STUN and ISO/IEC 29341 are incomplete, and most libraries that supply implementations are far too complete – you just want a banana, and you get the entire jungle.
Ideally we would like a fake or alternative TCP session setup, using raw
sockets and then you get a regular standard TCP connection on a random
port, assuming that the target machine has that service running, and the
default path for exporting that service results in window with a list of
accessible services, and how busy they are. Real polish would be hooking
the domain name resolution so that looking up the names in the peer top
level domain create a a hole, using fake TCP packets sent through a raw
socket. then return the ip of that hole. One might have the hole go through
wireguard like network interface, so that you can catch them coming and
going.
Note that the internet does not in fact use the OSI model though everyone talks as if it did. Internet layers correspond only vaguely to OSI layers, being instead:
1. Physical
2. Data link
3. Network
4. Transport
5. Application
And I have no idea how one would write or install one’s own network or
transport layer, but something is installable, because I see no end of
software that installs something, as every vpn does, wireguard being the simplest.
------------------------------------------------------------------------
Assume an identity system that finds the entity you want to
talk to.
If it is behind a firewall, you cannot notify it, cannot
send an interrupt, cannot ring its phone.
Assume the identity system can notify it. Maybe it has a
permanent connection to an entity in the identity system.
Your target agrees to take the call. Both parties are
informed of each other’s IP address and port number on which
they will be taking the call by the identity system.
Both parties send off introduction UDP packets to the
other’s IP address and port number – thereby punching holes
in their firewall for return packets. When they get
a return packet, an introduction acknowledgement, the
connection is assumed established.
It is that simple.
Of course networks are necessarily non deterministic,
therefore all beliefs about the state of the network need to
be represented in a Bayesian manner, so any
assumption must be handled in such a manner that the
computer is capable of doubting it.
We have finite, and slowly changing, probability that our
packets get into the cloud, a finite and slowly changing
probability that our messages get from the cloud to our
target. We have finite probability that our target
has opened its firewall, finite probability that our
target can open its firewall, which transitions to
extremely high probability when we get an
acknowledgement – which prior probability diminishes over
time.
As I observe in [Estimating Frequencies from Small Samples](./estimating_frequencies_from_small_samples.html) any adequately flexible representation of the state of
the network has to be complex, a fairly large body of data,
more akin to a spam filter than a Boolean.

1331
docs/names/replacing_TCP.md Normal file
View File

File diff suppressed because it is too large Load Diff

117
docs/names/true_names_and_TCP.md Normal file
View File

@ -0,0 +1,117 @@
---
lang: en
title: True Names and TCP
---
Vernor Vinge [made the point](http://www.amazon.com/True-Names-Opening-Cyberspace-Frontier/dp/0312862075) that true names are an instrument of
government oppression. If the government can associate
your true name with your actions, it can punish you for
those actions. If it can find the true names associated
with a transaction, it is a lot easier to tax that
transaction.
Recently there have been moves to make your cell phone
into a wallet. A big problem with this is that cell
phone cryptography is broken. Another problem is that
cell phones are not necessarily
associated with true names, and as soon as the government hears
that they might control money, it starts insisting that cell phones
*are* associated with true names. The phone companies don’t like
this, for if money is transferred from true name to true name, rather
than cell phone to cell phone, it will make them a servant of the
banking cartel, and the bankers will suck up all the gravy, but once
people start stealing money through flaws in the encryption, they
will be depressingly grateful that the government can track account
holders down and punish them – except, of course, the government
probably will not be much good at doing so.
TCP is all about creating connections.  It creates connections between network addresses, but network addresses correspond to
the way networks are organized, not the way people are organized,
so on top of networks we have domain names.
TCP therefore establishes a connection *to* a domain name rather
than a mere network address – but there is no concept of the
connection coming *from* anywhere humanly meaningful.
Urns are “uniform resource names”, and uris are “uniform resource identifiers” and urls are “uniform resource locators”, and that is what the web is built out of. 
There are several big problems with urls:
1. They are uniform: Everyone is supposed to agree on one domain name for one entity, but of course they don’t.  There is honest and reasonable disagreement as to which jim is the “real” jim, becaŭse in truth there is no one real jim, and there is fraŭd, as in lots of people pretending to be Paypal or the Bank of America, in order to steal your money.
2. They are resources: Each refers to only a single interaction,
but of course relationships are built out of many
interactions.  There is no concept of a connection continuing
throughout many pages, no concept of logon.  In building
urls on top of TCP, we lost the concept of a connection.  And
because urls are built out of TCP there is no concept of the
content depending on both ends of the connection – that a
page at the Bank might be different for Bob than it is for
Carol – that it does in reality depend on who is connected is
a kluge that breaks the architecture.
Because security (ssl, https) is constructed below the level of
a connection, because it lacks a concept of connection
extending beyond a single page or a single url, a multitude of
insecurities result. We want https and ssl to secure a
connection, but https and ssl do not know there are such
things as logons and connections.
That domain names and hence urls presuppose agreement, agreement
which can never exist, we get cybersquatting and phishing and
suchlike.
That connections and logons exist, but are not explicitly addressed
by the protocol leads to such attacks as cross site scripting and
session fixation.
A proposed fix for this problem is yurls, which apply Zooko’s
triangle to the web: One adds to the domain name a hash of a rule
for validating the public key, making it into Zooko’s globally unique
identifier.  The nickname (non unique global identifier) is the web
page title, and the petname (locally unique identifier) is the title
under which it appears in your bookmark list, or the link text under
which it appears in a web page.
This, however, breaks normal form.  The public key is an attribute of the domain, while the nickname and petnames are attributes of particular web pages – a breach of normal form related to the loss of the concept of connection – a breach of normal form reflecting the fact that that urls provide no concept of a logon, a connection, or a user.  
OK, so much for “uniform”.  Instead of uniform identifiers, we
should have zooko identifiers, and zooko identifiers organized in
normal form.  But what about “resource”, for “resource” also breaks
normal form.
Instead of “resources”, we should have “capabilities”.  A resource
corresponds to a special case of a capability, a resource is a
capability that that resembles a read only file handle. But what
exactly are “capabilities”?
People with different concepts about what is best for computer security tend to disagree passionately and at considerable length about what the word “capability” means, and will undoubtedly tell me I am a complete moron for using it in the manner that I intend to use it, but barging ahead anyway:
A “capability” is an object that represents one end of a
communication channel, or information that enables an entity to
obtain such a channel, or the user interface representation of such a
channel, or such a potential channel. The channel enables the
possessor of the capability to do stuff to something, or get
something.  Capabilities are usually obtained by being passed along
the communication channel. Capabilities are usually obtained from
capabilities, or inherited by a running instance of a program when
the program is created, or read from storage after originally being
obtained by means of another capability.
This definition leaves out the issue of security – to provide security, capabilities need to be unforgeable or difficult to guess.  Capabilities are usually defined with the security characteristics central to them, but I am defining capabilities so that what is central is connections and managing lots of potential connection.  Sometimes security and limiting access is a very important part of management, and sometimes it is not.
A file handle could be an example of a capability – it is a
communication channel between a process and the file
management system.  Suppose we are focussing on security and
access management to files: A file handle could be used to control
and manage permissions if a program that has the privilege to
access certain files could pass an unforgeable file handle to one of
those files to a program that lacks such access, and this is the only
way the less privileged program could get at those files.
Often the server wants to make sure that the client at one end of a
connection is the user it thinks it is, which fits exactly into the usual
definitions of capabilities.  But more often, the server does not care
who the client is, but the client wants to make sure that the server
at the other end of the connection is the server he thinks it is,
which, since it is the client that initiates the connection, does not fit
well into many existing definitions of security by capabilities.

239
docs/tim_may_on_bitcoin.md Normal file
View File

@ -0,0 +1,239 @@
---
# notmine
lang: en
title: Enough with the ICO-Me-So-Horny-Get-Rich-Quick-Lambo Crypto
---
*CoinDesk asked cypherpunk legend Timothy May, author of the “**[Crypto Anarchist Manifesto](https://www.activism.net/cypherpunk/crypto-anarchy.html),**” to write his thoughts on the bitcoin white paper on its 10th anniversary. What he sent back was a sprawling 30-page evisceration of a technology industry he feels is untethered from reality.*
*The original message is presented here as a fictional Q&A for clarity. The message remains otherwise unchanged. Read more in our **[White Paper Reflections](/category/bitcoin-white-paper-reviewed/)** series.*
------------------------------------------------------------------------
**CoinDesk: Now that bitcoin has entered the history books, how do you feel the white paper fits in the pantheon of financial cryptography advances?**
**Tim:** First, I’ll say I’ve been following, with some interest, some amusement and a lot of frustration for the past 10 years, the public situation with bitcoin and all of the related variants.
In the pantheon, it deserves a front-rank place, perhaps the most important development since the invention of double-entry book-keeping.
I can’t speak for what Satoshi intended, but I sure don’t think it involved bitcoin exchanges that have draconian rules about KYC, AML, passports, freezes on accounts and laws about reporting “suspicious activity” to the local secret police. There’s a real possibility that all the noise about “governance,” “regulation” and “blockchain” will effectively create a surveillance state, a dossier society.
I think Satoshi would barf. Or at least work on a replacement for bitcoin as he first described it in 2008-2009. I cannot give a ringing endorsement to where we are, or generate a puff-piece about the great things already done.
Sure, bitcoin and its variants – a couple of forks and many altcoin variants – more or less work the way it was originally intended. Bitcoin can be bought or mined, can be sent in various fast ways, small fees paid and recipients get bitcoin and it can be sold in tens of minutes, sometimes even faster.
No permission is needed for this, no centralized agents, not even any trust amongst the parties. And bitcoin can be acquired and then saved for many years.
But this tsunami that swept the financial world has also left a lot of confusion and carnage behind. Detritus of the knowledge-quake, failed experiments, Schumpeter’s “creative destructionism.” It’s not really ready for primetime. Would anyone expect their mother to “download the latest client from Github, compile on one of these platforms, use the Terminal to reset these parameters?”
What I see is losses of hundred of millions in some programming screw-ups, thefts, frauds, initial coin offerings (ICOs) based on flaky ideas, flaky programming and too few talented people to pull off ambitious plans.
Sorry if this ruins the narrative, but I think the narrative is fucked. Satoshi did a brilliant thing, but the story is far from over. She/he/it even acknowledged this, that the bitcoin version in 2008 was not some final answer received from the gods..
**CoinDesk: Do you think others in the cypherpunk community share your views? What do you think is creating interest in the industry, or killing it off?\
**
**Tim** Frankly, the newness in the Satoshi white paper (and then the early uses for things like Silk Road) is what drew many to the bitcoin world. If the project had been about a “regulatory-compliant,” “banking-friendly” thing, then interest would’ve been small. (In fact, there were some yawn-inducing electronic transfer projects going back a long time. “SET,” for Secure Electronic Transfer, was one such mind-numbingly-boring projects.)
It had no interesting innovations and was 99 percent legalese. Cypherpunks ignored it.
It’s true that some of us were there when things in the “financial cryptography” arena really started to get rolling. Except for some of the work by David Chaum, Stu Haber, Scott Stornetta, and a few others, most academic cryptographers were mainly focused on the mathematics of cryptology: their gaze had not turned much toward the “financial” aspects.
This has of course changed in the past decade. Tens of thousands of people, at least, have flocked into bitcoin, blockchain, with major conferences nearly every week. Probably most people are interested in the “Bitcoin Era,” starting roughly around 2008-2010, but with some important history leading up to it.
History is a natural way people understand things… it tells a story, a linear narrative.
About the future I won’t speculate much. I was vocal about some “obvious” consequences from 1988 to 1998, starting with “The Crypto Anarchist Manifesto” in 1988 and the Cypherpunks group and list starting in 1992.
**CoinDesk: It sounds like you don’t think that bitcoin is particularly living up to its ethos, or that the community around it hasn’t really stuck to its cypherpunk roots.**
**Tim** Yes, I think the greed and hype and nattering about “to the Moon!” and “HODL” is the biggest hype wagon I’ve ever seen.
Not so much in the “Dutch Tulip” sense of enormous price increases, but in the sense of hundred of companies, thousands of participants, and the breathless reporting. And the hero worship. This is much more hype than we saw during the dot-com era. I think far too much publicity is being given to talks at conferences, white papers and press releases. A whole lot of “selling” is going on.
People and companies are trying to stake-out claims. Some are even filing for dozens or hundreds of patents in fairly-obvious variants of the basic ideas, even for topics that were extensively-discussed in the 1990s. Let’s hope the patent system dismisses some of these (though probably only when the juggernauts enter the legal fray).
The tension between privacy (or anonymity) and “know your customer” approaches is a core issue. It’s “decentralized, anarchic and peer-to-peer” versus “centralized, permissioned and back door.” Understand that the vision of many in the privacy community — cypherpunks, Satoshi, other pioneers — was explicitly of a permission-less, peer-to-peer system for money transfers. Some had visions of a replacement for “fiat” currency.
David Chaum, a principal pioneer, was very forward-thinking on issues of “buyer anonymity.” Where, for example, a large store could receive payments for goods without knowing the identity of a buyer. (Which is most definitely not the case today, where stores like Walmart and Costco and everybody else compiled detailed records on what customers buy. And where police investigators can buy the records or access them via subpoenas. And in more nefarious ways in some countries.)
Remember, there are many reasons a buyer does not wish to disclose buying preferences. But buyers and sellers BOTH need protections against tracking: a seller of birth control information is probably even more at risk than some mere buyer of such information (in many countries). Then there’s blasphemy, sacrilege and political activism. Approaches like Digicash which concentrated on \*buyer\* anonymity (as with shoppers at a store or drivers on a toll-road), but were missing a key ingredient: that most people are hunted-down for their speech or their politics on the \*seller\* side.
Fortunately, buyers and sellers are essentially isomorphic, just with some changes in a few arrow directions (“first-class objects”).
What Satoshi did essentially was to solve the “buyer”/”seller” track-ability tension by providing both buyer AND seller untraceability. Not perfectly, it appears. Which is why so much activity continues.
**CoinDesk: So, you’re saying bitcoin and crypto innovators need to fight the powers that be, essentially, not align with them to achieve true innovation?**
**Tim** Yes, there is not much of interest to many of us if cryptocurrencies just become Yet Another PayPal, just another bank transfer system. What’s exciting is the bypassing of gatekeepers, of exorbitant fee collectors, of middlemen who decide whether Wikileaks — to pick a timely example — can have donations reach it. And to allow people to send money abroad.
Attempts to be “regulatory-friendly” will likely kill the main uses for cryptocurrencies, which are NOT just “another form of PayPal or Visa.”
More general uses of “blockchain” technology are another kettle of fish. Many uses may be compliance-friendly. Of course, a lot of the proposed uses — like putting supply chain records — on various public or private blockchains are not very interesting. Many point that these “distributed ledgers” are not even new inventions, just variants of databases with backups. As well, the idea that corporations want public visibility into contracts, materials purchases, shipping dates, and so on, is naive.
Remember, the excitement about bitcoin was mostly about bypassing controls, to enable exotic new uses like Silk Road. It was some cool and edgy stuff, not just another PayPal.
**CoinDesk: So, you’re saying that we should think outside the box, try to think about ways to apply the technology in novel ways, not just remake what we know?**
**Tim** People should do what interests them. This was how most of the innovative stuff like BitTorrent, mix-nets, bitcoin, etc. happened. So, I’m not sure that “try to think about ways” is the best way to put it. My hunch is that ideologically-driven people will do what is interesting. Corporate people will probably not do well in “thinking about ways.”
Money is speech. Checks, IOUs, delivery contracts, Hawallah banks, all are used as forms of money. Nick Szabo has pointed out that bitcoin and some other cryptocurrencies have most if not all of the features of gold except it also has more features: it weighs nothing, it’s difficult to steal or seize and it can be sent over the crudest of wires. And in minutes, not on long cargo flights as when gold bars are moved from place to another.
But, nothing is sacred about either banknotes, coins or even official-looking checks. These are “centralized” systems dependent on “trusted third parties” like banks or nation-states to make some legal or royal guaranty.
Sending bitcoin, in contrast, is equivalent to “saying” a number (math is more complicated than this, but this is the general idea). To ban saying a number is equivalent to a ban on some speech. That doesn’t mean the tech can’t be stopped. There was the “printing out PGP code,” or the Cody Wilson, Defense Distributed case, where a circuit court ruled this way,
Printed words are very seldom outside the scope of the First Amendment.
**CoinDesk: Isn’t this a good example of where you, arguably, want some censorship (the ability to force laws), if we’re going to rebuild the whole economy, or even partial economies, on top of this stuff?**
**Tim** There will inevitably be some contact with the legal systems of the U.S., or the rest of the world. Slogans like “the code is the law” are mainly aspirational, not actually true.
Bitcoin, qua bitcoin, is mostly independent of law. Payments are, by the nature of bitcoin, independent of charge-backs, “I want to cancel that transaction,” and other legal issues. This may change. But in the current scheme, it’s generally not know who the parties are, which jurisdictions the parties live in, even which laws apply.
This said, I think nearly all new technologies have had uses some would not like. Gutenberg’s printing press was certainly not liked by the Catholic Church. Examples abound. But does this mean printing presses should be licensed or regulated?
There have usually been some unsavory or worse uses of new technologies (what’s unsavory to, say, the U.S.S.R. may not be unsavory to Americans). Birth control information was banned in Ireland, Saudi Arabia, etc. Examples abound: weapons, fire, printing press, telephones, copier machines, computers, tape recorders.
**CoinDesk: Is there a blockchain or cryptocurrency that’s doing it right? Is bitcoin, in your opinion, getting its own vision right?**
**Tim** As I said, bitcoin is basically doing what it was planned to do. Money can be transferred, saved (as bitcoin), even used as a speculative vehicle. The same cannot be said for dozens of major variants and hundreds of minor variants where a clear-cut, understandable “use case” is difficult to find.
Talk of “reputation tokens,” “attention tokens,” “charitable giving tokens,” these all seem way premature to me. And none have taken off the way bitcoin did. Even ethereum, a majorly different approach, has yet to see interest uses (at least that I have seen, and I admit I don’t the time or will to spend hours every day following the Reddit and Twitter comments.)
“Blockchain,” now its own rapidly-developing industry, is proceeding on several paths: private blockchains, bank-controlled blockchains, pubic blockchains, even using the bitcoin blockchain itself. Some uses may turn out to be useful, but some appear to be speculative, toy-like. Really, marriage proposals on the blockchain?
The sheer number of small companies, large consortiums, alternative cryptocurrencies, initial coin offerings (ICOs), conferences, expos, forks, new protocols, is causing great confusion and yet there are new conferences nearly every week.
People jetting from Tokyo to Kiev to Cancun for the latest 3-5 days rolling party. The smallest only attract hundreds of fanboys, the largest apparently have drawn crowds of 8,000. You can contrast that with the straightforward roll-out of credit cards, or even the relatively clean roll-out of bitcoin. People cannot spend mental energy reading technical papers, following the weekly announcements, the contentious debates. The mental transaction costs are too high, for too little.
The people I hear about who are reportedly transferring “interesting” amounts of money are using basic forms of bitcoin or bitcoin cash, not exotics new things like Lightning, Avalanche, or the 30 to 100 other things.
**CoinDesk: It sounds like you’re optimistic about the value transfer use case for cryptocurrencies, at least then.**
**Tim** Well, it will be a tragic error if the race to develop (and profit from) the things that are confusingly called “cryptocurrencies” end up developing dossiers or surveillance societies such as the world has never seen. I’m just saying there’s a danger.
With “know your customer” regulations, crypto monetary transfers won’t be like what we have now with ordinary cash transactions, or even with wire transfers, checks, etc. Things will be \_worse\_ than what we have now if a system of “is-a-person” credentialing and “know your customer” governance is ever established. Some countries already want this to happen.
The “Internet driver’s license” is something we need to fight against.
**CoinDesk: That’s possible, but you could make a similar claim about the internet today isn’t exactly the same as the original idea, yet it’s still be useful in driving human progress.**
**Tim** I’m just saying we could end up with a regulation of money and transfers that is much the same as regulating speech. Is this a reach? If Alice can be forbidden from saying “I will gladly pay you a dollar next week for a cheeseburger today,” is this not a speech restriction? “Know your customer” could just as easily be applied to books and publishing: “Know your reader.” Gaaack!
I’m saying there are two paths: freedom vs. permissioned and centralized systems.
This fork in the road in the road was widely discussed some 25 years ago. Government and law enforcement types didn’t even really disagree: they saw the fork approaching. Today, we have tracking, the wide use of scanners (at elevators, chokepoints), tools for encryption, cash, privacy, tools for tracking, scanning, forced decryption, backdoors, escrow.
In a age where a person’s smartphone or computer may carry gigabytes of photos, correspondence, business information – much more than an entire house carried back when the Bill of Rights was written – the casual interception of phones and computers is worrisome. A lot of countries are even worse than the U.S. New tools to secure data are needed, and lawmakers need to be educated.
Corporations are showing signs of corporatizing the blockchain: there are several large consortiums, even cartels who want “regulatory compliance.”
It is tempting for some to think that legal protections and judicial supervision will stop excesses… at least in the US and some other countries. Yet, we know that even the US has engaged in draconian behavior (purges of Mormons, killings and death marches for Native Americans, lynchings, illegal imprisonment of those of suspected Japanese ancestry).
What will China and Iran do with the powerful “know your writers” (to extend “know your customer” in the inevitable way)?
**CoinDesk: Are we even talking about technology anymore though? Isn’t this just power and the balance of power. Isn’t there good that has come from the internet even if it’s become more centralized?**
**Tim** Of course, there’s been much good coming out of the Internet tsunami.
But, China already uses massive databases – with the aid of search engine companies – to compile “citizen trustworthiness” ratings that can be used to deny access to banking, hotels, travel. Social media corporate giants are eagerly moving to help build the machinery of the Dossier Society (they claim otherwise, but their actions speak for themselves).
Not to sound like a Leftist ranting about Big Brother, but any civil libertarian or actual libertarian has reason to be afraid. In fact, many authors decades ago predicted this dossier society, and the tools have jumped in quantum leaps since then
In thermodynamics, and in mechanical systems, with moving parts, there are “degrees of freedom.” A piston can move up or down, a rotor can turn, etc. I believe social systems and economies can be characterized in similar ways. Some things increase degrees of freedom, some things “lock it down.”
**CoinDesk: Have you thought about writing something definitive on the current crypto times, sort of a new spin on your old works?**
**Tim** No, not really. I spent a lot of time in the 1992-95 period writing for many hours a day. I don’t have it in me to do this again. That a real book did not come out of this is mildly regrettable, but I’m stoical about it.
**CoinDesk: Let’s step back and look at your history. Knowing what you know about the early cypherpunk days, do you see any analogies to what’s happening in crypto now?**
**Tim** About 30 years ago, I got interested in the implications of strong cryptography. Not so much about the “sending secret messages” part, but the implications for money, bypassing borders, letting people transact without government control, voluntary associations.
I came to call it “crypto anarchy” and in 1988 I wrote “The Crypto Anarchist Manifesto,” loosely-based in form on another famous manifesto. And based on “anarcho-capitalism,” a well-known variant of anarchism. (Nothing to do with Russian anarchists or syndicalists, just free trade and voluntary transactions.)
At the time, there was one main conference – Crypto – and two less-popular conferences – EuroCrypt and AsiaCrypt. The academic conferences had few if any papers on any links to economics and institutions (politics, if you will). Some game theory-related papers were very important, like the mind-blowing “Zero Knowledge Interactive Proof Systems” work of Micali, Goldwasser and Rackoff.
I explored the ideas for several years. In my retirement from Intel in 1986 (thank you, 100-fold increase in the stock price!), I spent many hours a day reading crypto papers, thinking about new structures that were about to become possible.
Things like data havens in cyberspace, new financial institutions, timed-release crypto, digital dead drops through steganography, and, of course, digital money.
Around that time, I met Eric Hughes and he visited my place near Santa Cruz. We hatched a plan to call together some of the brightest people we knew to talk about this stuff. We met in his newly-rented house in the Oakland Hills in the late summer of 1992.
**CoinDesk: You mentioned implications for money… Were there any inclinations then that something like bitcoin or cryptocurrency would come along?**
**Tim:** Ironically, at that first meeting, I passed out some Monopoly money I bought at a toy store. (I say ironically because years later, when bitcoin was first being exchanged in around 2009-2011 it looked like play money to most people – cue the pizza story!)
I apportioned it out and we used it to simulate what a world of strong crypto, with data havens and black markets and remailers (Chaum’s “mixes”) might look like. Systems like what later became “Silk Road” were a hoot. (More than one journalist has asked me why I did not widely-distribute my “BlackNet” proof of concept. My answer is generally “Because I didn’t want to be arrested and imprisoned.” Proposing ideas and writing is protected speech, at least in the U.S. at present.)
We started to meet monthly, if not more often at times, and a mailing list rapidly formed. John Gilmore and Hugh Daniel hosted the mailing list. There was no moderation, no screening, no “censorship” (in the loose sense, not referring to government censorship, of which of course there was none.) The “no moderation” policy went along with “no leaders.”
While a handful of maybe 20 people wrote 80 percent of the essays and messages, there was no real structure. (We also thought this would provide better protection against government prosecution).
And of course this fits with a polycentric, distributed, permission-less, peer to peer structure. A form of anarchy, in the “an arch,” or “no top” true meaning of the word anarchy. This had been previously explored by David Friedman, in his influential mid-70s book “The Machinery of Freedom.” And by Bruce Benson, in “The Enterprise of Law.
He studied the role of legal systems absent some ruling top authority. And of course anarchy is the default and preferred mode of most people—to choose what they eat, who they associate with, what the read and watch. And whenever some government or tyrant tries to restrict their choices they often finds way to route around the restrictions: birth control, underground literature, illegal radio reception, copied cassette tapes, thumb drives ….
This probably influenced the form of bitcoin that Satoshi Nakamoto later formulated.
**CoinDesk: What was your first reaction to Satoshi’s messages, do you remember how you felt about the ideas?**
**Tim:** I was actually doing some other things and wasn’t following the debates. My friend Nick Szabo mentioned some of the topics in around 2006-2008. And like a lot of people I think my reaction to hearing about the Satoshi white paper and then the earliest “toy” transactions was only mild interest. It just didn’t seem likely to become as big as it did.
He/she/they debated aspects of how a digital currency might work, what it needed to make it interesting. Then, in 2008, Satoshi Nakamoto released “their” white paper. A lot of debate ensued, but also a lot of skepticism.
In early 2009 an alpha release of “bitcoin” appeared. Hal Finney had the first bitcoin transaction with Satoshi. A few others. Satoshi himself (themselves?) even said that bitcoin would likely either go to zero in value or to a “lot.” I think many were either not following it or expected it would go to zero, just another bit of wreckage on the Information Superhighway.
The infamous pizza purchase shows that most thought of it as basically toy money.
**CoinDesk: Do you still think it’s toy money? Or has the slowly increasing value sort of put that argument to rest, in your mind?**
**Tim:** No, it’s no longer just toy money. Hasn’t been for the past several years. But it’s also not yet a replacement for money, for folding money. For bank transfers, for Hawallah banks, sure. It’s functioning as a money transfer system, and for black markets and the like.\]
I’ve never seen such hype, such mania. Not even during the dot.com bubble, the era of Pets.com and people talking about how much money they made by buying stocks in “JDS Uniphase.” (After the bubble burst, the joke around Silicon Valley was “What’s this new start-up called “Space Available”?” Empty buildings all around.)
I still think cryptocurrency is too complicated…coins, forks, sharding, off-chain networks, DAGs, proof-of-work vs. proof-of-stake, the average person cannot plausibly follow all of this. What use cases, really? There’s talk about the eventual replacement of the banking system, or credit cards, PayPal, etc. is nice, but what does it do NOW?
The most compelling cases I hear about are when someone transfers money to a party that has been blocked by PayPal, Visa (etc), or banks and wire transfers. The rest is hype, evangelizing, HODL, get-rich lambo garbage.
**CoinDesk: So, you see that as bad. You don’t buy the argument that that’s how things get built though, over time, somewhat sloppily…**
**Tim:** Things sometimes get built in sloppy ways. Planes crash, dams fail, engineers learn. But there are many glaring flaws in the whole ecology. Programming errors, conceptual errors, poor security methods. Hundreds of millions of dollars have been lost, stolen, locked in time-vault errors.
If banks were to lose this kind of my money in “Oops. My bad!” situations there’d be bloody screams. When safes were broken into, the manufacturers studied the faults — what we now call “the attack surface” — and changes were made. It’s not just that customers — the banks — were encouraged to upgrade, it’s that their insurance rates were lower with newer safes. We desperately need something like this with cryptocurrencies and exchanges.
Universities can’t train even basic “cryptocurrency engineers” fast enough, let alone researchers. Cryptocurrency requires a lot of unusual areas: game theory, probability theory, finance, programming.
Any child understands what a coin like a quarter “does,” He sees others using quarters and dollar bills and the way it works is clear.
When I got my first credit card I did not spend a lot of time reading manuals, let alone downloading wallets, cold storage tools or keeping myself current on the protocols. “It just worked, and money didn’t just vanish.
**CoinDesk: It sounds like you don’t like how innovation and speculation have become intertwined in the industry…**
**Tim:** Innovation is fine. I saw a lot of it in the chip industry. But we didn’t have conferences EVERY WEEK! And we didn’t announce new products that had only the sketchiest ideas about. And we didn’t form new companies with such abandon. And we didn’t fund by “floating an ICO” and raising \$100 million from what are, bluntly put, naive speculators who hope to catch the next bitcoin.
Amongst my friends, some of whom work at cryptocurrency companies and exchanges, the main interest seems to be in the speculative stuff. Which is why they often keep their cryptocurrency at the exchanges: for rapid trading, shorting, hedging, but NOT for buying stuff or transferring assets outside of the normal channels.
**CoinDesk: Yet, you seem pretty knowledgeable on the whole about the subject area… Sounds like you might have a specific idea of what it “should” be.**
**Tim:** I probably spend way too much time following the Reddit and Twitter threads (I don’t have an actual Twitter account).
What “should” it be? As the saying goes, the street will find its own uses for technology. For a while, Silk Road and its variants drove wide use. Recently, it’s been HODLing, aka speculating. I hear that online gambling is one of the main uses of Ethereum. Let the fools blow their money.
Is the fluff and hype worth it? Will cryptocurrency change the world? Probably. The future is no doubt online, electronic, paperless.
But bottom line, there’s way too much hype, way too much publicity and not very many people who understand the ideas. It’s almost as if people realize there’s a whole world out there and thousands start building boats in their backyards.
Some will make, but most will either stop building their boats or will sink at sea.
We were once big on manifestos, These were ways not of enforcing compliance, but of suggesting ways to proceed. A bit like advising a cat… one does not command a cat, one merely suggests ideas, which sometimes they go with.
**Final Thoughts:**
- Don’t use something just because it sounds cool…only use it if actually solves some problem (To date, cryptocurrency solves problems for few people, at least in the First World).
- Most things we think of as problems are not solvable with crypto or any other such technology (crap like “better donation systems” are not something most people are interested in).
- If one is involved in dangerous transactions – drugs, birth control information – practice intensive “operational security”….look at how Ross Ulbricht was caught.
- Mathematics is not the law
- Crypto remains very far from being usable by average people (even technical people)
- Be interested in liberty and the freedom to transact and speak to get back to the original motivations. Don’t spend time trying to make government-friendly financial alternatives.
- Remember, there are a lot tyrants out there.