Pavol Rusnak #cypherpunk #hacker #openhw #privacy #bitcoin #newmediaart

Trezor Emulator on Raspberry Pi

I got an idea while looking at the cool project called RaspiBlitz. They are using a nice LCD shield on top of Raspberry Pi for their Lightning Node. What if I tried running the Trezor Emulator on the same hardware setup? Trezor is completely open-source, so this should not be a big problem, right?

Here is the result of my late-night experiment. And it’s beautiful!


You can even connect it (via WiFi) to the Trezor web wallet and use it like you would use a real thing! However, the real Trezor is faster and smaller.

Never use the emulator for storing any value, it’s intended for testing only!

So, what do we need to build this?

Preparation steps, they are more-or-less the same for any Raspberry Pi based projects:

  • Get a Raspberry Pi 3 and 3.5 inch RPi Display (SKU MPI3501)
  • Download Raspbian (Raspbian Stretch with desktop) image from Raspberry Pi website
  • Unzip the image and write it to the SD card
  • Put the SD card into Raspberry Pi and boot the system

Let’s now install the display driver. Run the following in the terminal:

git clone
cd LCD-show
sudo sh LCD35-show

This will do the reboot, so let’s wait until Raspberry Pi starts again. You should see the internal display being used now.

Now, we’ll build the Trezor emulator:

sudo apt-get install scons libsdl2-dev libsdl2-image-dev
git clone --recursive
cd trezor-core
make build_unix_raspi

And the Trezor Bridge:

sudo apt-get install golang
export GOPATH=/home/pi/go
go get
sed -i 's:127\.0\.0\.1:' $GOPATH/src/
go build

The sed command above is required, because we need the bridge to listen to remote connections too, while the original bridge only listens at localhost.

We now have everything set! Let’s run the following two commands in two terminals. One is the bridge, the other one is the emulator.

./trezord-go -e 21324
cd trezor-core ; make emu

Now, we want to use the Trezor Emulator running on the Raspberry Pi with the Trezor web wallet. To do that, we’ll just forward the local port to the remote port (on the Raspberry Pi) and the wallet will immediately find that. Here is the magic to do that:

socat TCP-LISTEN:21325,fork TCP:{RASPI_IP_ADDRESS}:21325

You need to replace {RASPI_IP_ADDRESS} with your Raspberry Pi IP address.

And that’s it!

How to push Bitcoin transactions via SMS

Blockstream announced today their Satellite project. I was thinking about exactly that for quite long time, ever since this DVB-T broadcast experiment in 2014. There are lot of sceptics, but I am very excited about this development.

One of the recurring questions I saw was this one: What about the other direction (from user to Bitcoin node)?

Well, there are many options. One of them is sending new transactions via SMS or some other “legacy” method, if the Internet is not usable (blocked by the government, etc.).

I decided to create a simple proof of concept experiment named SMSPushTX. The source code is available from my GitHub repository.

First, I had to register at some service provider which is able to process inbound/incoming SMS. One of them is for example Nexmo, but there are others, such as Twilio or Tropo. I decided to go with Nexmo, because they have relatively cheap virtual numbers and also one does not have to pay for incoming messages, which is exactly what we (do not) want in our scenario!

After getting a virtual number (this was just 0.50 EUR/month for Belgian numbers), I was able to set up a Nexmo webhook which is triggered on each received SMS message. This webhook is pointed at my very simple Flask server in It consumes messages and forwards them to process_msg function in There is a catch, though. If a message is longer than 160 characters, you’ll need to concatenate it in your software manually, because Nexmo will send you a notification for every chunk separately. Luckily, that was quite easy, because you also get number of chunks and sequence number of current chunk in every notification.

Example of the incoming notifications:

    'concat-ref': '16',
    'msisdn': '420xxxxxxxxx',
    'messageId': '0C000000538BA945',
    'concat-total': '2',
    'message-timestamp': '2017-08-15 21:04:16',
    'concat-part': '1',
    'concat': 'true',
    'type': 'text',
    'to': '32460213730',
    'text': 'AQAAAAGKDYUXkeV/1wYLUD82slBs++d1BG+3l3VDzQsCk06KtAQAAABrSDBFAiEAhnJOYrejTqK/yeC7trGn/RhmQ13cCLjgI7KFmpPxxf4CIEj599L7S7r/WNFw63178y2cUHbQPtquhs3JtAcxxzyZA',

    'concat-ref': '16',
    'msisdn': '420xxxxxxxxx',
    'messageId': '0C000000538BAAA6',
    'concat-total': '2',
    'message-timestamp': '2017-08-15 21:04:17',
    'concat-part': '2',
    'concat': 'true',
    'type': 'text',
    'to': '32460213730',
    'text': 'SECK8N3vuXGrfZcC+wxfzyXVJtOnRaDDVVgU6RP/7vIKJj/////AgcEMwAAAAAAGXapFFmMuQgji+WAXhfI8FA1PGHHV8ZeiKxAQg8AAAAAABl2qRQkNDDiX+4AeooHtEj57drd3FbY54isAAAAAA==',
    'keyword': 'SECK8N3VUXGRFZCC',

Once the message is correctly concatenated, we can push it to Insight server using its API. I decided to allow two formats of transactions: hexadecimal format and base64 format. If sender uses the latter, we need to convert it to hexadecimal and only push to Insight server afterwards. This is done in pushtx function of

That’s it! That was easy right?! Remember, this is just a quick & dirty proof of concept and lots of things can (and should) be improved. But if one person is able to do something like this within 90 minutes with 10 EUR budget (10 EUR is minimum Nexmo payment, you will get 2 EUR as bonus, what translates to 2 years of Belgian number!), imagine what could be done with a little bit more resources!

