Richi's blog

Category: BitCoin

  • SIX fintech hackathon

    I learned of hackathons before. It sounded interesting, but either they were too far away, the topic was not interesting enough, or the date was already booked. This time was different. The topic is really what made it interesting enough. FinTech is about new technology in finance. I’m sure there was innovation in the financial industry in the last 50 years, but it was not very visible, and not as fast as in other industries. Recently I read about an employee in a bank that was asked upon his retirement, what was the biggest change in the last 40 years in his job. His answer was : “air conditioning”.

    With the advent of BitCoin, the financial sector started feeling some pressure to innovate. I don’t really know how the term FinTech was born, but this all might have contributed. So one thing was clear for me about the hackathon from the beginning: The project had to be about BitCoin.

    SIX is probably one of (if not the) biggest service providers in Swiss finance. They run the Swiss stock exchange, most card terminals in brick and mortar shops and PayNet where people can receive electronic invoices in their online banking. These are only the most visible products. They organized the hackathon for the first time a year ago. This time it was in two locations: Zürich and London. Watching last years videos I realized that the event would be organized much better than I expected. And the actual event was even better than the videos promised.

    So I went to the Schiffbau which is a former ship building factory turned into theater. Everything was prepared, and we were welcomed with a dinner. The opening ceremony included a very entertaining speech from an editor of the Wired magazine. Next were presentations for the four workshops. I watched “Blockchain, Smart Contracts and Beyond” and “Cognitive Computing in Fintech”. Both were interesting, but not exactly what I expected.
    Some teams were already formed, the others went to the match making session. Everybody who had an idea for a project could present it in a few sentences. Then the teams were formed. The Idea I presented to implement a bridge between PayNet and BitPay didn’t spark a lot of interest, so I helped implementing another endeavor.

    Our team set out to implement a bridge between PayMit and BitCoin, thus we named it BitMit. I knew the name was familiar, but it took me a while to remember that BitMit was also the long defunct Marketplace that worked like eBay, but with BitCoin. The responsibilities were quickly found: Iwan would implement the IOS app, Mark would implement the management dashboard, Roger was responsible for the Presentation of our project and I implemented the backend.

    IOS App
    We received an API for PayMit that came with an example app. The app had buttons for buying certain products. So Iwan replaced the buttons for different denominations of popular crypto currencies. When a button was clicked, the app would first execute the payment using the PayMit API and then communicate with our BitMit backend. Finally it displays a receipt including the BitCoin transaction ID. Apparently working with Apple’s XCode is a very special experience that is far from intuitive.

    Back-end
    The back-end was responsible for providing a simple API for the IOS app, interacting with the BitCoin blockchain and managing a BitCoin hot wallet. We chose python and flask to do the task. Most members in our team were familiar with python and flask. I only implemented a very small project with flask a few years ago, but that knowledge was almost enough for the task at hand. I wanted to make use of electrum servers to have it lite weight. But Friday and Satturday we wanted to use the BitCoin testnet, and unfortunately there are no electrum servers for testnet. So I went with BitCoinCore.
    At first we were not so sure where the backend would run. My notebook would be good enough for the time being. But then the guy from IBM offered to have it running on their cloud. He helped me setting everything up. When connecting with ssh to the ubuntu machine, I didn’t even realize that it ran inside a docker container. And the beast was fast! With the 48 cores and a fast internet connection, the BitCoin blockchain was synchronized in less than six hours.

    Management Console
    Compliance and auditing is very important for Banks. Thus our Service has to have a means of keeping track what is going on. Mark implemented the front-end using React. I certainly heard this buzzword before, but never saw actual code. It’s quite cool how simple the code looks when the task fits the framework.

    Pitch
    The presentation or pitch was allowed two minutes max. And a gong would terminate it abruptly on stage. The first iterations were roughly twice that long. It was hard to cut it down to the right duration. Too valuable all the information we wanted to communicate. Roger had a very good opening, which I don’t even know if it was still part of the final pitch.
    Before entering the final, we gave the pitch a couple of times. Most important was the presentation to the jury. After the pitch the judges could ask us questions. One guy obviously had no clue about how BitCoin works. When this guy was later presented as member of the board and announced the winners, I felt our chances dramatically dwindling.
    I took a video of the pitch Roger and Iwan gave for the final on the main stage. It is streaming from the ipfs.

    Our project might be not the most novel idea, but it fills a need. Other projects that were presented sound very funny at first but after thinking it through you don’t think anybody would use it. Still others had only fancy slides but nothing functional to show. But there were also projects that made a really good impression. That is probably the expected outcome from a hackathlon.
    For me it was a fun and entertaining experience. I will surely participate in other hackathlons. A big thanks to SIX for organizing the event and for all the good food and drinks we enjoyed.

    An interesting fact that I observed was the computers used by the participants. About 90% of them were from apple. Most of the remaining computers ran some kind of flavor of linux. And I saw a single one running Windows.

  • Super secure BitCoin storage

    I wrote about multisig with different hardware wallets something more than a year ago. Back then It was awfully complicated and I didn’t really get it working. A lot of progress has been made since then. The functionality was added to electrum last summer for trezor. I couldn’t test it however because my two trezor are initialized to the same seed, and the recovery sheet is distributed geographically. On top of that, the functionality was, and still is not implemented for ledger wallets. Like I wrote in a previous post, I recently received a keepkey. Multisig functionality was one of the main topics I wanted to experiment with the new device. My goal with this is not for everyday use but for super secure storage of BitCoin.

    We are going to create a multisig wallet consisting of trezor, keepkey and ledger HW1. I assume, an electrum wallet is already set up for each of them. Further I assume, the seeds for each of them are written on the paper cards. These cards shall be properly secured. To further improve security, you can split the cards and distribute the contents geographically for example in different vaults.

    First you will have to extract the xpub from each one of them. I used the main account. While I assume it would work with secondary accounts as well, I can’t be sure without testing. To construct the multisig watch-only wallet with electrum, follow these steps:

    • File -> New/Restore
    • Enter a name of choice. I use 2ofTKH to indicate 2 of x multisig with Trezor, Keepkey and HW1
    • Select “Restore a wallet or import keys” and “Multi-signature wallet”
    • Select 2 of 3
    • Enter the xpub’s from the three different hardware wallets into the three edit fields
    • Wait for electrum to generate the addresses

    Receiving works the same way as every other electrum wallet. But for sending, follow these steps:

    With the multisig watchonly wallet:

    • Go to the send tab, and enter the information just like with regular electrum wallets.
    • Click the “Send…” button
    • Notice that the transaction dialog doesn’t have a send button
    • Click the Save button, and save the file as unsigned.txn
    • Close the transaction dialog

    With the trezor wallet:

    • Tools -> Load transaction -> From file
    • Select the unsigned.txn that you saved before
    • On the Transaction dialog that opened, click Sign
    • Confirm the transaction on the trezor
    • Note that the status is: Partially signed (1/2)
    • Click Save, and select a name like partially_signed.txn
    • Close the transaction dialog

    With the keepkey wallet:

    • Tools -> Load transaction -> From file
    • Select the partially_signed.txn that you saved before
    • On the Transaction dialog that opened, click Sign
    • Confirm the transaction on the keepkey
    • Note that the status is: Signed
    • Click the Broadcast button
    • Close the transaction dialog

    The Ledger HW1 can also do multisig, that’s why I used it as the third key. But so far, the functionality is not implemented in the plugin.

    The reason I wanted to constuct the multisig wallet with hardware wallets from different vendors is this: Suppose a weakness was found in one of them, at most one of the keys of the multisig could be compromised.

    Yes, the procedure is somewhat lengthy and cumbersome. It is not intended for everyday use, but for secure storage of higher value savings. So the usability tradeoff is completely ok for me. Given the security offered by this scheme, it is the most user friendly procedure that I am aware of.

     

  • keepkey premium bitcoin hardware wallet

    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:

    HardwareWallets1 HardwareWallets2

  • case bitcoin hardware wallet

    Part of the reason why I pre-ordered a case hardware wallet, was probably that there is no good wallet software on ubuntu phone. But the case is way more secure than a software wallet on a phone. Roughly the same size of the smallest feature phone you can buy, it contains an eInk display, a camera, a GSM chip, a fingerprint reader and wireless charging. For improved security it makes use of Bitcoin’s multisig feature. One key is on the device and one on the case servers. The third key is used only to restore funds in case the device is lost or stolen. You can either leave it with a third party or manage it yourself. Of course I chose to manage it myself, after all BitCoin is about empowering people instead of depending on third parties. The server part allows to implement spending limits and maybe other validity checks in the future. The fingerprint is used to authenticate against the server.

    When the presale started in early May, the projected shipping date was end of summer. It was later fixed to September 21st. Because they found a problem with the uptate mechanism, they postponed the delivery. Communication suffered during this period. Everybody understands that this kind of problem can happen with such an early limited batch of a new class of product. But weekly updates would be very valuable in this situation to keep customers happy.

    November 20th the box was finally delivered. The packaging is not as nice as with the trezor, but I don’t mind. The contents are much more important than the box. Build quality looks good. When I read that it is charged wirelessly and has no connector, I assumed it would be water proof. That is definitely not the case, but wouldn’t be too hard to achieve as it looks. It has tiny gaps around the fingerprint reader and the camera where water and dust can enter. The buttons are from the same film that covers the screen.

    The setup process looks simple. You scan a qrcode from the website and your xpub for the 3rd key. Then you register your fingerprint by swiping it ten times. I was warned that it had to be at the right speed and angle. My first two tries were misreads, but after that I had only two more in total. It is easy to get right. The bigger problems were the server error messages that I got ten times in a row. Maybe the server had too much load. When I tried it again after waiting for an hour, it succeeded the first time.

    Updating the firmware is a breeze, and worked like a charm the first time I tried.

    Sending and receiving BitCoins couldn’t be easier and works very well. The connection can take a moment sometimes, but I think they are working on improving this aspect. Although I can’t tell for sure, but I had the impression it improved already with the first firmware upgrade. Specifically, I could now see the bars of the GSM signal already while scanning the qrcode.

    What I miss is the current balance of the account.

    But what I miss even more is an option to set the transaction fees. MultiSig transactions are bigger than standard transactoin, and thus the transaction fee is naturally higher. But a standard transaction in electrum with the dynamic fees slider in the middle costs usually mBTC 0.05  ($ 0.02) @ 223 bytes. The three outgoing transactions I did so far with the case were not that much bigger at 372 bytes but carried a transaction fee of mBTC 4.43751 ($ 1.43). This is more than an order of magnitude too high, and there needs to be a way to adjust.
    Update: The fourth transaction with my case which I performed just an hour after writing this post, and the fifth the day after, had a regular transaction fee of mBTC 0.1 ($ 0.03).

    Of course the three keys of the multisig are not just three ordinary BitCoin addresses. On the transaction level they are, but they are part of three hierarchical deterministic wallets that are linked together just like multisig wallets in electrum. Thus I was releaved to see that it asked me for an xpub as my 3rd key, and I could happily use one from the Trezor. But so far I couldn’t figure out how to retrieve the xpub’s of the other two components. Once I get them I can setup a readonly multisig wallet in electrum to track the transactions and the current ballance. But even more importantly, I can then assign descriptions to the transaction in a familiar environment for my personal accounting.

    After the important issues above will be fixed, we can move to some wishes I would also have:

    It would be nice if I could use the case for a custom multisig scheme. With the xpub of a Trezor, a HW1 and the Case, I could set up a multisig wallet in electrum. With electrum I would construct the transaction, and partially sign it with the Trezor. Then I would display the partially signed tx with electrum on my computer screen. Case could scan it from there and add it’s signature to it. Then it would either display a qrcode with the signed transaction on its screen, or transmit it to the BitCoin network over GSM. Once this works, I could set up an electrum wallet with the same xpubs as used in normal case operation. This would give me peace of mind because it would allow me to access my funds even if case went out of business or decided to censor my payments for whatever reason.

    To improve privacy, it would be cool if I could run the server part on my own web server. This would require it to be open sourced, and a configuration option would have to be added to the firmware.

    Last but not least, an option to sweep paper wallets by scanning the private key would also be useful.

     

    case_bitcoin_hardware_wallet_box

  • ScroogeCoin

    After a long pause, I just started attending a MOOC again. It’s on Coursera, from Princeton and it’s about BitCoin. In one of the first lectures the teacher goes through some simple hypothetical digital coin concepts. I don’t know if the lectures are publicly available piecewise, but as a whole they are at youtube. Jump to minute 50 for scroogecoin.

    Name property problem
    GoofyCoin signed receipts double spend
    ScroogeCoin centralized blocks corruption
    BitCoin fully decentralized solved

     

    ScroogeCoin reminds me a lot of the blockchain projects a lot of big financial institutions announced over the last few months. They talk about permissioned blockchains. That sounds like exclusive access and centralized control. BitCoins inclusiveness is one of the important characteristics, and I hope enough people recognise it as such.

    BlockChain

  • When VISA doesn’t work

    I used to order stuff from dealextreme on a regular basis over the last few years. Like many other customers I asked them to accept BitCoin payments. But that didn’t happen so far. So we are left with the payment options from the last century for the time being. It used to work acceptably so far … until about a month ago, when my payments suddenly started being declined. The same VISA debit card used to work with dx before, and it remains working with other merchants. Of course I checked the balance. I dont keep much more on that account than I expect to need in the short term. But $250 should suffice for a $200 order, so the problem has to be somewhere else.

    Dx states it on their page unmistakeably that all payment problems are not their fault, and that people should consult with their issuing bank. So I contacted them first. They couldn’t find anything about the declines in their logs:

    There are no transaction attempts on your card for the merchant
