Abstract

A lightning enabled wallet called BlueWallet is reviewed on the basis that it provides the most user friendly experience for regular users when it comes to the Bitcoin (BTC) lightning network (LN). The user experience is contrasted to that of using the well known on-chain wallet called HandCash (though the comparisons are true for several modern mobile BSV and BCH wallets). It becomes very clear during the review that to provide a tractable on-ramp to the lightning network, for regular users, the overall user experience is lacking in the areas of security, reliability, privacy and custody of funds. Furthermore, a number of technical problems were encountered with the wallet, including loss of funds, but even if none of those problems occurred, given that the experience is competing with other modern fiat based payment systems, it is concluded that the complete user experience is one that is hardly likely to be the future of mass adoption. This is not a criticism of the wallet developers (though they are the ones responsible for the current technical issues with the wallet), but it is a consequence of the way the lighting network works; it seems like it may very well be impossible to make a lighting wallet that is user friendly enough for normal people to begin to even consider switching from incumbent payment systems.

Forward

In this article I will try my best to deliver an un-biased review of the lightning network (LN) enabled wallet called BlueWallet, and where relevant compare the user experience (UX) on that wallet, with the HandCash wallet. Note that I will not be reviewing HandCash in this article, but basing comparisons on my own regular usage and experience with that wallet, so for now, if you have not used HandCash, you’ll have to take my word, for what it’s worth. I’ll plan to do a review of HandCash sometime in the future.

For the purposes of this review, and the tests conducted, I ran all wallets on the same hardware (spare Samsung Galaxy S4 devices) and on the same home network. The experiences with the HandCash wallet that I draw upon are also based on HandCash being installed on the very same Samsung Galaxy S4 devices, so as to keep the comparisons as fair as possible, even though the comparisons themselves are mostly anecdotal.

Introduction

It’s certainly not the only thing, but one big thing that is holding back adoption of cryptocurrency is ease of use and accessibility for non tech savvy people. It stands to reason whilst easy to use tools might not bring mass adoption, the lack of them will most certainly stymie it significantly.

The Bitcoin (BTC) Lighting Network is BTC’s off-chain scaling solution. It is intended to relieve the primary on-chain network of the plethora of micro (let’s say sub $100 USD) transactions that would occur in a mass adoption scenario, by moving these to an off-chain, or second layer, system. It is outside the scope of this review to analyze and comment on the design and implementation of the lightning network, but it’s safe to say that for most users, in its current form, it represents an insurmountable hurdle mainly due to extreme lack of user friendliness and pre-requisite technical knowledge.

Running a lightning network node at home involves at minimum, running an (often Linux based) server that runs 24/7, with a Bitcoin (BTC) full node installed and configured (btcd), and a Lightning Network node installed and configured (lnd). Optionally, for mobile wallet access there is additional software that can be installed, configured and paired to a mobile device. All of this requires knowledge of computers, networks and configuration. Whilst tech geeks and crypto nerds might find this stuff extremely interesting and have no qualms about tackling it head on, no mere mortal is going to put themselves through it. Normal people just want to install an app and use it. This is where BlueWallet comes in.

BlueWallet is claimed to be user friendly Bitcoin wallet that comes with zero configuration lightning network support. It is intended to be a wallet for the layperson and by extension support mass adoption of Bitcoin (BTC) and the lightning network.

To that end, this review is about comparing the path that a potential normal user would take to on-board into Lightning, and constrasting that to the on-chain experience that is possible with HandCash (or other on-chain wallets). Is Lighting with BlueWallet a HandCash killer, or can HandCash claim the better overall user experience? We shall find out.

Some information about BlueWallet.

BlueWallet is software that supports both on-chain BTC wallets and lighting network (LN) wallets. According to some folk on Reddit this wallet is still in beta, but the Google App store gives no indication of this at all.

Some links to BlueWallet where you can find additional information:

