diff --git a/RELEASE_NOTES.html b/RELEASE_NOTES.html index b4e91c2..8143673 100644 --- a/RELEASE_NOTES.html +++ b/RELEASE_NOTES.html @@ -64,7 +64,7 @@ text-align: left;

Release Notes

To build and run README

-

pre alpha documentation (mostly a wish list)

+

pre alpha documentation (mostly a wish list) (In order to read these on this local system, you must first execute the document build script mkdocs.sh, with bash, sed and pandoc)

This software is pre alpha and should not yet be released. It does not work well enough to even show what it would do if it was working

diff --git a/docs/libraries.md b/docs/libraries.md index 25050b9..2692e93 100644 --- a/docs/libraries.md +++ b/docs/libraries.md @@ -210,12 +210,28 @@ is a much worse idea – it is the usual “embrace and extend” evil plot by Microsoft against open source software, considerably less competently executed than in the past. -## The standard gnu installer +## The standard gnu installer from source ```bash ./configure && make && make install ``` +## The standard cmake installer from source + +```bash +cmake .. && cmake --build && make && make install +``` + +To support this on linux, Cmakelists.txt needs to contain + +```default +project (Test) +add_executable(test main.cpp) +install(TARGETS test) +``` + +On linux, `install(TARGETS test)` is equivalent to `install(TARGETS test DESTINATION bin)` + ## The standard Linux installer `*.deb` @@ -271,40 +287,246 @@ But what about the menu for just one user? The documentation says `~/.local/share/applications`. Which I do not entirely trust. +### autotools + +Has a poorly documented and unexplained pipeline to `*.deb` files. +Plausibly `cmake` also has a pipeline, but I have not found it. + +autotools is linux standard, is said to have a straightforward pipeline +into making `*.deb` files, and everyone uses it, including most of your +libraries, but I hear it cursed as a complex mess, and no one wants to +get into it. They find the far from easy `cmake` easier. And `cmake` +runs on all systems, while autotools only runs on linux. + +I believe `cmake` has a straightforward pipeline into `*.deb` files, but if it has, the autotools pipleline is far more common and widely used. + ## The standard windows installer -Wix creating an `*.msi` file. +Requires an `*.msi` file. If the install is something other than an msi +file, it is broken. -Which `*.msi` file can be wrapped in an executable, but there is no sane -reason for this and you are likely to wind up with installs that consist of an -executable that wraps an msi that wraps an executable that wraps an msi. +[Help Desk Geek reviews tools for creating `*.msi`]: https://helpdeskgeek.com/free-tools-review/4-tools-to-create-windows-installer-packages/ +{target="_blank"} -To build an `*.msi`, you need to download the Wix toolset, which is referenced in the relevant Visual Studio extensions, but cannot be downloaded from within the Visual Studio extension manager. +[Help Desk Geek reviews tools for creating `*.msi`] -The Wix Toolset, however, requires the net framework in order to install it -and use it, which is the cobbler’s children going barefoot. You want a -banana, and have to install a banana tree, a monkey, and a jungle. +1. First and formost, Nullsoft Scriptable Install System (NSIS) Small, simple, and powerful. -There is a [good web page](https://stackoverflow.com/questions/1042566/how-can-i-create-an-msi-setup) on WIX resources +1. Last and least Wix and Wax: it requires the biggest learning + curve. You can create some very complex installers with it, but you’ll be coding quite a bit and using a command line often.\ + And word on the internet is that complex installs created with + Wix and Wax create endless headaches and even if you get it + working in your unit test environment, it then breaks your + customer's machine irreversibly and no one can figure out why. -There is an automatic wix setup: Visual Studio-> Tools-> Extensions&updates ->search Visual Studio Installer Projects +### [NSIS] Nullsoft Scriptable Install System -Which is the Microsoft utility for building wix files. It creates a quite adequate wix setup by gui, in the spirit of the skeleton windows gui app. +NSIS can create msi files for windows, and is open source. [NSIS]:https://nsis.sourceforge.io/Download -{target="blank"} +{target="_blank"} -## [NSIS] Nullsoft Scriptable Install System +[NSIS Open Source repository]:https://sourceforge.net/projects/nsis/files/NSIS%203/3.08/RELEASE.html/view +{target="_blank"} + +[NSIS Open Source repository] People who know what they are doing seem to use this open source install system, and they write nice installs with it. -But NSIS has not had any releases since 2019, and it looks that -updating has been minimal for several years before that. +Unlike `Wix`, I hear no whining that any attempt to use its power will +leave you buggered and hopeless. -# Package managers +When I most recently checked, the most recent release was thirty +five days previous, which is moderately impressive, given that their +release process is somewhat painful and arduous. -Lately, however, package managers have appeared: Conan and [vcPkg](https://blog.kitware.com/vcpkg-a-tool-to-build-open-source-libraries-on-windows/). Conan lacks wxWidgets, and has far fewer packages than [vcpkg](https://libraries.io/github/Microsoft/vcpkg). +### Wix + +`Wix` is suffering from bitrot. The wix toolset relies on a framework +that is no longer default installed on windows, and has not been for +a very very long time. + +But no end of people say that sucky though it is, it is the standard +way to create install files. + +[Hello World for Wix]:https://stackoverflow.com/questions/47970743/wix-installer-msi-not-installing-the-winform-app-created-with-visual-studio-2017/47972615#47972615 +{target="_blank"} + +[Hello World for Wix] is startling nontrivial. It does not default create +a minimal useful install for you. So even if you get it working, still +looks like it is broken. + +[Common Design Flaws]:https://stackoverflow.com/questions/45840086/how-do-i-avoid-common-design-flaws-in-my-wix-msi-deployment-solution +{target="_blank"} + +[Common Design Flaws] do not sound entirely like design flaws. It +sounds like it is easy to create `*.msi` files whose behaviour is +complex, unpredictable, unexpected, and apt to vary according to +circumstances on the target machine in incomprehensible and +unexpected ways. "Works great when we test it. Passes unit test." + +[Some practical Wix advice]:https://stackoverflow.com/questions/6060281/windows-installer-and-the-creation-of-wix/12101548#12101548 +{target="_blank"} + +[Some practical Wix advice] advises that trying to do anything +complicated on Wix is hell on wheels, and will lead to unending +broken installs out in the field that fuck over the target systems. + +While Wix in theory permits arbitrarily complex and powerful +installs, in practice, no one succeeds. + +"certain things are still coded on a case by case basis. These ad hoc +solutions are implemented as 'custom actions` in Windows Installer," + +And custom actions that involve writing anything other than file +properties, die horribly. + +Attempts to install Wix on Visual Studio repeatedly failed, and +sometimes trashed my Visual Studio installation. + +After irreversibly destroying Visual Studio far too many times, +attempted to install on a fresh clean virtual machine. + +Clean install of Visual Studio on a vm worked, loaded my project, +compiled and built it almost as fast as my real machine. The +program it built ran fine and passed unit test. And then Visual +Studio crashed on close. Investigating the hung Visual Studio, it had +freed up almost all memory, and then just stopped running. Maybe +the problem is not Wix bitrot, but Visual Studio bitrot, since I did +not even get as far as trying to install Wix. + +If the Wix installer is horribly broken, is it not likely that any install +created by Wix will be horribly broken? + +The Wix Toolset, requires the net framework 3.5 in order to install it +and use it, which is the cobbler’s children going barefoot. You want +a banana, and have to install a banana tree, a monkey, and a jungle. + +Network Framework 3.5.1 can be installed with Control +Panel/programs and programs/features. + +You have to install the extension after the framework in that order, +or else everything breaks. Or maybe everything just breaks anyway +far too often and people develop superstitions about how to avoid +such cases. + +## Choco + +Choco, Chocolatey, is the Windows Package manager system. Does not use `*.msi` as its packaging system. A chocolatey package consists of an `*.nuget`, `chocolateyInstall.ps1`, `chocolateyUninstall.ps1`, and `chocolateyBeforeModify.ps1` (the latter script is run before upgrade or uninstall, and is to reverse stuff done by is accompanying +`chocolateyInstall.ps1 `) + +Interaction with stuff installed by `*.msi` is apt to be bad. + +The community distribution redirects requests to particular servers, +which have to be maintained by particular people - which requires +an 8GB ram, 50GB disk Windows server. I could have `nginx` in the +cloud reverse proxying that to a physically local server over +wireguard, which solves the certificate problem, or I could use a +commercial service, which is cheap, but leaks identity all over the +place and is likely to be subject to hostile interdiction and state sponsored identity theft. + +Getting on the `choco` list is largely automatic. Your package has to +install on their standard image, which is a deliberately obsolete +2012 windows server - and your install script may have to install +windows update packages. Your package is unlikely to successfully +install until you have first tested it on an imitation of their test +environment, which is a great deal of work and skill to set up. +Human curation exists, but is normally routine and superficial. +Installs, has license, done. + +[whole lot more checks]:https://docs.chocolatey.org/en-us/information/security#chocolatey.org-packages +{target="_blank"} + +[whole lot more rules]:https://docs.chocolatey.org/en-us/community-repository/moderation/package-validator/rules/ +{target="_blank"} + +Well, actually there are a [whole lot more checks], which enforce a [whole lot more rules], sixty eight rules and growing, but they are robotically checked and the outcome reported to human. If the robot OKs it, it normally goes through automatically into the community distribution. + +A Choco package is immutable. Can be superseded, but cannot +change. Could have the program check for a Zooko signature of its package file against a list, and look for indications of broad +approval, thus solving the identity problem and eating my own dogfood. + +Choco packages would be very handy to automatically install my build environment. +### Cmake + +`cmake` has a pipeline for building choco files. + +[wxWidgets has instructions for building with Cmake]:https://docs.wxwidgets.org/trunk/overview_cmake.html +{target="_blank"} + +[wxWidgets has instructions for building with Cmake]. My other +libraries do not, and require their own idiosyncratic build scripts, +and I doubt that I can do what the authors were disinclined to do. +Presumably I could fix this with `add_custom_target` and +`add_custom_command`, where the custom command is bash script +that just invokes the author's scripts, but I just do not understand +the documentation for these commands, which documentation + resupposes knowledge of the incomprehensible domain specific language. + +`Cmake` runs on both Windows and Linux, and is a replacement for autotools, that runs only on Linux. + +Going with `cmake` means you have a defined standard cross platform development environment, `vscode` which is wholly open source, and a defined standard cross platform packaging system, or rather four somewhat equivalent standard packaging systems, two for each platform. + +Instead of + +```bash +./configure +make +make install +``` + +We have + +```bat +cmake .. +cmake --build . +cmake --install . +``` + +`cmake --install` installs from source, and has a pipeline (`cpack`) +to generate `*.msi` through [NSIS]. Notice it does *not* have a pipeline +through Wix and Wax. It also has a pipeline to Choco, and, on linux, +to `*.deb` and `*.rpm`. + +No uninstall, which has to be hand written for your distribution. + +`cmake` has the huge advantage that with certain compilers, far from +all of them, it integrates with the vscode ide, including a graphical +debugger that runs on both windows and linux. Which otherwise +you really do not have on linux. + +It thus provides maximum cross platform portability. On the other +hand, all of my libraries rely on `.configure && make && make install` +on linux, and on visual studio on Windows. In my previous +encounter with `cmake`, I found mighty good reason for doing it that +way. The domain specific language of `CMakeLists.txt` is arcane, +unreadable, unwriteable, and subject to frequent, arbitrary, +inconsistent, and illogical ad hoc change. It inexplicably does +remarkably complicated things without obvious reason or purpose, +which strange complexity usually does things you do not want. + +Glancing through their development blog, I keep seeing major +breaking changes being corrected by further major breaking +changes. Internals are undocumented, subject to surprising change, +and likely to change further, and you have to keep editing them, +without any clearly knowable boundary between what is internal +stuff that you should not need to look at and edit, and what is the +external language that you are supposed to use to define what +`cmake` is supposed to accomplish. It is not obvious how to tell `cmake` to do a certain thing, and looking at a `CmakeLists.txt` file, not at all obvious what `cmake` is going to do. And when the next +version comes out, probably going to do something different. + +But allegedly the domain specific language of `./configure` has +grown a multitude of idiosyncrasies, making it even worse. + +`ccmake` is a graphical tool that will do some editing of +`CMakeLists.txt` with respect for the mysterious undocumented +arcane syntax of the nowhere explained or documented domain +specific language. + +# Library Package managers + +Lately, however, library package managers have appeared: Conan and [vcPkg](https://blog.kitware.com/vcpkg-a-tool-to-build-open-source-libraries-on-windows/). Conan lacks wxWidgets, and has far fewer packages than [vcpkg](https://libraries.io/github/Microsoft/vcpkg). I have attempted to use package managers, and not found them very useful. It is easier to deal with each package as its own unique special case. The diff --git a/docs/libraries/review_of_crypto_libraries.md b/docs/libraries/review_of_crypto_libraries.md index 93860b3..9141f3f 100644 --- a/docs/libraries/review_of_crypto_libraries.md +++ b/docs/libraries/review_of_crypto_libraries.md @@ -4,15 +4,249 @@ title: Review of Cryptographic libraries # Noise Protocol Framework -[Noise](https://noiseprotocol.org/) is an architecture and a design document, - not source code. Example source code exists for it, though the [C example] -(https://github.com/rweather/noise-c) uses a build architecture that may not -fit with what you want, and uses protobuf, while you want to use Cap’n -Proto or roll your own serialization. It also is designed to use several -different implementations of the core crypto protocols, one of them being -libsodium, while you want a pure libsodium only version. It might be easier -to implement your own version, using the existing version as a guide. -Probably have to walk through the existing version. +The Noise Protocol Framework matters because used by Wireguard to do something related to what we intend to accomplish. + +Noise is an already existent messaging protocol, implemented in +Wireguard as a UDP only protocol. + +My fundamental objective is to secure the social net, particularly the +social net where the money is, the value of most corporations being +the network of customer relationships, employee relationships, +supplier relationships, and employee roles. + +This requires that instead of packets being routed to network +addresses identified by certificate authority names and the domain +name system, they are routed to public keys that reflect a private +key derived from the master secret of a wallet. + +## Wireguard Noise + +Wireguard maps network addresses to public keys, and then to the +possessor of the secret key corresponding to that public key. We +need a system that maps names to public keys, and then packets to +the possessor of the secret key. So that you can connect to service +on some port of some computer, which you locate by its public key. + +Existing software looks up a name, finds an thirty two bit or one +twenty eight bit value, and then connects. We need that name to +map through software that we control to a durable and attested +public key, which is then, for random strangers not listed in the conf +file, locally, arbitrarily and temporarily mapped into Wireguard +subnets , which mapping is actually a local and temporary handle to +that public key, which is then mapped back to the public key, which +is then mapped to the network address of the actual owner of that +secret key by software that we control. So that software that we do +not control thinks it is using network addresses, but is actually using +local handles to public keys which are then mapped to network +address supported by our virtual network card, which sends them off, +encapsulated in Wireguard style packets identified by the public +key of their destination to a host in the cloud identified by its actual +network address, which then routes them by public key, either to a +particular local port on that host itself by public key, or to another +host by public key which then routes them eventually by public key +to a particular port. + +For random strangers on the internet, we have to in effect NAT +them into our Wireguard subnets, and we don't want them able to +connect to arbitrary ports, so we in effect give them NAT type port forwarding. + +It will frequently be convenient to have only one port forwarded +address per public key, in which case our Wireguard fork needs to +accept several public keys, one for each service. + +The legacy software process running on the client initiates a +connection to a name and a port, from a random client port. The +legacy server process receives it on the whitelisted port ignoring +the port requested, if only one incoming port is whitelisted for +this key, or to the requested whitelisted port if more than one port +is whitelisted. It replies to the original client port, which was +encapsulated, with the port being replied to encapsulated in the +message secured and identified by public key, and the receiving +networking software on the client has temporarily whitelisted that +client port for messages coming from that server key. Such +"temporary" white listing should last for a very long time, since we +might have quiet but very long lived connections. We do not want +random people on the internet messaging us, but we do want people +that we have messaged to randomly messaging at random times the +service that message them. + +One confusing problem is that stable ports are used to identify a +particular service, and random ports a particular connection, and we +have to disentangle this relationship and distinguish connection +identifiers, from service identifiers. We would like public keys to +identify services, rather than hosts but sometimes, they will not. + +Whitelist and history helps us disentangle them when connecting to +legacy software, and, within the protocol, they need to be +distinguished even though they will be lumped back together when +talking to legacy software. Internally, we need to distinguish +between connections and services. A service is not a connection. + +Note that the new Google https allows many short lived streams, +hence many connections, identified by a single server service port +and a single random client port, which ordinarily would identify a +single connection. A connection corresponds to a single concurrent +process within client software, and single concurrent process within +server software, and many messages may pass back and forth between +these two processes and are handled sequentially by those +processes, who have retrospective agreement about their total shared state. + +So we have four very different kinds of things, which old type ports +mangle together + +1. a service, which is always available as long as the host is up + and the internet is working, which might have no activity for + a very long time, or might have thousands of simultaneous + connections to computers from all over the internet +1. a connection, which might live while inactive for a very long time, + or might have many concurrent streams active simultaneously +1. a stream which has a single concurrent process attached to it + at both ends, and typically lives only to send a message and + receive a reply. A stream may pass many messages back and + forth, which both ends process sequentially. If a stream is + inactive for longer than a quite short period, it is likely to be + ungracefully terminated. Normally, it does something, and + then ends gracefully, and the next stream and the next + concurrent process starts when there is something to do. While a stream lives, both ends maintain state, albeit in a + request reply, the state lives only briefly. +1. A message. + +Representing all this as a single kind of port, and packets going +between ports of a single kind, inherently leads to the mess that we +now have. They should have been thought of as different derived +classes with from a common base class. + +[Endpoint-Independent Mapping]:https://datatracker.ietf.org/doc/html/rfc4787 +{target="_blank"} + +Existing software is designed to work with the explicit white listing +provided by port forwarding through NATs with [Endpoint-Independent Mapping], +and the implicit (but inconveniently +transient) white listing provided by NAT translation, so we make it +look like that to legacy software. To legacy client software, it is as if +sending its packets through a NAT, and to legacy server software, it +is sending its packets through a NAT with port forwarding. Albeit +we make the mapping extremely long lived, since we can rely on +stable identities and have no shortage of them. And we also want +the port mappings (actually internal port whitelistings, they would +be mappings if this was actual NAT) associated with each such +mapping to be extremely stable and long lived. + +[Endpoint-Independent Mapping] means that the NAT reuses the +address and port mapping for subsequent packets sent from the +same internal port (X:x) to any external IP address and port (Y:y). +X1':x1' equals X2':x2' for all values of Y2:y2, which our architecture +inherently tends to force unless we do something excessively clever, +since we should not muck with ports randomly chosen. For us, [Endpoint-Independent Mapping] means that the mapping between +external public keys of random strangers not listed in our +configuration files, and the internal ranges of the Wireguard fork +interface is stable, very long lived and *independent of port numbers*. + +## Noise architecture + +[Noise](https://noiseprotocol.org/) is an architecture and a design document, not source code. +Example source code exists for it, though the [C example] +(https://github.com/rweather/noise-c) uses a build architecture that +may not fit with what I want, and uses protobuf, enemy software. It +also is designed to use several different implementations of the +core crypto protocols, one of them being libsodium, while I want a +pure libsodium only version. It might be easier to implement my +own version, using the existing versions as a guide, in particular and +especially Wireguard's version, since it is in wide use. Probably have +to walk through the existing version. + +Noise is built around the ingenious central concept of using as the +nonce the hash of past shared and acknowledged data, which is +AEAD secured but sent in the clear. Which saves significant space +on very short messages, since you have to secure shared state +anyway. It regularly and routinely renegotiates keys, thus has no $2^{64}$ +limit on messages. A 128 bit hash sample suffices for the nonce, +since the nonce of the next message will reflect the 256 bit hash of +the previous message, hence contriving a hash that has the same +nonce does the adversary no good. It is merely a denial of service. + +I initially thought that this meant it had to be built on top of a +reliable messaging protocol, and it tends to be described as if it did, +but Wireguard uses a bunch of designs and libraries in its protocol, +with Noise pulling most of them together, and I need to copy, +rather than re-invent their work. + +On the face of it, Wireguard does not help with what I want to do. +But I am discovering a whole lot of low level stuff related to +maintaining a connection, and Wireguard incorporates that low level stuff. + +Noise goes underneath, and should be integrated with, reliable +messaging. It has a built in message limit of 2^16 bytes. It is not +just an algorithm, but very specific code. + +Noise is messaging code. Here now, and present in Wireguard, +as a UDP only cryptographic protocol. I need to implement my +messaging system as a fork of Wireguard. + +Wireguard uses base64, and my bright idea of slash6 gets in the +way. Going to use base52 for any purposes for which my bright idea +would have been useful, so should be rewritten to base64 regardless. + +Using the hash of shared state goes together with immutable +append only Merkle-patricia trees like ham and eggs, though you +don't need to keep the potentially enormous data structure around. +When a connection has no activity for a little while, you can discard +everything except a very small amount of data, primarily the keys, +the hash, the block number, the MTU, and the expected timings. + +The Noise system for hashing all past data is complicated and ad +hoc. For greater generality and more systematic structure, for a +simpler fundamental structure with fewer arbitrary decisions about +particular types of data, needs to be rewritten as hashing like an +immutable append only Patricia Merkle tree. Which instantly and +totally breaks interoperability with existing Wireguard, so to talk +to the original Wireguard, has to know what it is talking to. +Presumably Wireguard has a protocol negotiation mechanism, that +you can hook. If it does not, well, it breaks and the nature of the +thing that public key addresses has to be flagged anyway, since I +am using Ristretto public keys, and they are not. Also, have to move +Wireguard from NACL encryption to Libsodium encryption, because +NACL is an attack vector. + +Wireguard messages are distinguishable on the wire, which is odd, +because Noise messages are inherently white noise, and destination +keys are known in advance. Looks like enemy action by the bad guys at NACL. + +I think a fork that if a key is an legacy key type, talks legacy +wireguard, and if a new type (probably coming from our domain +name system), though it can also be placed in `.conf` files) talks +with packets indistinguishable from white noise to an adversary that +does not know the key. + +Old type session initiation messages are distinguishable from +random noise. For new type session initiation messages to a server +with an old type id and a new type id on the same port, make sure +that the new type session initiation packet does not match, which +may require both ends to try a variety of guesses if its expectations +are violated. Which opens a DOS attack, but that is OK. You just +shut down that connection. DOS resistance is going to require +messages readily distinguishable from random noise, but we don't +send those messages unless facing workloads suggestive of DOS, +unless under heavy session initiation load. + +Ristretto keys are uncommon, and are recognizable as ristretto +keys, but not if they are sent in unreduced form. + +Build on top a fork of Wireguard a messaging system that delivers +messages not to network addresses, but to Zooko names (which +might well map to a particular port on a particular host, but whose +network address and port may change without people noticing or caring.) + +Noise is a messaging protocol. Wireguard is a messaging protocol +built on top of it that relies on public keys for routing messages. +Most of the work is done. It is not what I want built, but it has an +enormous amount of commonality. I plan a very different +architecture, but that is a re-arrangement of existing structures +already done. I am going to want Kademlia and a blockchain for the +routing, rather than a pile of local text files mapping IPs to nameless +public keys. Wireguard is built on `.conf` text files the way the +Domain name system was built on `host` files. It almost does the job, +needs a Kamelia based domain name system on top and integrated with it. # [Libsodium](./building_and_using_libraries.html#instructions-for-libsodium) @@ -50,7 +284,7 @@ Amber library packages all these in what is allegedly easy to incorporate form, The fastest library I can find for pairing based crypto is [herumi](https://github.com/herumi/mcl).  -How does this compare to [Curve25519](https://github.com/bernedogit/amber)?  +How does this compare to [Curve25519](https://github.com/bernedogit/amber)? There is a good discussion of the performance tradeoff for crypto and IOT in [this Internet Draft](https://datatracker.ietf.org/doc/draft-ietf-lwig-crypto-sensors/), currently in IETF last call:  @@ -71,4 +305,4 @@ that document, nor any evaluations of the time required for pairing based cryptography in that document. Relic-Toolkit is not Herumi and is supposedly markedly slower than Herumi.  -Looks like I will have to compile the libraries myself and run tests on them.  \ No newline at end of file +Looks like I will have to compile the libraries myself and run tests on them. diff --git a/docs/social_networking.md b/docs/social_networking.md index b319b51..8aab0e7 100644 --- a/docs/social_networking.md +++ b/docs/social_networking.md @@ -16,7 +16,7 @@ We also have a crisis of shills, spamming, and scamming. [lengthy battleground report]: images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp "anon report_from people who tried to keep unmoderated discussion viable" -{target="blank"} +{target="_blank"} Here is a [lengthy battleground report] from some people who were on the front lines in that battle, and stuck it out a good deal longer than I did. @@ -825,6 +825,104 @@ to the stake. # Many sovereign corporations on the blockchain +We have to do something about the enemy controlling speech. No +namefag can mention or acknowledge any important truth, as more +and more things, even in science, technology, and mathematics, +become political. Global warming and recent horrifying ineffective +and dangerous vaccinations are just the tip of the iceberg – every +aspect of reality is being politicized. Our capability to monitor +reality is being rapidly and massively eroded. + +Among those capabilities, are bookkeeping and accounting, which +is becoming Environmental, Social, and Governance and is +increasingly detached from reality. The latter is an area of truth that +can get us paid for securing the capability to communicate truth. +Information wants to be free, but programmers want to be paid. + +Increasingly, the value of shares is not physical things, but "goodwill" + +Domino’s does not sell pizzas, and Apple does not sell computers. It +sets standards, and sells the expectation that stuff sold with its +brand name will conform to expectations. Domino's does not make the +pizza dough, does not make the pizzas. It sells the brand. + +The latest, and one of the biggest, jewels in Apple’s tech crown, at +the time of writing, is the M1 chip. Which is *designed* by Apple. It is +not *built* by Apple. And similarly if you buy a Domino’s pizza it was +cooked according to a Domino’s recipe from Domino’s approved +ingredients. But it was not cooked in a Domino’s owned oven, was +not cooked by a Domino’s employee, and it is unlikely that any of +the ingredients where ever anywhere near Domino’s owned +physical property or a Domino’s direct employee. Domino's does +not cook pizzas, and Apple does not build computers it. It designs +computers and set standards. + +Most businesses are in practice distributed over a network, and +their capital is less and less big centralized physical things like steel +refineries that can easily be found and coerced, and more and more +“goodwill”. “Goodwill” being the network of relationships and social +roles within the corporation and between its customers and +suppliers, and customer and supplier expectations of employee +roles enforced by the corporation. *This*, we can move to the +blockchain and protect from governments. + +A huge amount of what matters, a major proportion of the value +represented by shares, is in the social network. Which is +increasingly, like Apple and Google, scarcely attached to anything +physical and coercible, and is getting less and less attached. + +It mostly information, which is a present organized in a highly +coercible form. It does not have to be. + +There are a whole lot of government hooks into the corporation +associated with physical things, but as more and more capital takes +the form of “goodwill”, the most important hooks in the Global +American Empire are Human Resources and Accounting. + +We have to attach employee roles and brand names to individually +held unshared secrets, derived from a master secret of a master +wallet, rather than the domain name system. + +With SSL, governments can, and routinely do, seize that name, but +that is a flaw in the SSL design, the sort of thing blockchains were +originally invented to prevent. The original concept of an +immutable append only data structure, what we now call, not very +accurately, a blockchain, was invented to address this flaw in SSL, +though its first widely used useful application was bitcoin. It is now +way past time to apply it to its original design purpose. + +These days, most of the wealth of the world is no longer in physical +things, and increasingly companies are outsourcing that stuff to +large numbers of smaller businessmen, each of whom owns some +particular physical thing that is directly under his physical control, +and who are therefore hard for the state to coerce. One is more +likely to get shot when one attempts to coerce the actual owner +who is physically present on his property than when coercing his +employee who is supervising and guarding his property. And who +can switch from Dominoes at the cost of taking down one sign and +putting up another. (Also at the cost of confusing his customers.) +Uber does not own any taxis, nor move any passengers, and +Dominoes bakes no pizzas. Trucking companies are converging to +the Uber model. Reflect on the huge revolutionary problem the +Allende government got when attempting to coerce large numbers +of truckers who each owned their own truck. The coup was in large + part the army deciding it was easier and less disturbing to do + something about Allende than to do something about truckers. One + trucker is no problem. Many truckers are a problem. One Allende … + + The value of a business is largely the value of its social net of suppliers, customers, and employee roles. Our job is protecting social nets. Among them, social nets who will pay us. + + And with Information Epoch warfare looming, the surviving + governments will likely be those that are good at protecting their + social graph information from enemies internal and external, who + will enjoy ever increasing capability to reach out and kill one + particular man a thousand miles away. Though governments are + unlikely to pay us. They are going to try to make us pay them. And + in the end, we probably will, in return for safe locations where we + have freedom to operate. Which we will probably lease from + sovereign corporations who leased the physical facilities from + small owners, and the freedom to operate from governments. + ## source of corporateness State incorporated corporations derive their corporateness from the diff --git a/docs/tim_may_on_bitcoin.html b/docs/tim_may_on_bitcoin.html deleted file mode 100644 index 6ee9ed6..0000000 --- a/docs/tim_may_on_bitcoin.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - - Enough with the ICO-Me-So-Horny-Get-Rich-Quick-Lambo Crypto - - - - - - -

To Home page

-
-

Enough with the ICO-Me-So-Horny-Get-Rich-Quick-Lambo Crypto

-
-

CoinDesk asked cypherpunk legend Timothy May, author of the “Crypto Anarchist Manifesto,” 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 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:

- - - diff --git a/docs/white_paper.md b/docs/white_paper.md index ac6826f..3782dfd 100644 --- a/docs/white_paper.md +++ b/docs/white_paper.md @@ -265,7 +265,7 @@ So general Malloc might send general Bob the the message: > facing overwhelming enemy attack, falling back. You and general Dave may soon be cut off. -and general Dave the message: +and general Dave the message: > enemy collapsing. In pursuit. @@ -292,7 +292,7 @@ yields an advantage of least two to one in getting one’s way. This is a Byzantine fault. And if people get away with it, pretty soon no one is following process, and the capacity to act as one collapses. Thus process becomes bureaucracy. Hence today’s American State Department -and defense policy. Big corporations die of this, though states take longer +and defence policy. Big corporations die of this, though states take longer to die, and their deaths are messier. It is a big problem, and people, not just computer programs, fail to solve it all the time.