https://eud.dx.com, not on July 27th or after.
In those days I can see transactions at merchants X, Y, Z - which all
look like they are still pending and waiting to be completed
(a few months ago we updated our payment processing system to
adhere to settlement standards).

For some reason it looks like the payment authorization never reached Us..
When a payment takes place (when you use your card), what happens
first is that the merchant informs Visa, Visa then informs our card
issuer, and the card issuer informs us about a new transaction on
your card. We then hold the corresponding funds from your wallet.
Then a few days later, the merchant settles the transaction
(ie. broadcasts to the network whether the transaction was
completed or not), and we use that information to complete your
transaction. What is strange is that the authorization for your
purchase at https://eud.dx.com either never reached Us, or never
left the merchant's system.

Because you've been able to use your card in the past few days,
I'll dare to say that there's nothing wrong with your card - rather
it seems like a glitch with this particular merchant.

    So I asked the card processing intermediary. They had no means of secure communication. I found it hard to believe that a financial institution can only communicate with their customers over unencrypted cleartext eMail.  However, I got similar results:

    Please be informed that we could not find any decline on your card at our end,
which means it could be an issue with merchant end.
We request you to check with the merchant regarding this.

    Finally I went back to dx and got this answer:

    sorry for that.
but our related staff told us your bank reject the payment.
that is not our problem.

    From all I learned so far, it seems like VISA is the problem here. But I don’t have a contact or a direct relationship with VISA. It is routed over shady ways through an unknown number of intermediaries. The best explanation that I can come up with is that the transactions triggered some kind of fraud alert and were thus blocked. Is that how they deal with the lack of a secure system? They just randomly block transactions! With no way of recurse, such false positives are really annoying for their customers.

    So what do I learn from this? When there are too many intermediaries in the loop, there are more chances for errors and errors are harder to find, let alone fix. With BitCoin, there are no middlemen and a lot less things that could go wrong. I have been using BitCoin whenever possible for the last four years. Nothing alike ever happened with BitCoin, in fact this would be unimaginable with a peer to peer blockchain system. I’m really looking forward to leave all those ancient  payment methods behind…

    Ironically, I read this story the same day I got the last answer from dx.

  • connecting home securely

    It has been probably close to a decade that I run a small server at home. At first it was only because I could not find a web hosting company that would serve my fcgi libwt apps at an affordable price. Then I added this blog to it. In the meantime I added a lot of other stuff as well. One of the more important things became ssh. Not only for remote shell sessions, but also for securely copying files and tunneling. In fact I use ssh tunnels instead of a more traditional VPN.

    Discovery

    Static IP addresses are expensive in Switzerland. So I used dyndns from the start. At first the free offering, and then switched to a paid plan long before they discontinued the free offering. Just last week I received a note that they grabed the annual fee from my (scheduled to be deactivated) credit card. Generally I strongly dislike services that automatically grab money from my accounts. They didn’t even mention that the fee doubled. That’s one side of the story, the other is that dyndns is an American company. They could take my domain name hostage without even telling me.  So there has to be a better alternative. In fact there is one. It’s good technology wise, but not generally available to the unintroduced yet.

    DyName for namecoin

    I wrote about namecoin in a previous blog post. One of its main uses is a censorship resistant domain name registration. And the simple python script from DyName is to namecoin what dyndns and ddclient are to traditional domain names. Just prepare your registered name to include a dd entry, edit your config file, and call the script periodically from cron. That way you separate the private key where your name is registered from the hot wallet on the server. My provider used to reassign new ip addresses more frequently, now it’s about once every two months I would guess. The transition with namecoin was very smooth the last two times. I have a script that queries namecoin for the current ip address and then connects. There are dns resolvers and browser plugins or even public dns servers that would resolve namecoin domains. My experience with them was not as smooth as with the namecoin core itself. But I’m sure these parts will improve as well. So, with namecoin we have high confidence, that the ip address is correct that we are connecting to, but it can’t protect against man in the middle attacks. SSH has means to protect from that. The ssh client has a list of known ip addresses or host names and corresponding key fingerprints. But after an ip address change, there is no entry for the new destination, so ssh prints an error message and refuses to connect until you accept to add a new entry to your known_hosts file.

    ssh known hosts

    When you search for the error with your preferred search engine, you’ll find advices to delete offending lines in your known_hosts file. This of course is not what we need here. Just accepting to add a new entry the next time you connect would circumvent the protection against MITM that ssh provides. Since we already have the key fingerprint from the previous address, there is another more secure solution. If you have only one entry in your known_hosts file, you can skip the next few lines. Maybe you know which fingerprint is valid, for example because the file already contains a couple of lines with the same key fingerprint because the ip address changed a couple of times, and you just accepted it.

    If you are not sure, which fingerprint you need, ask the server what it provides:

    $ ssh-keyscan 85.3.164.135