BlueWallet’s developers list the following pros and cons (emphasis my own).

Pros :

· Improves user experience, allowing to onboard more users

· Completely removes technicalities, like opening and maintaining channels and liquidity (both incoming and outgoing)

· Improves chances of successful payment routing

· Receiving payments is a breeze (lndhub and lnd are 100% online, no need for Watchtowers)

· Single LndHub (if self-hosted) can help share lightning experience with many users (think friends and family)

Cons :

· Funds are held by a 3rd party (but only small amounts for everyday use). Mitigated by opensourcing LndHub.

· Minor network centralization

· Less private. Hub operator knows who paid whom . Luckily, trust is minimized as Hub doesn’t know who is on sending and who is on receiving end, and what is being paid for. And again, LndHub is opensource for people needing extra privacy.

The BlueWallet developers provide an extra layer that they call lndhub . In the case that a tech savvy user was to adopt lndhub, they may also install and configure this on their own 24/7 server, resulting in a complete stack of btcd + lnd + lndhub. At that point such a user could expose the hub service to multiple parties, bearing in mind that they would be running a custodial service for whoever used it and would be responsible for keeping it up 24/7 and for managing and troubleshooting any issues that may arise.

The zero configuration option with BlueWallet is such that you use an instance of lndhub that is hosted by BlueWallet, thus alleviating the need to install and configure not only lndhub, but also all of the other components in the stack.

In theory, a regular user would, therefore, install BlueWallet and immediately be able to start using the lightning network. This sounds pretty cool, but even before we download the BlueWallet app, there are some potential issues to be aware of, as follows.

1. Using BlueWallet and the zero configuration option, means that the wallet is custodial ; i.e., you have an account with BlueWallet and the BlueWallet lndhub instance keeps track of your account balance. When you send/receive using your BlueWallet wallet, it is not really sending or receiving on the lightning network; it is forwarding those requests to the hosted lndhub instance.

2. As a consequence of #1, and as the BlueWallet developers freely admit, they are able to access all of your transactions , so basically there should be no expectation of privacy when using BlueWallet.

3. A further consequence of #1 is that if there are any problems with your account, that you would not have control over this and would likely have to contact the developers and hope that they can resolve the issue. The developers do only recommend using BlueWallet with small amounts, but for LN to be of practical use long term then that figure has to be at least $100 USD, in my opinion. I say this amount for two reasons. The first, that even though the model use case for LN is buying a coffee, LN won't be much use if coffee is all you can buy. You also need to be able to purchase other more expensive items, to make LN compelling. If it was only useful for transactions of $5 or less, and on-chain was only really practical in future for $500 or more (due to high fees and confirmation times) then there would be a large range of items that people couldn't practically buy with either LN or on-chain transactions. The second reason is that for LN's low fees to be compelling, one needs to amortize on-chain fees over many LN transactions. If you were to top up the LN wallet for every 2 LN transactions, with an on-chain transaction, then the low fees on LN are moot.

4. Another thing to note about BlueWallet is that the developers claim that using lndhub increases chances of a successful payment routing. I’m not sure this is much of an advertisement for LN in general, however, BlueWallet does have this effect because the hosted lndhub instance already has numerous connected lightning channels that contain a certain amount of liquidity. As I found though, that wasn’t always enough to guarantee a successful transaction.

More information about the hosted lndhub instance that BlueWallet uses:

An example of the hosted lndhub’s open channels, showing capacity and state information.

Setting up the BlueWallet

Downloading and installing the wallet is pretty straight-forward for anyone that has ever installed an app on a phone and setting up new wallets, to be fair, is fairly intuitive and easy to do. For that reason and for the sake of brevity, I skip the download and installation steps and go straight to setting up an LN enabled wallet.

The first step in BlueWallet is to create a wallet. I started with the lightning enabled wallet (Left screen, below).

