Sytse Sijbrandij

Apr 8, 2013

Lately bitcoins have quickly and steadily increased in value. With a market capitalization of over 2 billion US dollars many people must be trying to manipulate it. Most people are concerned that the discovery of a flaw in the bitcoin algorithm would sink its value. I think that the most likely thing to occur is the publication of a fake flaw that will temporarily sink its value.

It is very hard to find a real flaw in the bitcoin algorithm, many people have already tried and failed. It is much easier to publish a convincing looking paper about a supposed flaw that does not really exist. Such a paper would allow the manipulator to sink the value of bitcoins temporarily. The manipulator would than quickly buy bitcoins and wait for the discovery to be invalidated. After the invalidation the manipulator can sell the bought bitcoins at a higher price. Of course it would also be possible to buy options or futures to achieve the same effect.

It is very likely that a supposed flaw can have major effects on bitcoins. There are limited number of bitcoins and they devaluate. This causes people to hoard bitcoins with the intention of profiting from future value increases. The majority of bitcoins are in the hands of people with these intentions. The only things that these people are afraid of in the short term is a flaw in the algorithm and government action. The effects of other dangers such as the popularity of litecoins or a drop in public interest are much more gradual. The widespread publication of a supposed flaw would mean many bitcoins are racing for the exits at the same time, casing the exchange rate to free-fall.

The manipulation can happen in many forms. The manipulator can increase the profit if they take into account the following points. It is good to be previously active in the bitcoin community before publishing the supposed flaw. This will increase the legitimacy of the publication. Of course they would have to stay anonymous since the trading after the publication can be traced back to them. To prevent the trading being traced easily they can trade from multiple accounts on multiple exchanges connected to many bank accounts or other means of injecting and extracting value. The supposed flaw is published in a very public forum or even at multiple locations at the same time. The publication would coincide with the start of the most active trading hours on the exchanges so that it is possible to buy a lot of bitcoins without slowing down the free-fall too much. If the manipulator wants to do this without any accomplices a large amount of free cash and a scientific research background are probably required.

I'm long on bitcoins and one of the reasons of publishing this is to make sure the market is aware of the potential for fake papers about flaws in bitcoins.

Jan 10, 2013

Today I read a bit more about Javascript and JSON hijacking. JSON hijacking is nicely described in these articles:

One of the first reports Security statement

This problem exists because browsers don't check same origin policy on script tags.

Javascript hijacking is very similar to JSON hijacking. The difference is that the server returns executable javascript instead of an executable javascript object.

Rails is vulnerable to hijacking because the CSRF protection is not enabled for GET requests.

Apparently it is hard to address this problem. There is an old ticket for Rails but right now I see no easy solution in Rails or in rich client framweorks such as Ember.

Mitigation alternatives: - Don't send confidential data. - Send html snippets instead of JSON. - Send invalid data and parse it. - Use unguessable urls. - Use a token for authentication instead of a cookie. - Don't use GET requests. - Use a CSRF token and fail when it is not correct.

Jan 7, 2013

Today I solved an interesting problem in Ruby on Rails.

When I upgraded an application to a new rails version the application worked but some tests failed with "No route matches ". I couldn't figure out why. So I wanted to trace the failure down to a a specific rails commit.

I did this by using the following line in the Gemfile: gem 'rails', :git => "git://", :ref => "8af2fd889"

I varied the reference to track down the offencing commit and each time ran: bundle update rails && rspec rspec spec/controllers/example_controller_spec.rb

Normally I use git bisect but wouldn't know how to do this in case there is another repository causing the problems. I guess you have to point bundler to a local rails repo that you run git bisect in.

In the end the problem was that format parameter was not stringified in JSON requests due to rails commit:

To fix it I had to change: :format => format to 'format' => format

Oct 28, 2012

