Archive for the ‘crypto’ Category

It has long been known that much of the resources for Tor are provided by US spy agencies. Which is not necessarily a bad thing, since they might want a means for communicating that no one can spy on.

However, Lucky Green, a key figure in the privacy community, has issued a warrant canary – what you issue when you are forbidden to tell people you have had a warrant served on you.

The canary fails to tell us that a US spy agency is inside his servers in a way that tells us that a US spy agency now is inside his servers and a many other Tor servers.

In a warrant canary, you say what you are forbidden to say by failing to say things that you would otherwise be expected to say.

This inclines me to Moldbug’s solution, assuming his interpreter and compiler can be sufficiently small and self contained that one can make sure that everyone runs the same one. But if the interpreter and compiler exceed sixteen thousand lines, then defending them against this sort of attack becomes difficult.

The world is moving to cloud computing – which means that the world is moving to giant megacorps that are excessively cozy with the government owning all your data.

Which, as general David Petraeus discovered, can be really bad for you. Google tipped off his enemies, not by reading his email, though they did read his email, but by tracking where he was when he logged in to gmail. Which is why Hillary likes to keep her email server’s database on a thumb drive that she personally controls. Supposedly this is bad for national security, but I am pretty sure it is mighty good for Hillary’s security.

Urbit is intended to fix this:

Your urbit is a personal server: a persistent virtual computer in the cloud that you own, trust, and control.

Unfortunately urbit is also a language, a rather weird language, and a language that is interpreted rather than compiled.

A compiler can compile itself, and usually does. An interpreter cannot interpret itself.

Urbit, as a language, is kind of like Haskell as a language. Except that Haskell has a compiler, which is a huge advantage.

Let us suppose you want to multiply two times three in Haskell:

Well if you multiply two by three in C++, the compiler generates code that loads the number two into a register, loads the the number three into another register, multiplies the registers together, then stores the result where you tell it to store it.

If you multiply two by three in Haskell, the interpreter first creates a function to multiply any number by two, then applies that function to the number three, and it does not store the result. Which means if you have any non trivial program, it is pretty hard to figure out what the program is actually doing and how much time and memory space the task is going to take. Except that you can be pretty sure it is going to take more time and more memory space than doing it in C++.

Does anyone actually use anything written in Haskell? All alleged successful uses of Haskell are in-house usages – the man who uses the program is the man who wrote the program. We don’t see someone writing something in Haskell, and then large numbers of other people using his software. If you google any standard language, you get lots of hits of people wrestling with vast amounts of data used by vast numbers of people. If you google functional languages, you get academics playing interesting and clever games for the entertainment of other academics.

I rather suspect that no one except Yarvin is likely to be able to write any large efficient program in Urbit.

In order for Urbit “your personal server on the cloud” to be useful, your personal server needs to provide tools that are the functional equivalent of blogging, tweeting, reddit, facebook, Github, email, the pirate bay, the silk road, ebay, and such. Tools whereby you can use your personal server to securely interact with other people.

Not seeing specs for such tools. Such tools seem like a lot of work.

The huge advantage of a language such as Urbit is that the cloud is inherently massively parallel, and Urbit is designed to be inherently adapted to massive parallelism. Your personal server on the cloud can scale – enormously. Which is more of an advantage if you are a giant corporation. And even so, giant corporations do not use such languages, because they are hard.

Something like Urbit is the right way to do things in a massively networked environment. But it is an enormous and difficult task. Writing a compiler would not be such a big job compared to all the other jobs that have to be done to make Urbit useful.

Urbit is a bright idea. It is a correct idea. But it is a really big job.

That outcomes are determined by weight of computing power (the miners) rather than weight of bitcoins owned has led to problems. The miners don’t face the same incentives as the people trying to do bitcoin based businesses.

Bitcoin has grown to about as large as it can get. It is doing about as many transactions as it can do, arguably rather more transactions that it is really suited for doing. Any fixes are at best small tune ups to get a little bit more performance out of the system, are at worst just burden shifting and burden hiding – hence the civil war. I have been trying to design a coin that could scale, by having a dispersed blockchain, where no one entity has to keep all transactions. You keep your own transactions, and summary information about entities you transact with, and summary aggregate information about all transactions, and the chain of hashes that links the ownership of your money and your transactions into the global hash, which chain would only grow as log of the total number of transaction, rather than grow with the total number of transactions. This means that parts of the blockchain will get lost temporarily or permanently, and the problem is to create a method for dealing with such losses that does not give anyone incentive to cause such losses, apart from the general deflation that such losses cause. Have been trying to design this for some time. Not making much progress these days.

Another solution, compatible with existing bitcoin is to have account based money built on top of bitcoin, bitcoin backed banks, analogous to gold backed banks. People are talking about this solution, but not actually implementing it, even though it seems a good deal easier than the solution that I proposed.

We are going to need a heavily decentralized solution, so that if a relatively small number of nodes get shut down or taken over by law enforcement, the network continues to function correctly, and, because no single node is central, no single node has traffic patterns that make it stand out.

The Tor hidden site system will always fail if a hidden site generates too much traffic for too long. We need a non Tor solution for publishing and curating reputations and performing transactions.

For bitcoin to work politically, authority over the currency needs to be distributed over a large group of peers. If power is concentrated at a single point, the state can dominate that point, whoever controls that point can steal other people’s currency and do a variety of bad things.

Bitcoin was designed so that “voting” depended on computing power and network connection. Initially, almost everyone who had a client was a miner, there were a huge number of miners, everyone who used bitcoin had roughly equal influence because they contributed roughly equal computing power to the block chain.

What we need is a crypto currency which is controlled by the top one hundred or so owners of the currency that are well connected to the net and have adequate computing power, with influence over the currency proportional to the amount of currency that they own, rather than the number of cycles that they burn.

In principle it should be possible to do this using bilinear maps, but the details are a bit tricky, because we have to make sure that manageable number of votes reflects an infinitely divisible currency whose ownership changes continually. So the shares (private and public keys in groups with a bilinear map) have to be reissued frequently, while ownership of the infinitely divisible currency is given value by the fact that if you own a lot of it, you get shares proportional to the amount you own. Since shareholders are people who own a lot of currency, they have an incentive to not misbehave, to continue to reissue shares according to currency ownership and validate transactions according to the rules, since to do otherwise would destroy the value of the currency that they own.

The number of shares remains manageably small, however many people use the currency and however many transactions take place. The shares underlie the value of the currency – and absolutely nothing underlies the value of the shares. Of course we still have other scaling problems, to which I have not figured out a solution except in alarmingly vague outline.

The government placed malware on Tor exit nodes, located the Silk Road servers, raided servers, game over.

Private messages should have been end to end encrypted, existing in the clear only on the computers of the sender and recipient, and should have been deniable, except for messages containing money, where the sender needed to be able to prove that the recipient account had received a message with a particular hash, and thus able to prove that the recipient account received a message with particular content including payment. (more…)