I’m a big fan of meetups, with our first Zurich Bitcoin Meetup all the way back in 2011, with just 4 people attending, more on that another time.
The Zurich Bitcoin meetups have become far more popular and better organized, thanks to Lucas, who has been organizing the locations and speakers.
And so it was my turn to speak about my research at the latest Meetup:
The talk has quite a large introduction about how Bitcoin works and why it does not scale. In the second part we talk about Duplex Micropayment Channels, how Payment Service Providers could emerge to build a fast payment network on top of Bitcoin and what some of the remaining challenges are.
I had a lot of fun, and it is always nice to have such an interested crowd. If you get a chance to give a talk at a meetup, go for it.
In the talk I said that most of this information is in my dissertation, so for those who would like to read up on these technologies the dissertation is available at Amazon: On The Scalability and Security of Bitcoin.
Git is a really cool version control system. So cool in fact that I decided to use it to distribute the project I’m working on to several hundreds of Planetlab nodes. So I went ahead and created a repository with git init --bare somewhere in under the root of my local Apache2. Using pssh we can clone and pull from the repository simply by specifying the URL to that repo.
Obviously the traffic is still pretty high, after all every request still ends up at my machine, so I have to serve the whole repository once for each machine. Then I stumbled over CoralCDN, a free Content Distribution Network, that runs on Planetlab. So instead of cloning directly from my machine I took the URL of the repo, added .nyud.net to the domain and cloned from that URL instead.
The drop in traffic when cloning was immediate and I was happily working with this setup, for some time. Then I noticed that having the CDN cache the contents has its drawbacks: if I want to push changes quickly one after another, say, because I noticed a typo just after issuing the update, I have to wait for the cache to time out.
To solve this problem we have to set the objects files, which do not change because it is part of gits content addressable design, and set a short caching time for the few files that do change. Placing this .htaccess file in the repository and activating mod_headers and mod_expires should do the trick:
It’s an amazing time to be part of the Bitcoin family. With the Wikileaks scandal we had some quite heated discussions on whether to promote ourselfs as an alternative way for them to acquire funds, but in the end we decided not to, preferring not to be associated with a company being investigated by some countries. However the decision seems to have already been taken for us: as this article in PCWorld demonstrates we are not the only ones making that connection.
Furthermore people are investing more and more resources into Bitcoin as the confidence in the future of the currency grows. Currently the Bitcoin economy containing 4’464’000 coins is worth just short of 1 million USD (MtGox). Meanwhile the growing interest increased the difficulty to generate blocks (the means to acquire new coins and confirm transactions) to incredible heights, and newcomers are getting frustrated at how long it takes them to earn their first real coins. Luckily the Bitcoin Faucet and a pooled mining effort should counteract part of this problem, but the trend is quite clear, people that do not invest heavily into GPUs are will have nearly no chance at accumulating large quantities just by mining, but then where does a country just give you freshly printed money?
In the meantime a lot of discussion is going on about improvements to the Protocol, and what should be part of the Bitcoin ecosystem, specifically an alternative DNS system is in discussion, which would piggyback on the currency transactions.
I’ve been bothered with the now famous PermGen Space error while developing a web application on a local jetty instance quite often, and I was hoping that the problem wouldn’t prove to be that serious once deployed on a tomcat server, but quite the opposite is the case.
The problem happens when the JVM runs out of permanent generation heap space, which most of the time is due to classloaders not being correctly garbage collected. Permanent generation heap space is an optimization that the Sun JVM contains to speed up object creation, but the default size is too small if classes are loaded and unloaded often during runtime, which is exactly the mechanism most application servers load applications. So the first, quick and dirty, solution would be to enlarge the permanent generation heap space: -XX:MaxPermSize=256m. Sadly, this still doesn’t get rid of the problem. Another solution is to use a completely different JVM altogether: JRockit.
JRockit, a proprietary Java Virtual Machine (JVM) from BEA Systems, became part of Oracle Fusion Middleware in 2008. Many JRE class files distributed with BEA JRockit exactly replicate those distributed by Sun. JRockit overrides class files which relate closely to the JVM, therefore retaining API compatibility while enhancing the performance of the JVM. [from Wikipedia]
I wasn’t thrilled having to change JVM because it isn’t available in the openSuse repositories at all, and I wasn’t quite sure how hard it would be to make the switch. As I found out, it’s incredibly easy.
Getting the package
Getting your hands on the JRockit installation package isn’t all that easy, because BEA became part of Oracle and everything is still in transition. The download location is http://edelivery.oracle.com/, where you’ll be greated by a wizard to select the products to download. JRockit can be found under BEA Products and then BEA WebLogic Media Pack, scrolling down you’ll find the zip package you need depending on your operating system.
Installation is straight forward, just unzip the archive and then execute the contained installer:
Now all you have to do is follow the instructions of the installer. When asked for a location to install JRockit into, I used /opt/jrockit but every location will do just fine. The next step is optional, but if you use update-alternatives I strongly suggest you to do it. We’ll add jrockit java and the the jrockit compiler (javac) as alternatives:
So when doing an update-alternives we see the jrocki VM:
$ update-alternatives --config java
There are 2 programs which provide `java’.
+ 1 /usr/lib64/jvm/jre-1.6.0.u7-sun/bin/java
* 2 /opt/jrockit/bin/java
Enter to keep the default[*], or type selection number: so now we can easily switch between the Sun VM and the JRockit VM. That’s it. Now just check to see if we really have the JRockit VM and we’re ready to code:
$ java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
BEA JRockit(R) (build R27.5.0-110_o-99226-1.6.0_03-20080528-1505-linux-ia32, compiled mode)