I’m always interested when a new hardware wallet is announced. Naturally also for the keepkey. In contrast to most competitors, they didn’t take pre-orders. Instead they began to accept orders only when the product was finished and they were ready to ship. When they announced that the devices were finished and could be ordered, I was disappointed to find out that the price was a lot higher than I anticipated. It costs more than twice as much as a trezor. Since it also looks very shiny, I jokingly called it the iKeepKey.
Fast forward a few months, I packaged a new version of the trezor python library for debian. Since I knew that electrum also has a plugin for the keepkey, I figured I could just as well package the keepkey library to make the usage with electrum a bit more convenient for the owners of these devices on debian and its derivatives. The only thing I could verify without a device was that the option for the keepkey appeared when creating a new wallet with hardware support in electrum. Before I committ the package to debian propper, I wanted to be sure everything worked. So I sent an eMail to keepkey, asking if they could test my experimental package. Within hours I had an answer offering to send me a device free of charge. I couldn’t have hoped for so much generosity, but of course I happily agreed.
Today the parcel was delivered. The device is as shiny and good looking as it appears on the photos. It has a big, nicely readable screen that shows effects and animations. To host the bigger screen it naturally has to be signifficantly bigger than a trezor. The premium appearance doesn’t stop at the device itself, but also the woven cable, and the leather sleeve for storing the seed restoration card are very slick. I don’t know how much for the internals, but at least for the protocol, the trezor was used as a starting point. This is surely a very good choice.
There are other hardware wallets that descend from the trezor. But there is a big and important difference. The keepkey seems to be the only one so far that is trustworthy. The chinese clones such as bwallet or ewallet look good at first. But some people or even satoshilabs themselves were quick to point out that they didn’t properly sign their firmwares and did not release their source code. Effectively stealing the previous work and putting users at risk. In contrast to this, keepkey really play by the rules for the benefit of their users.
The card that comes with the keepkey, is about how to use it with a chrome browser plugin. I almost always prefer native applications over web apps. I try not to use chromium after a recent breach of trust. And it is not in the trisquel repositories anyway. So I want to operate it fully from within electrum. The last time I initialized a trezor, I’m pretty sure I had to use the firefox plugin. But in the meantime I noticed that the initialization part was added to the electrum plugin. So to initialize the keepkey in electrum I executed the following steps:
- File -> New/Restore
- provide a name for the new wallet
- Select “Create a new wallet” and “Hardware Wallet”
- Select “initialize a new or wiped device” and “KeepKey wallet”
- Select your preferred use of pin and password
- The keepkey shows some entropy information
- Enter your new pin twice using the same method as known from trezor
- Choose the number of words for your restore seed
- Write down the words for the seed (very important to store securely)
- And voila .. your keepkey electrum wallet is ready to use
Spending and everything I tested so far worked flawlessly. The operations work effectively the same way as with the trezor. But where appropriate it makes use of the bigger screen to show more information at once. So I guess I can start preparing my package for debian.
Here are some pictures to compare the size with other bitcoin hardware wallets:
More than a year ago, I blogged here about using RFID to track presence times in the BORM ERP system. I used the system a lot since then. But the BlinkM was really limited as the only immediate feedback channel. To use it with multiple users, a display was needed. The default Arduino compatible displays seemed a bit overpriced, and the Nokia phone that I disassembled didn’t have the same display as I used for the spectrum analyzer. But these displays are available for a bargain from china. The only problem was that the bifferboard didn’t have enough GPIO pins available to drive the “SPI plus extras” interface. But i2c was already configured for the BlinkM.
So, the most obvious solution was to use an AtMega8 as an intermediary. I defined a simple protocol and implemented it as i2c and uart on the AVR. I also wrote a small python class to interface it from the client side. As I buffer only one complete command, I had to add some delays in the python script to make sure the AVR can complete the command before the next one arrives. Apart from that, it all worked well when testing on an Alix or RaspberryPi. But i2c communication refused to work entirely when testing with the bifferboard. Not even i2cdetect could locate the device. That was bad, since I wanted to use it with the Bifferboard, and the other two were only for testing during the development. I checked with the oscilloscope, and found out that the i2c clock on the bifferboard runs with only 33kHz while the other two run at the standard 100kHz. So I tried to adjust the i2c clock settings on the AVR, as well as different options with the external oscillators and clock settings, but I was still still out of luck. Then I replaced the AtMega8 with an AtMega168 and it immediately worked. Next, I tried another AtMega8 and this one also worked with the Bifferboard. I switched back and forth and re-flashed them with the exact same settings. Still, one of them worked with all tested linux devices, while the other one still refused to work with the Bifferboard. So I concluded, one of these cheap AVR’s from china must be flaky, and I just used the other one. Seems like that’s what you get for one 6th of the price you pay for these chips in Switzerland.
Apart from the display, I also added an RGB LED that behaves like the BlinkM before. And on top of that a small piezo buzzer. But since I could hardly hear it’s sound when driven with 3.3V, I didn’t bother re-soldering it when it fell off.
Now, my co-workers also started logging their times with RFID.
The code is still on github.
I have created deb packages for a couple of years now. Primarily for software that I created myself, or was somehow involved. But sometimes I also packaged stuff that I just used, and wanted to be able to conveniently install and upgrade on different systems. One of these was printrun, a host software for reprap 3d printers. I packaged it, and provided packages for ubuntu in my ppa, and packages for debian in my own little repository. Then one day, Scott, a debian developer contacted me, asking if I was interested in getting the package to a state ready for inclusion in the official debian repository. The debian standards are very high, and so far, my packages didn’t need to meet those standards. But I wanted to improve my packaging skills anyway, and that looked like a great opportunity to learn from someone experienced. Continue reading “my first package in the official debian repository”
When I read this blog post telling that there are netbooks available from china for $65, where it is possible to install a proper linux distro, I knew I must have one. Yes, the specs are lowest end, but even more so is the price. It has a WonderMedia 8650 system on a chip. That’s an ARM CPU running at 800 MHz with 256MB RAM. These chips are normally used for low end tablets, and you see that with other things. The netbook has a 7 inch screen with 800*480 pixels and runs Android 2.2. So the device could be described as a tablet with a keyboard, touchpad, wifi, ethernet and three USB host ports, but no touchscreen, accelerometer, GPS, camera nor bluetooth.
From AliExpress, I ordered a device that seemed to be the same as mentioned in the blog. Continue reading “The cheapest netbook”
The raspberry pi, for those living under a rock, is the $25 linux pc that was announced big almost a year ago. It has a 700Mhz ARM CPU, 256MB RAM and an OpenGL ES capable GPU. To enable hardware hacking it comes with lots of GPIO pins. All in all about the performance of a premium smart phone from three years ago. But at $25 !!! The primary focus are school children, and the foundation wants to bring the fun on computing back to the children. Like every geek who read about it, I couldn’t wait to get one. First, the launch was scheduled for September or October, then postponed to February. The foundation decided they would outsource the shipping to some big electronics companies. They told them that a lot of people would try to get one of the first 10’000 boards, but still they weren’t prepared at all. The websites of the pi foundation as well as farnell and rs components were down the entire day. I got up earlier that day, hoping to be amongst the lucky ones. Later I signed up for a pre order somewhere in the queue for an upcoming batch. As with the first batch, each person could still order only one board. Then about a month ago, I received a mail indicating that it was time to place the order. And today I finally received it. Continue reading “Raspberry Pi – at last”
I wanted the robot arm to be a bit autonomous from the computer, and I thought the bifferboard should be powerful enough to drive it. So I wanted to install ROS onto it. My bifferboard runs debian squeeze, and that means it’s not just a matter of installing the packages as with ubuntu. There is a dedicated wiki page about installing ROS on debian, so I was of the opinion that it can’t be that hard. Actually, I once tried to install ros electric already when the bifferboard was still running debian lenny, and I ran into an infinite loop. I was full of hope that this bug had been fixed now with the release of debian squeeze and ros fuerte. But in fact, the first infinite loop was even earlier this time. And after circumventing an issue in pip with the help of a pip dev, I ran into the one I experienced earlier. I was able to find a workaround this time and reported the issue to pyyaml. The bifferboard has no FPU, and from what I can observe in python no inf and strange handling of nan. Continue reading “installing ros on a bifferboard”
There is an increasing noise about GPGPU computing and how much faster than CPU (even parallel) it is. If you didn’t hear about all that, GPGPU is about using the computer’s graphics card(s) to do general purpose computations. The key to the performance lies in the parallel architecture of these devices. From what I read, an average graphics card has 64 parallel units, but they are not as versatile as the CPU of which a typical PC these days has 4 cores. That means, if the task is well suited, it can boost performance significantly, but if not, it’s nothing more than a lot of wasted work.
So I wanted to see for myself. To get started I read the book “OpenCL Programming Guide“. It gave a good overview. But now it was time to give it a try.
Continue reading “OpenCL First Steps”
I read many articles and posts over the last year or so, citing how great llvm clang is. On one side it shall have a static checker that makes lint redundant, and on the other side the optimizer has an -o4 where the -o3 shall be comparable to other optimizers. On top of that, compilation speed shall be really fast. And the part that makes it interesting for folks like Apple (who uses and contributes), is that it’s licensed under a BSD style license. What more could you want?
Continue reading “packaging libboost compiled with llvm clang”
Another project that I had in mind for a while was to experiment with robot arm path planning and inverse kinematics. If you don’t know what that is, think about how robot arms could be programmed. The simplest form would be capture and replay, in which you have a controller which which you record how you manually move the joints. The robot can then replay the movements. We humans have developed a good intuition for moving our body parts and grasping, but when it comes to formally describing what you do with the joints of your arm, it quickly becomes difficult. My younger son is in the phase of learning to grasp right now, and it’s amazing to see how the eye arm coordination evolves. The second approach would be to program it like a CNC milling machine with something like G-codes. This is a bit more general and more exact, but it’s also more difficult to do collision avoidance. And it’s complicated to calculate as most joints tend to be revolutionate. Both these approaches are only suited for repetitive tasks often found in industry automation, but completely unsuited for robots in dynamic environments. Now with inverse kinematics, you can tell the robot where the arm should move to in cartesian coordinates, and it does all the arm geometry calculations and positions the gripper to the correct position in the desired orientation. Maybe there are obstacles in between the current and the target position. To navigate around these, you also need path planning. That is usually done in configuration space. Real robots have also to care about dynamics such as inertia, but I won’t go that far.
Continue reading “Robot Arm part 1 packaging and simple manipulation”
With the X and Z gears propperly glued, all axes moved. But it didn’t take long for the Z axis gear to break again. The gear that came with the kit was multilayered wood glued together and laser cut. The place where the belt is, is off the axle of the stepper motor. That’s obviously not a good combination. So I ordered an alloy gear from maedler. That came without a hole in the center. I didn’t have anything else then my hand drill available. Well it’s a bit more off center then I had hoped, but nut much worse than the laser cut wooden gears. And still, it works. So, all three axes work now. The ammount by what they move doesn’t seem right, so I’ll have to adjust some parameters still.
Continue reading “RepRap part 3: Ethernet connection”