When creating a new lighting wallet, if no on-chain wallet exists, you get the following message (Middle screen, below), indicating that you require one in order to fund the LN wallet. Of course this is the way the lightning network works, but in comparison to something like HandCash, it’s an extra step that has the potential to confuse users, and is thus an overall negative for the user experience.

Ignoring the warning, and continuing, the resultant lighting wallet looks like the screen on the right.

So far, so good.

Creation of the on-chain wallet was also very straight forward, and so no screen shots of this process are included. The seed phrase is able to be backed up like most typical HD (hierarchical deterministic) wallets and no unexpected issues were encountered in that process.

After setting up both wallets I took time to review various settings and came across the area in BlueWallet where you could configure it to use a lndhub that you were hosting yourself on your own server. As it says, if you leave it as-is, it defaults to lndhub.io, so the wallet most definitely lives up to its claim of zero configuration (if you exclude wallet set up, which is standard for most software wallets).

Further exploration around the BlueWallet interface revealed that right now at least it is not possible to send LN Bitcoin (BTC) to an on-chain wallet. For this to happen you have to send LN BTC to an LN enabled exchange who would convert back to on-chain BTC for you, presumably with a fee. The BlueWallet directs you to an exchange called ZigZag, which is notably one of the domains where the BlueWallet lndhub has established channels.

At the time I tested the BlueWallet there didn't seem to be much demand for converting LN BTC to on-chain BTC, at least not using ZigZag. The following screen shot shows 6 total LN to BTC exchanges made in about 24 hours, all for very small amounts (which is probably expected with the technology in the testing phase).

Using the BlueWallet

The first thing for me to do to test the wallet was to acquire some BTC and send it to my on-chain wallet, after which I could fund the LN wallet. So I bought a small amount of BTC from my local exchange and sent it to my on-chain wallet. After about 35 minutes the balance was showing in the on-chain wallet. (Left screen, below).

The total amount I transferred to my on-chain wallet was 194,861 satoshis. (Middle screen, below).

Next, I needed to "refill" my LN wallet. BlueWallet has a funds management option which allows one to send BTC from the on-chain wallet to the LN wallet. I initiated a refill. (Right screen, below).

This is where I hit my first hurdle with the wallet, that had, to this point been pretty intuitive and user friendly. For some reason it didn't like that I wanted to use all my on-chain funds to refill the LN wallet. (Left screen, below).

So I tried again with a lower amount. (Middle screen, below).

Nope, that didn't work either. (Right screen, below).

Slightly long story short, it eventually worked if I picked a value of 0.0019 BTC, however, the refill transaction took the entire remaining sum of BTC in my on-chain wallet as a fee (approximately $0.17 USD or $0.23 AUD).

After that process was finally negotiated successfully, it was necessary to wait for the refill transaction (which is an on-chain transaction with the fee just mentioned) to confirm. After about 20 mins my on-chain BTC was now showing a 0 balance, and my sats had arrived in my LN wallet.

This process was mostly painless, except for a problem in the wallet where the transactions displayed didn't seem to update properly and seem to get mixed up between the on-chain wallet and the LN wallet. For example, in the previous screens the LN wallet is showing only LN transactions (seems expected), the on-chain wallet is showing on-chain transactions (also seems expected), but in the screen below, that was taken before the previous two, the LN wallet has a mix of transactions, including what appears to be a duplicate. To be honest it's not clear which icons represent on-chain transactions, which represent LN and which represent exchanges between on-chain and LN and the fact that the transaction list was somewhat unreliable made it more difficult to figure out.

Performing a LN transaction

I was now (almost) at the stage where I could perform my first LN transaction, however, I needed somewhere to send the LN funds, so I enlisted the help of a second Samsung Galaxy S4 to install a second copy of BlueWallet, setting up only a LN wallet on that device.

This is where I discovered that to send LN funds once needs to generate an invoice on the receiving device. Unlike for an on-chain transaction, such as is the case with HandCash, you cannot just send funds to an address; an invoice is necessary. LN invoices have limited terms and expire after a set amount of time. The BlueWallet seems to choose an arbitrary (but not restrictive) time limit when generating an invoice.

