14 Mar 2014
It is with regret that I have to announce, that Bridgewalker is shutting down.
Since it was using Mt.Gox as the backend exchange, it was directly affected by
Mt.Gox imploding. But there were also a few other factors which played into this
decision, which I detail below. Thanks to everyone who supported this project!
All user funds will be returned in full. An update should be available shortly
through Google Play which will allow you to submit a Bitcoin address, where you
would like to have your funds sent. I will use
BitcoinAverage to determine the
exchange rate. Please allow a few days for your request to be processed. I will
be returning user funds for at least the next 6 months, but would ask you to put
in your request soon. Feel free to email me if you have any questions.
"Why did you still use Mt.Gox? You should have seen that coming long ago!" True,
and I did to some extend, which is why my losses are manageable. The main reason
I never did the switch - and I contemplated it several times - was, that for all
its shortcomings, Mt.Gox still was for a long time the only big exchange with a
streaming data feed. And I considered it an important feature to keep track of
the market very closely, to be able to safely provide competitive currency
conversion services - a major cornerstone of the Bridgewalker architecture. So
switching to a different exchange would have required quite a bit of extra work
and a worse service level as a result. Not the most attractive value
proposition, so I decided to instead work on new features and hope that Mt.Gox
would get their act together. That optimism was unfortunately misplaced, but I
am prepared to deal with the consequences. The losses that did occur I will
replace out of my personal funds.
But the Mt.Gox debacle is not the only reason for the shutdown. So far, I
have not managed to gain the traction with Bridgewalker that I was hoping for.
There are probably many reasons for that, among them certainly, that it is a
tough sell to get people to entrust their funds with an unproven startup. And
for good reasons! I was always looking for ways to get rid of the requirement of
holding user funds, but have so far not found a practical and cost-competitive
alternative.
I still believe, that a service like Bridgewalker - providing a way of using
Bitcoin only as a payment mechanism, without holding Bitcoin yourself - is
something that has a target audience. As we go forward, we will hopefully be
able to deploy interesting Bitcoin-based solutions. Solutions like tap-to-pay,
metered billing (e.g. WiFi paid by the kb using micropayment channels) and making
smallish payments right in the browser, to name just three things that I find
very interesting. I am convinced that there will be a group of users, that will
want to use these services, but would rather maintain their account in their
trusted fiat currency of choice.
And there are good reasons for wanting to keep your funds in fiat:
- The often cited volatility of Bitcoin. It is true and will likely remain true
for some time to come.
- Familiarity with your local currency. You have a feeling for what things cost
and a sense of stability, simply because everything around you is priced in
that same currency. Your currency might fluctuate on the world markets, but
your coffee at Starbucks still costs the same as yesterday - at least on most
days.
- Easier accounting. This one is especially important for the merchant side.
Conducting business relies a lot on proper accounting and even if you are the
biggest Bitcoin fan, it might not be worth the trouble, to have to track a
foreign currency and deal with things like gains and losses caused by exchange
rate changes. Simply pretending that the customer paid you in your local
currency and just used Bitcoin as a technical solution to do so, can simplify
your bookkeeping and make it easier to get started accepting Bitcoins.
(Bridgewalker would have eventually attempted to eat BitPay's lunch. ;-P )
- Separating the use of Bitcoin as an investment and the use of Bitcoin as a
payment mechanism. Keep your bitcoins in cold storage and keep some fiat in
your Bridgewalker account to spend on Bitcoin services, without affecting your
Bitcoin holdings. The often requested "buy-as-you-spend" feature of Coinbase
follows from the same motivation.
In some ways, it might be, that Bridgewalker was simply too early and
Bitcoin-based solutions will need to mature more, before there is a real demand
for this type of service. I might try again at a later time. If I do, it will be
without an exchange in the background though. It's simply too big of a failure
point and also creates all sorts of legal challenges. Maybe projects like
Counterparty or
Ethereum will be ready by that time, to provide
crypto-equivalents of USD and EUR, that track their real-world counter party
through some kind of gambling/financial derivatives.
Then the Bridgewalker client could be completely server-less and just use one or
several blockchains to provide the same functionality. I would imagine, that the
client would maintain a small amount of bitcoins as a buffer, to be able to
quickly make transactions. But then move bitcoins from and to the buffer into
cryptoUSD or cryptoEUR to keep the purchasing power pegged to those fiat
currencies. The question is, whether this can be made cost-competitive, which
depends on the amount of market spread, slippage, tracking errors and other
sources of friction.
By the way, Bridgewalker is
open source,
so if you feel like tackling any of this and want to reuse parts of
Bridgewalker, feel free to do so!
For the moment, I will be focusing on pure Bitcoin wallets again at
Hive. Our Android wallet will be arriving shortly
- keep an eye out for it! And who knows, maybe at some point Bridgewalker will
be rising from its ashes. ;-) Thanks again for all your support!
07 Jan 2014
At Hive we have a strong commitment to open
source. Today, we honor this commitment by open sourcing the Bridgewalker
codebase. I am excited that this has been made possible by the Hive
acquisition
and am very much looking forward to the new possibilities and projects that this
might lead to down the line!
The meat of the Bridgewalker codebase can be found in these three repositories:
Then there are a number of support libraries and tools which the Bridgewalker
server depends on:
I'm afraid that the documentation is only rudimentary in many places. This was
only a side project for me for a long time. A working Bridgewalker server also
consists of quite a few moving parts, so getting it all set up is somewhat
involved. But each repository contains a brief README file which should
hopefully get you started. If you have any questions, I am happy to try to help
out - just shoot me an email at [email protected].
Happy coding!
01 Jan 2014
Bridgewalker has always been about exploring the idea of using "Bitcoin, the
network" solely as a payment mechanism, but avoiding "Bitcoin, the currency" and
its volatility by exchanging in and out of local currencies before and after the
payment takes place. Using Bitcoin in this way, it then becomes a technical
solution similiar to the ACH network
or credit card networks, in that it provides a payment network which allows the
electronic transfer of funds denominated in fiat (e.g. euro or dollar). But a
payment network which has no barrier of entry, as anyone can plug in, as long
as they speak the Bitcoin protocol. This concept has also been described as
Bitcoin being "money over IP" or an "IP address for
money".
Point of sale demo
The following video is a technology demo of how Bitcoin might be used in this
manner in a point of sale setting, where a customer wants to pay contactless
with his smartphone. To set the stage: In this example the merchant is using a
laptop to initiate the process. She enters the price of the product - let's say
2 euros - and the software uses the current Bitcoin exchange rate to calculate a
Bitcoin amount, which is then shown to the customer on an external screen
together with payment instructions. The customer holds his phone close to the
NFC pad and receives the payment details. In this case he uses the Bridgewalker
app, where he maintains a euro balance, which can be converted to bitcoins for
the purpose of transfer at a moment's notice. The app picks up the payment
request and - after final confirmation by the user - sends out a Bitcoin
transaction. To increase speed and especially reliability a copy of the Bitcoin
transaction is also sent back to the merchant via Bluetooth. The payment is now
complete (caveat: the risk of double spending - see discussion below). In the
video the merchant simply receives the bitcoins via Bitcoin-Qt. But one could
imagine to plug in a merchant solution like BitPay or Coinbase here, which would
then convert back to euros to complete the cycle. Here is the video:
Technical details
First off: If you do not care about all the back and forth with traditional
currencies, then this solution can of course also be used in a Bitcoin-only
manner. It is based on work that Andreas Schildbach already did for the Android
Bitcoin wallet (great stuff - thanks!) and is fully compatible with that. So the
Schildbach wallet will pick up the NFC payment request and also the transaction
transfer over Bluetooth is compatible. The code for the point of sale terminal
is open source and you can find it
over on GitHub. The
repository also has some notes about the recommended NFC hardware.
Currency conversions and fees
All this currency conversion back and forth is terrible convoluted and must be
pretty expensive, you might be thinking at this point. Why not just transfer
euros directly, if that is the goal? To expand on what I wrote in the
introduction: The problem with transferring euros electronically is the fact,
that there is no such thing as a digital euro. You can only have digital IOUs
for euros - that is promises from someone, that they will pay you a euro later -
and you can then transfer those digital IOUs. That means you will always have to
be very careful about whose IOUs you accept, so that you can be sure that you
are getting paid in the end.
Bitcoin, on the other hand, stands for itself. It is a digital commodity that
commands a market price and it therefore does not matter from whom you are
receiving those bitcoins. It is the digital equivalent of "cash is king".
Building a payment network with Bitcoin at the core allows for a much more open
approach where everyone is free to connect to and become a part of that network.
To make it cost-competitive, the "on- and off-ramps" to the Bitcoin network, the
exchanges, need to be efficient. That means low fees on one hand, and also tight
spreads - the difference between the highest buy offer and the lowest sell offer
- on the other hand. In the case of Bridgewalker, for example, this currently
amounts to a fee of around 1.5 % for a "round trip". So sending out 100 EUR in
the form of bitcoins and then depositing them again, will typically leave you
with 98.50 EUR (although transfers between Bridgewalker users are internal and
free, by the way). At the moment Bridgewalker uses Mt.Gox as its exchange
platform. Then you have to factor in the cost for the user to get bitcoins in
the first place, to fund his Bridgewalker account, and that might be another
percent or two. On the merchant side very competitive pricing options are
available from both BitPay and Coinbase. All in all, I think you can stay under
3 % even today, to pick a number that is typical for credit card fees, and there
is quite a bit of room to push this down further as Bitcoin exchanges mature.
Lastly I want to point out, that Bridgewalker is just a technical prototype and
I therefore opted to only allow funding of accounts via Bitcoin. This creates
additional points of currency exchange, but frees me from interfacing with the
traditional banking system and instead allows me to focus on experimenting with
the user interface. An institution that would undertake a direct integration
with, for example, the ACH network should be able to reduce fees even more.
In fact, a highly upvoted feature
request
for Coinbase to implement a "buy-as-you-spend" feature would be essentially just
that. It would allow a user to spend bitcoins via the Coinbase app and have it
replenished by pulling fiat from their bank account. This is essentially just a
mechanism to spend fiat from their bank account via Bitcoin, which brings us
back to the idea of using Bitcoin solely as a payment mechanism.
Double spending
Discussing the topic of double spend risk management really requires a whole
blog post or more like a series of them in itself, and this post is already
getting too long. But just a few comments here: The common wisdom so far has
been, that for small in person payments the risk of accepting zero-confirmation
transactions is minimal. I agree that this is probably true. Although it is
only true, if the merchant receives the transaction via the Bitcoin network and
therefore has some indication that it has been broadcasted widely.
In this setting the merchant receives the transaction directly from the
customer, which makes it much easier for the customer to trick the merchant, by
sending a conflicting transaction simultaneously to the rest of the Bitcoin
network. So this is still one of the pieces missing from this solution, before
it is ready for real world usage. The merchant should wait a few extra seconds
(unfortunately adding extra delay) and then check with a number of
highly connected Bitcoin nodes whether there are any known double spends
(feature request for Blockchain.info: return the double spend info that you are
collecting already via your JSON api. It would be great if the data returned for
a transaction would have an extra field called "known_double_spends" or
"known_conflicts" which would be simply "true" or "false" or maybe a list of
conflicting transaction ids). This would, I believe, be a reasonably secure
heuristic for small amounts.
In general though, receiving the transaction directly from the customer will be
the only solution going forward. Relying on a gossip-style peer-to-peer network,
as Bitcoin is, for timely delivery of transactions will simply fail too often
(for some anecdotal evidence of this, see for example this
thread).
As an aside: The demo above employs green
addresses. Bridgewalker transactions
can be recognized by their use of coins from 1MAxx46Dp3tFw933PxPwEYYGCpxYda2pyH
which is why the backend displays "Verified by Bridgewalker" after receiving the
transaction. So in this case the merchant knows where to complain, if anything
murky should happen with the transaction afterwards.
Green addresses are a hack - I said as much, when I proposed them back in 2011 -
and now that we have BIP 70, the payment
protocol proposal, this would probably be a better outlet to integrate a similar
mechanism.
Future work
All of this should probably be ported to use the payment protocol, which should
allow to add some other niceties as well, like displaying some meta information
about the payment directly on the client side (what is this for? who is
requesting it? have they signed the request?). Then of course the mentioned
double spend detection heuristic needs to be added. It would also be helpful to
replace the use of Bitcoin-Qt with a more lightweight client, to be able to run
the point of sale terminal on something like a Raspberry Pi.
The code is open source -
patches are always welcome! :-)
29 Dec 2013
Welcome to the Bridgewalker blog! The news is already a couple of weeks old, but
I would like to use this first post to report that Bridgewalker has been
acquired be Hive!
I was lucky to meet Wendell Davis at the Amsterdam Bitcoin conference in
September and we had some great conversations about Bitcoin wallets and the
Bitcoin ecosystem in general. So when he later approached me with the idea of
Hive acquiring Bridgewalker and me joining the team, it did not take much
convincing for me to decide that this was a great match and opportunity.
I am very excited about joining the Hive team and looking forward to building
some great products. I will be focusing initally on helping out with the Android
port of Hive, which will put Bridgewalker a little bit on the back burner for
the time being. But it will continue to operate and I am looking forward to
explore future possibilites of integerating it with the rest of Hive's
offerings.
Watch this space for some cool additional announcements resulting from the
acquisition!
Here is the original
announcement.