Below is the screenshot of the base64 encoded transaction I sent to my service. It’s already mined in the blockchain after being successfully broadcasted via my service to the Bitcoin network.

You can try sending your own transactions via SMS here:

  • +32 460 213 730 (BE/EU)
  • +1 (314) 300-3730 (USA)

I will try to keep the service running for some time. Enjoy! :-)


How to use TREZOR with Rootstock (RSK) using MyEtherWallet

Since firmware 1.5.0 TREZOR supports Rootstock (RSK).

Update: MyEtherWallet can use RSK with TREZOR out of the box now! So this post is now obsolete.

To use RSK using MyEtherWallet one needs to point it to a RSK node which runs using HTTPS (not HTTP) and has correctly set Cross-Origin headers. Since there was none, I created one and sent a pull request to MyEtherWallet, so this chain can be used out of the box.

Until this pull request is accepted you can try it manually. Click on a menu in top-right corner, select the “Add Custom Node” item and fill in the following values:

Node Name:          RSK
Port:               (empty)
(chain):            Custom
Supports EIP-155:   yes
Chain ID:           31


Some useful links:


Longest TXID prefix collision in Bitcoin

As you probably know, transactions in Bitcoin are identified by their SHA256 hashes which are 256 bits long. These identifiers are called transaction ID or TXID.

We were brainstorming a new project at SatoshiLabs and an interesting question popped up. How much can we trim TXIDs before collisions start to appear? Or in another words: can we use just the first 128 bits of the hash instead of the full hash to uniquely identify the transaction? Can we use even less bits?

Let’s find out!

Bitcoin Core daemon provides a JSON RPC interface, which you can use to query the blockchain. There are many ways how you can interact with the RPC, but I prefer to use Python, so let’s use this as an example. Let’s install the required package first:

sudo pip install python-bitcoinrpc

Next, let’s open ~/.bitcoin/bitcoin.conf file and note the rpcuser and rpcpassword fields from the file, we’ll need it for later. If you want to access the RPC from different machine, add the following line:


This opens the RPC port for the specified range.

Now, let’s create the script with the following contents (modify the line containing RPC_SERVER to your needs):


from bitcoinrpc.authproxy import AuthServiceProxy

RPC_SERVER = ('bitcoinrpc', 'mysupersecretpassword', '', 8332) # user, pass, host, port

rpc = AuthServiceProxy('http://%s:%s@%s:%d' % RPC_SERVER)

count = rpc.getblockcount()

first = 0
chunk = 100

for start in range(first, count, chunk):
    end = min(start + chunk, count)
    rng = range(start, end)
    hashes = rpc.batch_([['getblockhash', h] for h in rng])
    blocks = rpc.batch_([['getblock', h] for h in hashes])
    for b in blocks:
        for t in b['tx']:

What this script does is that it opens RPC connection to the node and asks for the actual blockheight (index of the newest block).

Then it uses batch API to ask for hashes of individual blocks and contents of these blocks (you can’t ask for content of block #17 directly, you need to know its hash first). Once the contents of the block is known, the script just prints out transaction IDs to output and discards the rest.

Running the script produces a 13 GB text file with 201,180,597 lines (each line containing exactly one TXID and a newline).

Now we need to find a longest collision. Finding it is quite easy once we sort the file, because sorting will put collisions next to each other. This means we just go through the file and measure the length of the collision with the previous line.

I wrote another script in Python to perform the task, but it was too slow (I left it running for 20 minutes and then I stopped it).

I decided to rewrite it to C and cheated a little bit (I know that each row is exactly 64 characters + newline, so there’s no need to read the file row by row as a text file, but let’s read it rather as a 65-byte blocks):

#include <stdio.h>
#include <string.h>

int strsame(const char *s1, const char *s2, int max)
    int r = 0;
    while (r <= max) {
        if (*s1 != *s2) return r;
        r++; s1++; s2++;
    return r;

int main()
    FILE *f = fopen("txlist.sorted", "rb");

    char buf1[65], buf2[65];
    char res1[65], res2[65];

    memset(buf1, 0, sizeof(buf1));
    memset(buf2, 0, sizeof(buf2));

    char *line = buf1;
    char *last = buf2;
    int last_max = 0;

    for (;;) {
        size_t s = fread(line, 65, 1, f);
        if (!s) break;

        int r = strsame(line, last, 64);

        if (r > last_max) {
            last_max = r;
            memcpy(res1, line, 65);
            memcpy(res2, last, 65);

        char *tmp = line;
        line = last;
        last = tmp;

    printf("%.65s%.65s%d\n", res1, res2, last_max);


    return 0;

Running the program (it took just around 45 seconds!) resulted in the following output:


Woohoo! We have the result. The longest collision is 13 hex characters long and you can see it above.

This means 7 bytes (56 bits) are enough to distinguish the transactions by their TXID for now. Much less than I anticipated at the beginning!

Autoplay video on Raspberry Pi

Lots of (art) people are using Raspberry Pi instead of DVD players and MP4 players for their installations that play videos in loop.

There are many ways how to achieve the result, but the one I liked the most is the following:

  1. download Raspbian Lite from
  2. copy the downloaded image to the SD card, e.g. sudo dd_rescue 2017-01-11-raspbian-jessie-lite.img /dev/mmcblk0
  3. boot Raspberry Pi into freshly installed Raspbian
  4. copy your video from USB flash drive to the SD card
  5. sudo apt-get update
  6. sudo apt-get install omxplayer
  7. append this line /usr/bin/omxplayer -b --loop /home/pi/*.mp4 to file /etc/rc.local
  8. set the file as executable: chmod +x /etc/rc.local
  9. reboot and enjoy!

If you want something more magical (that can discover and autoplay all video files on attached USB stick), you can try VideoPi project by my friend Jakub.