After generating an invoice on the second phone, it was relatively easy to choose send on the first phone, scan the QR code for the LN invoice and send 1,000 sats.

The following image shows the second phone and the invoice that was generated to receive 1,000 sats. (Side note: That LN QR code is a complicated sucker! Some symmetry, perhaps, with LN in general?).

The next image shows the first phone and the process of sending the 1,000 sats. The process involved scanning the QR code (I was impressed that my sometimes recalcitrant Galaxy S4 managed to scan it) and approving the send. The balance on the send phone updated virtually right away.

The receive phone, however, after showing that the invoice had been paid, had some problems in displaying the successful transaction. The middle screen (below) shows that the payment transaction was received, as does the text under "latest transaction", but the balance still shows 0 sats. Then a few minutes later on the right hand side screen, the balance is updated, but the transactions have vanished. This kind of behavior with transactions and balances turned out to be a consistent problem with the BlueWallet and consistently annoying.

Further testing of LN transactions

After this initial test of an LN transaction was successful, I returned the 1,000 sats to the first wallet and then started to look for a way to test the wallet with an LN enabled site that was not part of the same underlying LN node. After initially finding nothing (I'm not a good Googler, probably), some folks on Reddit put me on to lighting-roulette.com. The site is a simple gambling site with a roulette wheel, that maintains an account balance where that account balance accepts LN deposits and withdrawals. I'm not a gambler (or maybe I am since I own crypto), but I decided it would be a good way to test the BlueWallet further with a real LN enabled site.

I started by sending a small amount of satoshis to the site (2 lots of 150). The fees were zero, but the transactions where no where near as fast as I was thinking they would be based on what I keep hearing about the expected user experience. The whole process from clicking send, to seeing the site display a tick indicating that the funds were received was somewhere between 6-10 seconds. This compared to a typical HandCash transaction that takes of the order of 2-3 seconds in my experience.

(Just a guess, but this delay was not evident when sending from BlueWallet to BlueWallet, which I assume is related to the fact that lndhub is account based; there may have been no actual LN transaction in that case. But again, I am just guessing based on the description of BlueWallet from the official sources).

After a couple of roulette wheel spins I was winning (just), so I transferred my HUGE winnings back to my wallet.

At this point, despite the fact that the transactions weren’t really free (due to on-chain fees to refill my LN wallet), despite the fact that the transactions weren’t as fast as I thought (8-9 seconds), and despite the fact the wallet was having troubles always showing the correct balance information and transactions, I was still feeling generally that the BlueWallet was performing fairly admirably. It wasn't too long, however, before I ran into some issues that changed my mind.

I played a bit more roulette (I'll admit, I was enjoying it) and got up past 300,000 sats before I eventually lost a bunch of sats and decimated my total balance to under 10,000. Desperate not to go out in one fell swoop I managed to fight back to about 33,000 sats. After sitting on that balance over night I was up for another round the next morning and tried sending 32,000 sats to the same roulette site as a deposit. This is where the real trouble began.

For some reason my deposit to the roulette site failed. In terms of the total amount transacted, 32,000 sats is a bit over $1 USD (@ approx $3500/BTC), so you would think that it should not have been a (routing) problem? Either way, the error message doesn't give the user much insight into the actual issue.

Determined to play roulette, I tried again, this time sending 30,000 instead of the 32,000 and it was successful. The satoshis arrived on the roulette site.

I played for about 10 mins and won an extra 3,000 satoshis so decided to cash out, but even though the 33,000 sat transaction arrived (30,000 + 3,000 winnings), my total balance was just 1037 sats!

Initially I thought that this was just another wallet refresh/display problem, but even after a couple of hours the balance was still showing the same. Further review of the transaction history seems to show that the failed transaction didn't fail after all. Or it failed, but somehow my balance was decremented anyway, without the funds being credited on the other end. So once I withdrew my winnings, that credit only just covered the "failed" 32,000 sats transaction that occurred earlier. Or something to that effect.

Wondering whether I might be able to give the wallet a nudge by performing an additional transaction (I have no idea what is going on, under the hood) I sent an additional 100 sats back to the roulette site. Instead of reducing my balance by 100 sats to 937 sats, it increased by 2900 sats to 3937 sats!!! (Probably a WTF moment if I ever saw one).

Pretty soon after this I stopped testing BlueWallet as I realized that it could not be trusted with my funds. I had achieved what I had wanted to achieve anyway. Whether the loss of funds issue is a problem with the wallet specifically, or a problem with the lightning network, I do not know. What I do know that the user experience in it's current form, even if the wallet behaved flawlessly, is not up to the same level as something like HandCash, so once you throw in a number of pain points, then it becomes a non starter in my book, especially considering that we are reviewing the wallet based on it being the most friendly lightning UX possible and aimed at regular (non tech savvy) users.

Comparison with HandCash

After testing BlueWallet as the most user friendly, zero configuration alternative for BTC/LN I am in a position to compare that experience with, albeit anecdotally (until the HandCash review) HandCash for BSV.

HandCash, as some of you may know, is a very user friendly mobile wallet. The setup process is quite trivial and it walks the user through the backup process.

As already mentioned earlier, I do not intend to review HandCash in this article (it's well and truly long enough already), but suffice to say I have used it quite a bit and this is how it compares to BlueWallet, in my opinion.

Note: If someone wanted to challenge my comment on QR codes I would probably accept it. Newer phones handle larger QR codes better, but we should also remember that not every user will have access to the latest and greatest phones either. If we want Bitcoin to be accessible to as many people as possible, it could be a consideration.

Conclusions

All up the BlueWallet was somewhat better than I was expecting, but also in certain ways worse than what I was expecting.

An example of where it was better is the ability to receive funds without having to jump through any additional hoops. If you are familiar with the lighting network you may know that when you open a channel and fund it, the funds are all "at your end", meaning that you must first send funds (and move them to the other end of the channel) before you can receive funds back in the other direction. There are currently ways to get around this (that further complicate LN for geek users, such as submarine swaps), but the BlueWallet makes this a non issue for a regular user.

Note : You can see an example of this "channel direction" in a channel in the very first image of the lndhub channels. On the left hand side the channels show a bar indicating of the total channel capacity how much of it is receive capacity and how much of it is send capacity.

An example of where BlueWallet was worse than expected is the slow transactions, the problems with balances and transactions and also the fact that I lost funds.

As a general observation, the BlueWallet UI was fairly intuitive though a little drab and plain in some places.

Thinking about a non-technical user using this application on a daily basis, I cannot see why they would choose to use BlueWallet (and LN) versus something as reliable and easy to use as HandCash. Surely the extra friction created by having to first fund an on-chain wallet, then refill the lightning wallet (incurring two lots of on-chain transactions and associated fees that are expected to increase over time), the wait times involved for the on-chain funding, the risk of keeping any significant amount in the custodial wallet, the lack of privacy and the chance of losing funds (even if that turns out to be quite small) all combines together to make a compelling reason to steer well clear of it.

I have no doubt that this assessment might make some hard core BTC or lightning network fans cry out in objection, however, once they get over the unbridled joy, excitement and welling of tears when they see the speed of a lightning transaction compared to BTC on-chain transactions, the reality of the situation must eventually seep through that there are other versions of Bitcoin that arguably stayed true to the original scaling vision, that deliver a much more robust and user friendly user experience. And, what's more, they do not provide this experience at some unspecified time into the distant future; they provide it right now.

Note : There is nothing in the "paid content" section other than a message of thanks if you do choose to pay for this article. It will be much appreciated!