I think it is interesting how the evolution of computing has lead to many layers of storage and caching. As a developer you have to keep a mental model of all these layers. As an example below are the approximate latencies for an instance (server) using the different services offered by Amazon Web Services.

  1. CPU register: 0.3ns
  2. L1 cache: 1ns
  3. L2 cache: 3ns
  4. L3 cache: 10ns
  5. Main memory: 30ns
  6. Local SSD: 0.1 ms
  7. Local hard drive: 10ms
  8. Network drive (EBS): 20ms
  9. Object store (S3): 100ms
  10. Tape store (Glacier): 1 hour

Luckily we don't have to think about all of the above when we are developing an application. The first five layers (from the CPU register up to main memory) can just be thought of as memory for most of the time. And most developers don't use all services mentioned above, for example an instance on Amazon with SSD doesn't have a local hard drive.

On the other hand there are many caching layers that application developers have to think about that happen on top of the above layers:

  • Database caching (Redis and Memcache)
  • Page caching (Apache / Varnish)
  • Separate data centers and regions
  • Content Delivery Networks
  • Browser caching
  • Javascript executing (asynchronous and deferred)
  • Geographic latency (speed of light)
  • Routing latency (internet backbone)
  • Connection latency (mobile connections)

And there are even more complex techniques like HTTP streaming, precompiling assets, asynchronous code, client side framworks and websockets. In conclusion, there a lot of Matryoshka dolls to consider when building an application.

Update: Found this awesome time-slide overview of latencies.


Jan 13, 2004

This essay was also published in a book about MP3 and the digital music revolution by John Hedtke. Distributed by Top Floor Publishing with ISBN 0-9661032-4-6.

The internet is changing the world, and it doing that by taking down the walls that make up our normal society. Normally an artist has to give away his copyrights to get his music published and people had to sign Non Disclosure Agreements and pay cash to see the source of an OS. But thanks to the internet that's changing, everybody can set up a homepage a publish their mp3's and with Linux everybody can modify and distribute their own OS.

This scares the hell out of now days establishment and they try to stop it. The Rcaa trying to stop mp3 every way they can and Microsoft's halloween documents show they are really scared about opensource. But the injunction of the Rio and the modifying of protocols won't make the walls come back, intellectual freedom is here to stay.

Of course this freedom comes with some drawbacks, most notably the copying of illegal mp3's. Because of this the Rcaa started development of SDMI, a standard that would make it harder (but not impossible) to copy digital music. But this standard would also be much less flexible then mp3 (sharing it with friends, copying it to your car) and it would prevent little artists from distributing their music without a big record label. And that is what it's all about, the six big labels don't want an equal playing field because it would undermine their hold on the market.

But that's also why it shall fail, people want to be able to share their music, play it in their car or on their walkman. And little artists will continue to give away their music on and other sites. Not only because the want their music to be heard from an artist point of view but also with a business sense. Yes people, money can be made by giving your music away free. Just like Redhat makes money by giving their software away new record labels will make money by giving their software away. And artist will make money with advertising, concerts, T-shirts, limited edition songs, poems, fanclubs, email lists, commercials and many other creative ways.

When the dust settles down the big six record labels will have a lot more competition, from goodnoise and other digital labels and from the independent labels which finally have means of distribution. People will be able to access their music anytime, anywhere with minimal cost but great flexibility and service. Artist will retain their copyrights but will still have to work hard to get their music heard. But as a whole artists will earn more money while at the same time people will send less. Why is that? Well, it's due to one of the oldest business tactics, to cut out the middleman. Lawyers, cd-shops, cd-makers, distribution companies and all other people that higher the price of a cd; be afraid, be very afraid.

Jan 12, 2004

We have much more choices these days. We can learn anything we want. We can have friends all over the world. We can say whatever we want.

Indeed this is partly true. I can have another profession as my father. I can have a friend at the other side of the Atlantic. I can say what I want on my webpage.

But there is a stronger current below at this. That dictates how I should look. That dictates who my friends should be. That dictates what I should do with my live.

This current comes from the media. It's in beauty magazines. It's in films, music and all that's around us. It's in the minds of people all around us.

Such a thing isn't bad in itself. We know how to make quicker choices. We know what is expected of us. We know what to do when we don't have a clue.