# 85.3.164.135 SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1
85.3.164.135 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE7WE5vtqSxUnQRX5CjOzEzUAdewqHRV5MXcSCQcylcKanpnDHRE4yVlEn770MFP6EfJ61ukdNYMDnSO9eoRiZY=

    Now search for this fingerprint in your known_hosts file, and copy the whole line. On the new line, you replace the first hash with the actual new ip address in clear text. You could leave it like that, but you can also hash it with the following command.

    $ ssh-keygen -H -f ~/.ssh/known_hosts

    After writing all this I started wondering if it would be possible to keep the host key on an external hardware device like a NitroKey or a YubiKey. I already keep my client key for authenticating to the ssh server on one of these.  That’s something to find out in a future post maybe.

  • libreboot and trisquel

    Last month I saw somebody on the fsfe mailing list talk about an OpenMoko phone. As I had one of those collecting dust in the drawer, I asked if anybody was interested. Promptly I got an offer to exchange it for a Lenovo X60 notebook with libreboot. I didn’t need another notebook, but libreboot seemed interesting enough, so I agreed. It came preinstalled with trisquel gnu linux, and with a docking station. I’m not sure if I heard about that distribution before. It is based on ubuntu, but includes only the free open libre stuff. The default desktop is gnome3. Since it’s a good fit with libreboot, I kept trisquel. The first impression was that it runs extremely well for such an old device. I was also amazed how rounded and complete a full on libre distro can be these days. Gone are the days where the compromises you had to make for freedom were hard to justify. The first thing, friends ask is about flash. But I don’t miss it at all, I mean html5 has been around for a while. At first, I started to install games for the kids. They run a lot better than on my old Atom netbook. As it’s my first device with a fingerprint reader, I had a little play installing this option for logging in, fully aware that it’s not that secure. The only two things that are not so optimal are sound and heat. Neither the speakers nor the headphones give any sign of live, event hough the operating system seems to have recognized the sound card. This is not such a big deal, as the bluetooth headphones still work perfectly. The other issue is that it heats up a lot under full load. And when the core temperature hits 100°C it just switches off. This happened a couple of times when the BitCoin BlockChain synchronized. And it still happens once every second day.

    Then, my XPS13 was stolen, and I needed something to fill the gap until I have a proper replacement. I must say it does the job well. I miss the XPS13 a lot, but at least I have something I can work on. And who knows how long it takes before I have an XPS13 again. They recently announced a new version with tiny bezels around the screen, bigger SSD and newer processors. But the new developer edition is not available yet, and the old version is not available any more. When it becomes available, I want to pay it with BitCoin, which also is not available yet. Dell accepts BitCoin payments in the US, Canada and the UK. I hope they will soon roll out worldwide, or at least to the rest of Europe. Once I can order on my terms, I will still have to wait about a month for delivery.

  • xapo debit card backed by BitCoin

    It will take a while until we can pay with BitCoin at most merchants. For the time being xapo introduced a visa debit card that credits your expenses directly from your BitCoin online wallet at xapo. Since it runs over the visa network, and since there are currency conversions involved, it can’t be as cheap and frictionless as BitCoin directly, but it is an interesting option nonetheless. Since I’m planning on cancelling my regular credit card, this could be an interesting intermediary solution. I found a couple of articles that more or less describe the card, but they all left some uncertainty. It appears that they only recently expanded their offer to Europe. But only cards with USD, EUR or GPB as nominal currency are available. That means for me that an additional conversion from CHF to EUR will be required, adding to the transaction costs.

    So, first you create an account with xapo, which is as easy as with any other online service. Then you find an option to pre-order a debit card, which will require you to allow them to hijack your twitter and facebook accounts. I don’t have none of the two, so I was stuck for a moment. There is a support chat easily accessible, and they respond quickly. European customers just need to send some money from their regular bank account to the xapo wallet where it is converted to BitCoin. After that, you receive a debit card automatically.

    I received mine last week. To enable it and get the pin code, I had to call a number in the UK with a fully automated computer system. On the web you will find different information about the card. The third party issuer seems to have prohibitive fees, which xapo promised to absorb. So, I’m a bit curious about the business model behind. but this post is about it’s usage. Since I planned it as a replacement for my regular Visa credit card, I tried it for online purchases first. I always thought Visa is Visa, after all Visa debit cards are uncommon around here. Turns out most online merchants only accept Visa credit cards, and wont go with debit cards. I have no idea why this is. Today it should be easy to verify a payment with a bank where the customer’s account is. That was not the case twenty years ago, but nowadays ….?

    Then I used the card to buy some chewing gums and a train ticket. That worked like a charm. When I calculated the cost with the current CHF price that the android BitCoin wallet displayed, it was about CHF 5.99 which would be even less than the fees indicated. But as we all know BitCoin is very volatile, and so this calculation is difficult to carry out exactly. But I think it’s save to say that the fees with the two currency conversions are not as prohibitive as I feared. I don’t know if the merchants pay equally high fees as with credit cards, but I guess it’s for sure higher than with the Maestro debit cards that all local banks hand out to their customers.

    To sum it up, it’s great that there is now a way to indirectly spend BitCoin for everyday purchases. Even if BitCoin is used in the background, this particular use case seems to add more friction than just using the Maestro card from my local bank. The minus that bugs me most, is that I can’t use it for online purchases.

    Coop sbb xapo-card

     

    Update

    After the card initially failed for most online purchases, I asked the xapo staff about it. They couldn’t find a good reason why the transaction failed, nor were there any logs indicating reasons for the declines. Hence I kept trying, and indeed the last few times I used the card for online purchases, it was always successful, even with merchants that failed previously.
    The other issue I had a close eye on was the fees. The Amazon transactions were free, which was most welcome as purse.io stopped working with amazon.de lately. All other card transactions carried a 3% fee, which is quite hefty. But compared to the CHF 120 I currently pay for my Visa credit card, that’s acceptable. So, the time to cancel the credit card has finally arrived.
    I usually have the card charged with about CHF 100. After I used it to pay something, I can recharge it immediately with a simple BitCoin transaction.

  • prevent or react

    Beginning of this year, there was a very tragic event prominently present in all newspapers across Switzerland. The whole thing was so tragic, that I won’t add a link here. But there is one aspect, that kept me thinking for the last two weeks. Today’s blog post by Bruce Schneier triggered me to write about it. There was a family father who fed his family from selling smart phones on online auction sites without delivering anything. Apparently he did that for years. They couldn’t get hold of him because he moved house every couple of months. In contras to places like Nigeria, I didn’t think this was even possible here in Switzerland.

    First of all, I don’t think that’s the profession he imagined for himself. There must have gone something terribly wrong long before. I think one has to be very desperate to become a professional cheater. Most measures our society has in place against such behaviour are reactive. Bad behaviour is punished, and the prospect of the punishment should keep the hesitant from misbehaving.

    In certain areas of commerce it’s easier. In a brick and mortar store, you get the goods and pay directly. If you take the goods and run out of the store, chances are somebody will follow or somebody will stop you. This kind of theft is also easier for the police to pursue. But there are other areas where you need to bring a certain trust. That’s for example if you order something online and pay upfront. If it is a big name store, you may know it’s reputation. If they wouldn’t deliver, you ‘d tell your friends. This in turn could influence the reputation of the shop. With sites like ebay that have more participants than could any individual keep track of, it doesn’t work as easy. That’s why they have reputation systems built in. There are certain ways how you could trick them. I have no ideas how well that would work out, but the only way to prevent that would be to require for example a social security number instead of just an email address to register. Other countries issued electronic passports for a while which could be used for identification in such cases. Whether this is desired is another question.

    Ebay and ricardo do offer some sort of escrow service. But nobody seems to make use of it. Certainly not the victims of the above mentioned iphone scammer. Some may already know where I’m leading to. That’s an area where BitCoin can shine. With it’s built in, easy (soon) to use  multi signature escrow system, certain types of fraud almost disappear over night. If the system doesn’t allow cheating, there is no need for punishment after somebody was ripped off, or threats against such behaviour. So which is better, prevention or reaction paired with menace?